Re: [OE-core] [PATCH 0/21] linux-yocto: combined and consolidated pull request

Mathieu Dubois-Briand
2025-12-22T08:29:49Z

On Thu Dec 18, 2025 at 9:56 PM CET, Bruce Ashfield via lists.openembedded.org wrote:
> On Thu, Dec 18, 2025 at 3:22 PM Bruce Ashfield via
> lists.openembedded.org
> <bruce.ashfield=gmail.com@lists.openembedded.org> wrote:
>>
>> From: Bruce Ashfield <bruce.ashfield@gmail.com>
>>
>> Hi all,
>>
>> As discussed in the weekly engineering call, I'm sending this as
>> single series even though it crossed boundaries of the repositories.
>>
>> I don't have access to meta-yocto-contrib yet, so I haven't pushed
>> the component parts to contrib branches yet, but will do that for
>> future pull requests.
>>
>> I'm using this as a first run through some things I've cooked up
>> to coordinate the patches across the repos. The formatting is my
>> own, so apologies if it isn't clear .. and we'll see if it all
>>
>> Now to the series for OE-core:
>>
>> - We have stable updates to 6.12
>> - A kern-tools fix
>> - Updates to 6.17
>> - Removal of 6.17
>> - Introduction of 6.18
>> - Bump to libc-headers to 6.18
>>
>> I've built and booted what I can locally, and I know that the
>> major architectures work, and are functional with respect to
>> core features.
>>
>> I have more libc-headers testing running against meta-oe and
>> muslc, so there may be some breakage there and I'll help deal
>> with that if it happens.
>>
>> The update and then removal of 6.17 is on purpose. In case any
>> one was using it, they should get the latest tested before it
>> starts to be removed.
>>
>> For meta-yocto:
>>
>> - removal of any remaining 6.17 references
>> - introduction of 6.18
>>
>> The meta-yocto default changes are obviously REALLY RFC/RFT
>> there will be issues, but I've provided them anyway to make it
>> clear that we are going to 6.18 as the new default for all the
>> variants.
>>
>> Once we get 6.18 fully green and the h/w references udpated,
>> I'll remove 6.12 and 6.16 from master. That isn't in this series
>> by design.
>
>
> FYI: my extended testing shows a warning in the virtualization
> fragments. It isn't serious, but will be fixed in incremental patches
> on the end of this queue.
>
> Bruce
>

Hi Bruce,

Sorry, I was a bit late in testing this.

On my side I also get some issues in building strace, are you aware of
this?

ERROR: strace-6.17-r0 do_compile: Execution of '/srv/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/core2-64-poky-linux/strace/6.17/temp/run.do_compile.3198325' failed with exit code 1
...
| ../../sources/strace-6.17/src/listmount.c: In function 'print_mnt_id_req':
| ../../sources/strace-6.17/src/listmount.c:39:16: error: 'struct mnt_id_req' has no member named 'spare'
| 39 | if (req.spare) {
| | ^
| In file included from ../../sources/strace-6.17/src/listmount.c:9:
| ../../sources/strace-6.17/src/print_fields.h:384:37: error: 'struct mnt_id_req' has no member named 'spare'
| 384 | PRINT_VAL_X((where_).field_); \
| | ^
| ../../sources/strace-6.17/src/defs.h:1910:17: note: in definition of macro 'zero_extend_signed_to_ull'
| 1910 | (sizeof(v) == sizeof(char) ? (unsigned long long) (unsigned char) (v) : \
| | ^
| ../../sources/strace-6.17/src/print_fields.h:384:17: note: in expansion of macro 'PRINT_VAL_X'
| 384 | PRINT_VAL_X((where_).field_); \
| | ^~~~~~~~~~~
| ../../sources/strace-6.17/src/listmount.c:41:17: note: in expansion of macro 'PRINT_FIELD_X'
| 41 | PRINT_FIELD_X(req, spare);
| | ^~~~~~~~~~~~~
| ../../sources/strace-6.17/src/print_fields.h:384:37: error: 'struct mnt_id_req' has no member named 'spare'
| 384 | PRINT_VAL_X((where_).field_); \
| | ^
...

https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/2904
https://autobuilder.yoctoproject.org/valkyrie/#/builders/19/builds/2895
https://autobuilder.yoctoproject.org/valkyrie/#/builders/22/builds/2922
https://autobuilder.yoctoproject.org/valkyrie/#/builders/60/builds/2891

Thanks,
Mathieu

--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering