Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #81018 > unrolled thread

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2023-12-02 21:10 +0100
    Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Luca Boccassi <bluca@debian.org> - 2024-05-30 00:40 +0200
      Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2024-05-30 01:30 +0200
        Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Luca Boccassi <bluca@debian.org> - 2024-05-30 15:10 +0200
    Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2024-06-01 22:20 +0200
      Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Bastian Blank <waldi@debian.org> - 2024-06-19 22:10 +0200
    Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2024-07-17 22:10 +0200

#81018 — Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

Package: bpftool
Severity: wishlist
X-Debbugs-Cc: sudipm.mukherjee@gmail.com, debian-kernel@lists.debian.org, debian-devel@lists.debian.org

The official home for bpftool is now the github repo [1] but keeps the kernel
as the authoritative source code of bpftool and is developed as part of the bpf-next Linux source tree.
The Maintainers have said "Please use this Github repository for building and packaging bpftool" at [2]
The announcement was at [3].

imho, packaging it from the github instead of the kernel source will fix three issues:
1. bpftool will use libbpf available in Debian, whereas now it is building a libbpf.a from the development codes of libbpf in the kernel source and using that.
2. The official releases of bpftool is done in the github repo when the bpf maintainers decides the code is ready for a release. But the Debian bpftool package is done from the kernel source and so follows the kernel releases. And as a result, when a new kernel is released which Debian kernel team will then pickup may not have a bpftool release worthy code. For example, bpftool v7.3 was released on 23/11/2023,
3. bpftool package in Debian is from the kernel v6.5.13 and so looking at the source and git commits I can see the that the Debian package is missing 25 commits which is in the bpftool v7.3 release.


Do we package bpftool from their github repo independent of the kernel
update? Then we will need to remove the bpftool building bits from the
Debian kernel source and create a separate package for bpftool.

And so, it will be great if kernel team will like to package and maintain
it, if not, then I will be happy to do it. Please reject this bug report
if you think bpftool should not be done separately and should live inside
kernel source package.

[1]. https://github.com/libbpf/bpftool
[2]. https://github.com/libbpf/bpftool/blob/main/README.md?plain=1#L18
[3]. https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc325@isovalent.com/

-- 
Regards
Sudip

[toc] | [next] | [standalone]

#82623

[Multipart message — attachments visible in raw view] — view raw

On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk>
wrote:
> On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote:
> > And so, it will be great if kernel team will like to package and
> > maintain it, if not, then I will be happy to do it. Please
> > reject this bug report if you think bpftool should not be done
> > separately and should live inside kernel source package.
> 
> Since you are already maintaining libbpf I would be happy to hand
over
> bpftool to you.  I will try to discuss this at this evening's team
> meeting.

What about moving libbpf and bpftool to the kernel team area under
Salsa? That way more people can help, and it can use salsa-ci too

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#82624

On Wed, 29 May 2024 at 23:27, Luca Boccassi <bluca@debian.org> wrote:
>
> On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk>
> wrote:
> > On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote:
> > > And so, it will be great if kernel team will like to package and
> > > maintain it, if not, then I will be happy to do it. Please
> > > reject this bug report if you think bpftool should not be done
> > > separately and should live inside kernel source package.
> >
> > Since you are already maintaining libbpf I would be happy to hand
> over
> > bpftool to you.  I will try to discuss this at this evening's team
> > meeting.
>
> What about moving libbpf and bpftool to the kernel team area under
> Salsa? That way more people can help, and it can use salsa-ci too

bpftool is already with the kernel team and being built from kernel
source. And I anticipated that bpftool will move to github like
upstream libbpf did and also mentioned that at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041#83. So, its
upto the kernel team what they want to do with bpftool -
1. continue to build from kernel source and we can just close this bug
2. Split bpftool from kernel source and package it from github. The
kernel team can maintain if they want to maintain an userspace
package. If the kernel team does not want to maintain it, I can do
that.

About libbpf, I am confused with your message. What kind of help? Are
you seeing that libbpf is not maintained properly?


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#82627

On Thu, 30 May 2024 at 00:17, Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
>
> On Wed, 29 May 2024 at 23:27, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk>
> > wrote:
> > > On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote:
> > > > And so, it will be great if kernel team will like to package and
> > > > maintain it, if not, then I will be happy to do it. Please
> > > > reject this bug report if you think bpftool should not be done
> > > > separately and should live inside kernel source package.
> > >
> > > Since you are already maintaining libbpf I would be happy to hand
> > over
> > > bpftool to you.  I will try to discuss this at this evening's team
> > > meeting.
> >
> > What about moving libbpf and bpftool to the kernel team area under
> > Salsa? That way more people can help, and it can use salsa-ci too
>
> bpftool is already with the kernel team and being built from kernel
> source. And I anticipated that bpftool will move to github like
> upstream libbpf did and also mentioned that at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041#83. So, its
> upto the kernel team what they want to do with bpftool -
> 1. continue to build from kernel source and we can just close this bug
> 2. Split bpftool from kernel source and package it from github. The
> kernel team can maintain if they want to maintain an userspace
> package. If the kernel team does not want to maintain it, I can do
> that.
>
> About libbpf, I am confused with your message. What kind of help? Are
> you seeing that libbpf is not maintained properly?

I'm not talking about the upstream source, but about the debian
repository: given both of these are inextricably tied to the kernel, I
think it would be good to have the downstream repositories in salsa,
in the kernel-team area - and of course, still including yourself as
repo owner. The kernel team is not only for the kernel package, but
also other kernel-adjacent packages like ethtool, iproute2, firmware,
iw, etc: https://salsa.debian.org/kernel-team

