lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 21 Aug 2019 23:09:06 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Julia Kartseva <hex@...com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        "labbott@...hat.com" <labbott@...hat.com>,
        "acme@...nel.org" <acme@...nel.org>,
        "debian-kernel@...ts.debian.org" <debian-kernel@...ts.debian.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrii Nakryiko <andriin@...com>, Andrey Ignatov <rdna@...com>,
        Alexei Starovoitov <ast@...com>, Yonghong Song <yhs@...com>,
        "jolsa@...nel.org" <jolsa@...nel.org>
Subject: Re: libbpf distro packaging

On Tue, Aug 20, 2019 at 10:27:23PM +0000, Julia Kartseva wrote:
> 
> 
> On 8/19/19, 11:08 AM, "Julia Kartseva" <hex@...com> wrote:
> 
>     On 8/13/19, 11:24 AM, "Andrii Nakryiko" <andrii.nakryiko@...il.com> wrote:
>     
>         On Tue, Aug 13, 2019 at 5:26 AM Jiri Olsa <jolsa@...hat.com> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