[bionic][PATCH 0/2] add bpftool to linux-tools-common

[Quentin Monnet]

2019-08-14 11:45 UTC+0200 ~ Kleber Souza <kleber.souza at canonical.com>
> On 8/12/19 6:27 PM, Quentin Monnet wrote:
>> 2019-07-21 17:36 UTC+0100 ~ Quentin Monnet <quentin.monnet at netronome.com>
>>> BugLink: https://bugs.launchpad.net/bugs/1774815
>>>
>>> [Impact]
>>>
>>> bpftool is a debugging and introspection tool for BPF elements, developed by
>>> the BPF kernel community. It is essential to list and dump BPF programs and
>>> maps loaded on the system. Its sources are located in the kernel repository,
>>> and because it is not packaged, administrators willing to use bpftool must
>>> download the whole kernel sources, compile and install the utility.
>>>
>>> [Fix]
>>>
>>> Adding bpftool to linux-tools and linux-tools-common packages makes it easily
>>> accessible. These packages are already use to provide other tools located in
>>> the kernel repository, such as perf.
>>>
>>> Because the bpftool version provided with kernel 4.15 does not build properly
>>> (API changed at some point in bfd.h from binutils-dev), backport a patch from
>>> 4.16 to fix the calls to libbfd's disassembler.
>>>
>>> [Testcase]
>>>
>>> A test linux package was successfully built, at:
>>>
>>> https://launchpad.net/~qmonnet/+archive/ubuntu/ppa-linux-bpftool
>>>
>>> (The i386 build actually fails, but it does not seem related to the
>>> changes. The amd64 build succeeded.)
>>>
>>> Packages linux-tools-$(uname -r) and linux-tools-common can be built with
>>> "debian/rules binary", and contain bpftool's binary and related files
>>> (redirection script, bpftool manual pages, bash completion), respectively.
>>>
>>> [Regression Potential]
>>>
>>> Low, as far as I can tell:
>>>
>>> - The backported patch touches only bpftool and one feature in
>>>   tools/build/feature (only used with bpftool), all of it user space tools not
>>>   used for anything other than bpftool itself.
>>>
>>> - bpftool packaging does not change the way other tools are packaged (apart
>>>   from creating $(toolsman)/man8 a few lines earlier), and should have no
>>>   impact on the packaging of other tools. One dependency is added to
>>>   Build-Depends-Indep, none is removed.
>>>
>>> ---
>>> This is my first contribution to ubuntu_kernel, please let me know if I got
>>> anything wrong with the process.
>>>
>>> I would like bpftool to be packaged for bionic and later (supported) releases,
>>> if possible. Could someone provide me some guidance on the process, please?
>>> Should I also submit the packaging patch for disco/eowan? (As the patch
>>> backported in this series is in Linux 4.16, later Ubuntu versions should not
>>> need this backport.)
>>>
>>
>> Hi all,
>>
>> I am looking forwards to having bpftool packaged on bionic and later
>> releases. Is there anything more I can do to help with getting this
>> patchset accepted? Please let me know.
>>
>> (I am not aware of the usual processing delays for patches on the
>> mailing list, please accept my apologies - and tell me - if pinging does
>> not feel appropriate.)
>>
> 
> Hi Quentin,
> 
> Thank you for your contribution to the Ubuntu kernel.
> 
> From what I can tell your submission as a SRU request followed all the
> guidelines. However, our rule for this sort of packaging change is that
> it needs to be made first in the development series (currently Eoan). This
> is so that no newer releases get out of sync and that we have time to test
> the changes in the devel series before backporting to a stable series.
> 
> I would suggest sending the request again tagging as "[EOAN][UNSTABLE]"
> so that the development team can assess this change (I have added them on
> CC).

Hi Kleber,

Thank you for your answer and guidance! I will rebase the patch for
Eowan, and resubmit as you indicated.

Best regards,
Quentin