[toc] | [prev] | [next] | [standalone]

#82646

On Thu, 30 May 2024 at 14:24, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote:
> > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee
> > <sudipm.mukherjee@gmail.com> wrote:
> > >
> > > On Wed, 29 May 2024 at 23:27, Luca Boccassi <bluca@debian.org> wrote:
> > > >
> > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk>
> > > > wrote:
> > > > > On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote:
> > > > > > And so, it will be great if kernel team will like to package and
> > > > > > maintain it, if not, then I will be happy to do it. Please
> > > > > > reject this bug report if you think bpftool should not be done
> > > > > > separately and should live inside kernel source package.
> > > > >
> > > > > Since you are already maintaining libbpf I would be happy to hand
> > > > over
> > > > > bpftool to you.  I will try to discuss this at this evening's team
> > > > > meeting.
>
> Unfortunately we didn't have time for it this time.

No problem. And even if bpftool is built as a new package, I think
Luca will like to keep bpftool with kernel team. Whoever maintains it,
as long as a release version is packaged and not a development
version, all is good.  So, I will leave it with you and the kernel
team.
Please ping me if you need me to do anything.

>
> > > > What about moving libbpf and bpftool to the kernel team area under
> > > > Salsa? That way more people can help, and it can use salsa-ci too
> > >
> > > bpftool is already with the kernel team and being built from kernel
> > > source. And I anticipated that bpftool will move to github like
> > > upstream libbpf did and also mentioned that at
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041#83. So, its
> > > upto the kernel team what they want to do with bpftool -
> > > 1. continue to build from kernel source and we can just close this bug
> > > 2. Split bpftool from kernel source and package it from github. The
> > > kernel team can maintain if they want to maintain an userspace
> > > package. If the kernel team does not want to maintain it, I can do
> > > that.
> > >
> > > About libbpf, I am confused with your message. What kind of help? Are
> > > you seeing that libbpf is not maintained properly?
> >
> > I'm not talking about the upstream source, but about the debian
> > repository: given both of these are inextricably tied to the kernel, I
> > think it would be good to have the downstream repositories in salsa,
> > in the kernel-team area - and of course, still including yourself as
> > repo owner. The kernel team is not only for the kernel package, but
> > also other kernel-adjacent packages like ethtool, iproute2, firmware,
> > iw, etc: https://salsa.debian.org/kernel-team
>
> Ah, I hadn't noticed that the libbpf packaging was on Github.
>
> I agree with Luca that it would be preferable to have these on Salsa
> but I don't have a strong opinion on whether they should be in the
> kernel-team group.

Absolutely. I dont remember why some of my packages (from 2019 - 2020)
are in github. But I will definitely move them to salsa.
About moving it under kernel team, I think I will say "no" to that
unless Luca can give some very good reasons about what is missing now
that will change if ts moved under kernel team.


-- 
Regards
Sudip

[toc] | [prev] | [next] | [standalone]

#82766

On Sat, Jun 01, 2024 at 09:13:09PM +0100, Sudip Mukherjee wrote:
> Absolutely. I dont remember why some of my packages (from 2019 - 2020)
> are in github. But I will definitely move them to salsa.
> About moving it under kernel team, I think I will say "no" to that
> unless Luca can give some very good reasons about what is missing now
> that will change if ts moved under kernel team.

I then object to a move from linux to you and even using the packaged
libbpf.  Right now this package is also single maintainer and this is
not acceptable for critical toolchain and basic userland stuff.

Bastian

-- 
Extreme feminine beauty is always disturbing.
		-- Spock, "The Cloud Minders", stardate 5818.4

[toc] | [prev] | [next] | [standalone]

#83065

On Wed, 19 Jun 2024 at 21:09, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Sat, 2024-06-01 at 21:13 +0100, Sudip Mukherjee wrote:
> > On Thu, 30 May 2024 at 14:24, Ben Hutchings <ben@decadent.org.uk> wrote:
> > >
> > > On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote:
> > > > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee
> > > > <sudipm.mukherjee@gmail.com> wrote:
> > > > >
> > > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi <bluca@debian.org> wrote:
> > > > > >
> > > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk>
> > > > > > wrote:
> > > > > > > On Sat, 2023-12-02 at 20:04 +0000, Sudip Mukherjee wrote:
> > > > > > > > And so, it will be great if kernel team will like to package and
> > > > > > > > maintain it, if not, then I will be happy to do it. Please
> > > > > > > > reject this bug report if you think bpftool should not be done
> > > > > > > > separately and should live inside kernel source package.
> > > > > > >
> > > > > > > Since you are already maintaining libbpf I would be happy to hand
> > > > > > over
> > > > > > > bpftool to you.  I will try to discuss this at this evening's team
> > > > > > > meeting.
> > >
> > > Unfortunately we didn't have time for it this time.
> >
> > No problem. And even if bpftool is built as a new package, I think
> > Luca will like to keep bpftool with kernel team. Whoever maintains it,
> > as long as a release version is packaged and not a development
> > version, all is good.  So, I will leave it with you and the kernel
> > team.
> > Please ping me if you need me to do anything.
> [...]
>
> At today's meeting we agreed that bpftool should be split out, but
> should remain under the kernel team with you as an uploader.

Sorry Ben, but it look like there are objections.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057290#40
I think all your team members will be happy if someone from your team
is the uploader.
Lets discuss during the Minidebconf if you think otherwise.


-- 
Regards
Sudip

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web