From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2C77C3A59E for ; Wed, 21 Aug 2019 21:09:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C79FB20578 for ; Wed, 21 Aug 2019 21:09:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728464AbfHUVJL (ORCPT ); Wed, 21 Aug 2019 17:09:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58162 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727316AbfHUVJK (ORCPT ); Wed, 21 Aug 2019 17:09:10 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5150B18C8905; Wed, 21 Aug 2019 21:09:10 +0000 (UTC) Received: from krava (ovpn-204-27.brq.redhat.com [10.40.204.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id 92958194B9; Wed, 21 Aug 2019 21:09:07 +0000 (UTC) Date: Wed, 21 Aug 2019 23:09:06 +0200 From: Jiri Olsa To: Julia Kartseva Cc: Andrii Nakryiko , "labbott@redhat.com" , "acme@kernel.org" , "debian-kernel@lists.debian.org" , "netdev@vger.kernel.org" , Andrii Nakryiko , Andrey Ignatov , Alexei Starovoitov , Yonghong Song , "jolsa@kernel.org" Subject: Re: libbpf distro packaging Message-ID: <20190821210906.GA31031@krava> References: <3FBEC3F8-5C3C-40F9-AF6E-C355D8F62722@fb.com> <20190813122420.GB9349@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.70]); Wed, 21 Aug 2019 21:09:10 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Aug 20, 2019 at 10:27:23PM +0000, Julia Kartseva wrote: > > > On 8/19/19, 11:08 AM, "Julia Kartseva" wrote: > > On 8/13/19, 11:24 AM, "Andrii Nakryiko" wrote: > > On Tue, Aug 13, 2019 at 5:26 AM Jiri Olsa wrote: > > > > On Mon, Aug 12, 2019 at 07:04:12PM +0000, Julia Kartseva wrote: > > > I would like to bring up libbpf publishing discussion started at [1]. > > > The present state of things is that libbpf is built from kernel tree, e.g. [2] > > > For Debian and [3] for Fedora whereas the better way would be having a > > > package built from github mirror. The advantages of the latter: > > > - Consistent, ABI matching versioning across distros > > > - The mirror has integration tests > > > - No need in kernel tree to build a package > > > - Changes can be merged directly to github w/o waiting them to be merged > > > through bpf-next -> net-next -> main > > > There is a PR introducing a libbpf.spec which can be used as a starting point: [4] > > > Any comments regarding the spec itself can be posted there. > > > In the future it may be used as a source of truth. > > > Please consider switching libbpf packaging to the github mirror instead > > > of the kernel tree. > > > Thanks > > > > > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.iovisor.org_g_iovisor-2Ddev_message_1521&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=dYAc2jLhFg0wtCZ_ms2HF5bWANoHzA3UMug5TNCeBtE&e= > > > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__packages.debian.org_sid_libbpf4.19&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=lq1MpF-bt6y6ZEtFc57eT-BO_wMBx8uUBACJooWbUYk&e= > > > [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__rpmfind.net_linux_RPM_fedora_devel_rawhide_x86-5F64_l_libbpf-2D5.3.0-2D0.rc2.git0.1.fc31.x86-5F64.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=zUrDY_Sp_5PqcGtRQPNeDA&m=prYVDiu3-aH1o2PWH4ZcP7lEQRCQAcTwcWPrJrtaroQ&s=NoolYHL57G2KhzE768iWdy6v5LD2GfJQyqPmtjy196E&e= > > > [4] https://github.com/libbpf/libbpf/pull/64 > > > > hi, > > Fedora has libbpf as kernel-tools subpackage, so I think > > we'd need to create new package and deprecate the current > > > > but I like the ABI stability by using github .. how's actually > > the sync (in both directions) with kernel sources going on? > > Sync is always in one direction, from kernel sources into Github repo. > Right now it's triggered by a human (usually me), but we are using a > script that automates entire process (see > https://github.com/libbpf/libbpf/blob/master/scripts/sync-kernel.sh). > It cherry-pick relevant commits from kernel, transforms them to match > Github's file layout and re-applies those changes to Github repo. > > There is never a sync from Github back to kernel, but Github repo > contains some extra stuff that's not in kernel. E.g., the script I > mentioned, plus Github's Makefile is different, because it can't rely > on kernel's kbuild setup. > > Hi Jiri, > I'm curious if you have any comments regarding sync procedure described > By Andrii. Or if there is anything else you'd like us to address so Fedora > can be switched to libbpf built from the github mirror? hi, yea, I think it's ok.. just need to check the implications for rhel packaging and I'll let you know jirka