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/
I don't really understand the distinction they're trying to make between "official" and "authoritative"... That's certainly a good reason. So bpftool does not get stabilised in the kernel? I don't really understand why it's still in the kernel tree at all then! Right. 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. Ben.
On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings <ben@decadent.org.uk> wrote: over 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?
On Thu, 30 May 2024 at 00:17, Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote: 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
Unfortunately we didn't have time for it this time. 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. Ben.