Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Wed, 19 Jun 2024 at 21:09, Ben Hutchings wrote: > > On Sat, 2024-06-01 at 21:13 +0100, Sudip Mukherjee wrote: > > On Thu, 30 May 2024 at 14:24, Ben Hutchings wrote: > > > > > > On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote: > > > > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee > > > > wrote: > > > > > > > > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > > > > > > > > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > > > > > > > > > > > > wrote: > > > > > > > On Sat, 2023-12-02 at 20:04 +, 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
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Sat, 2024-06-01 at 21:13 +0100, Sudip Mukherjee wrote: > On Thu, 30 May 2024 at 14:24, Ben Hutchings wrote: > > > > On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote: > > > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee > > > wrote: > > > > > > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > > > > > > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > > > > > > > > > > wrote: > > > > > > On Sat, 2023-12-02 at 20:04 +, 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. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. signature.asc Description: This is a digitally signed message part
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
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
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Thu, 30 May 2024 at 14:24, Ben Hutchings wrote: > > On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote: > > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee > > wrote: > > > > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > > > > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > > > > wrote: > > > > > On Sat, 2023-12-02 at 20:04 +, 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
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote: > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee > wrote: > > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > > > wrote: > > > > On Sat, 2023-12-02 at 20:04 +, 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. > > > 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. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Thu, 30 May 2024 at 00:17, Sudip Mukherjee wrote: > > On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > > wrote: > > > On Sat, 2023-12-02 at 20:04 +, 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
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Wed, 29 May 2024 at 23:27, Luca Boccassi wrote: > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings > wrote: > > On Sat, 2023-12-02 at 20:04 +, 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
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings wrote: > On Sat, 2023-12-02 at 20:04 +, 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 signature.asc Description: This is a digitally signed message part
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote: > Package: bpftool > Severity: wishlist > X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-kernel@lists.debian.org, > debian-de...@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. I don't really understand the distinction they're trying to make between "official" and "authoritative"... > 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. That's certainly a good reason. > 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, 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! > 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. Right. > 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. 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. > > [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-78afbf6fc...@isovalent.com/ > -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
Package: bpftool Severity: wishlist X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-kernel@lists.debian.org, debian-de...@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-78afbf6fc...@isovalent.com/ -- Regards Sudip
