Patch for linux-headers
Hi,
I wonder if it's allowed to add patch to add patch for linux-headers. There would have to be more versions for the patch (due headers being built for more versions). I'd like to use my upstreamed patch [1] which fixes "redefinition of struct sysinfo" build failure on MUSL.
This so far required to patch affected packages or simply disable them (depends on !BR2_TOOLCHAIN_USES_MUSL).
Actually, much simpler patch from Khem Raj could be used [2].
Kind regards,
Petr
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a85cbe6159ffc973e5702f70a3bd5185f8f3c38d
[2] https://git.alpinelinux.org/aports/tree/main/linux-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Petr" == Petr Vorel <[email protected]> writes:
Hi,
I wonder if it's allowed to add patch to add patch for linux-headers. There would have to be more versions for the patch (due headers being built for more versions). I'd like to use my upstreamed patch [1] which fixes "redefinition of struct sysinfo" build failure on MUSL.
This so far required to patch affected packages or simply disable them (depends on !BR2_TOOLCHAIN_USES_MUSL).Actually, much simpler patch from Khem Raj could be used [2].
It can be done if needed, but it is naturally easier to handle without. I noticed that you got some patches applied to the stable kernels related to this recently - Do those fix the issues, or is an additional patch needed?
Signature · 1 line
Bye, Peter Korsgaard
Hi Peter,
Quoted 10 lines
Quoted 9 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Petr" == Petr Vorel <[email protected]> writes:
Hi,
I wonder if it's allowed to add patch to add patch for linux-headers. There would have to be more versions for the patch (due headers being built for more versions). I'd like to use my upstreamed patch [1] which fixes "redefinition of struct sysinfo" build failure on MUSL.
This so far required to patch affected packages or simply disable them (depends on !BR2_TOOLCHAIN_USES_MUSL).
Quoted 4 lines
Quoted 1 line
Actually, much simpler patch from Khem Raj could be used [2].
It can be done if needed, but it is naturally easier to handle without.
Understand. More versions and kernel checking would be needed. I implemented it, but IMHO it'd have to also require Buildroot toolchain rebuild.
Quoted 3 lines
I noticed that you got some patches applied to the stable kernels related to this recently - Do those fix the issues, or is an additional patch needed?
Yes, it fixes the issue. Thus no patching is needed.
I didn't expect the fix would be accepted in stable, but it has been accepted (in the end it's a fix).
OK, we need to wait till kernel stable releases, update kernel versions in Buildroot. But IMHO it still requires Buildroot toolchain rebuild. Or am I wrong?
BTW I'm waiting for it for iproute2 upgrade (originally [1] and [2], now [3]).
Kind regards,
Petr
[1] https://patchwork.ozlabs.org/project/buildroot/patch/20200818183832.7947-2-petr.vorel at gmail.com/
[2] https://patchwork.ozlabs.org/project/buildroot/patch/20200903155728.19448-2-petr.vorel at gmail.com/
[3] https://patchwork.ozlabs.org/project/buildroot/patch/20201104171416.1062-1-petr.vorel at gmail.com/
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Petr" == Petr Vorel <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 2 lines
It can be done if needed, but it is naturally easier to handle without.
Understand. More versions and kernel checking would be needed. I implemented it, but IMHO it'd have to also require Buildroot toolchain rebuild.
Indeed.
Quoted 4 lines
Quoted 3 lines
I noticed that you got some patches applied to the stable kernels related to this recently - Do those fix the issues, or is an additional patch needed?
Yes, it fixes the issue. Thus no patching is needed.
Ok, great!
Quoted 2 lines
OK, we need to wait till kernel stable releases, update kernel versions in Buildroot. But IMHO it still requires Buildroot toolchain rebuild. Or am I wrong?
Yes, the external toolchains will need to be rebuilt, but perhaps we can blacklist those in the autobuilders until the toolchains are all rebuilt.
Quoted 1 line
BTW I'm waiting for it for iproute2 upgrade (originally [1] and [2], now [3]).
Ahh, ok.
Signature · 1 line
Bye, Peter Korsgaard
Hi Peter,
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Petr" == Petr Vorel <[email protected]> writes:
Hi,
Quoted 5 lines
Quoted 2 lines
It can be done if needed, but it is naturally easier to handle without.
Understand. More versions and kernel checking would be needed. I implemented it, but IMHO it'd have to also require Buildroot toolchain rebuild.
Indeed.
I backported it to all LTS and stable branches (except 5.9 which is EOL) It has been released to some of them, for the rest the patch is in stable-queue.git => will be released soon.
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
I noticed that you got some patches applied to the stable kernels related to this recently - Do those fix the issues, or is an additional patch needed?
Yes, it fixes the issue. Thus no patching is needed.
Quoted 7 lines
Ok, great!
Quoted 2 lines
OK, we need to wait till kernel stable releases, update kernel versions in Buildroot. But IMHO it still requires Buildroot toolchain rebuild. Or am I wrong?
Yes, the external toolchains will need to be rebuilt, but perhaps we can blacklist those in the autobuilders until the toolchains are all rebuilt.
Do you mean to disable MUSL based toolchains for affected packages? I'm carrying patch for LTP, which is not going to be upstreamed. Sure, I could drop this patch and add: depends on !BR2_TOOLCHAIN_USES_MUSL, but I expect more packages affected by <linux/sysinfo.h> bug.
Quoted 3 lines
Quoted 1 line
BTW I'm waiting for it for iproute2 upgrade (originally [1] and [2], now [3]).
Ahh, ok.
I've prepared package for v5.8.0 which was blocked by this, then v5.9.0. There is already v5.10.0. I'm not sure what is better: allow BR2_TOOLCHAIN_USES_UCLIBC to have iproute2, but block new features (we still have v5.7.0).
Kind regards,
Petr