Hi Robert, On 1/15/26 4:30 PM, Robert P. J. Day via lists.openembedded.org wrote:
(hoping that someone might have an idea of what weirdness might be happening here, or might have seen this before.) i've jumped into an existing YP build and am trying to untangle it, so here's the layout. all "walnascar" releases for: * STMicroelectronics (STM) layer meta-st-stm32mp for MACHINE defn * Poky * meta-openembedded for some basic networking stuff rather than try to build for the final image, i do as i always do and back off and try to build a simple core-image-minimal (or even simpler) and work up from there. given that the STM layer defines a linux-stm32mp recipe file and that's the preferred provider for "virtual/kernel", i started simple: $ bitbake linux-stm32mp ... snip ... WARNING: linux-libc-headers-6.12-r0 do_package: linux-libc-headers-lic package already existed in linux-libc-headers. ERROR: linux-libc-headers-6.12-r0 do_package: QA Issue: linux-libc-headers: Files/directories were installed but not shipped in any package: /usr/share /usr/share/licenses /usr/share/licenses/linux-libc-headers /usr/share/licenses/linux-libc-headers/COPYING /usr/share/licenses/linux-libc-headers/generic_GPL-2.0-only Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. linux-libc-headers: 5 installed and not shipped files. [installed-vs-shipped] ERROR: linux-libc-headers-6.12-r0 do_package: Fatal QA errors were found, failing task. ERROR: Logfile of failure stored in: /home/rpjday/BOARDS/nexus/walnascar/core_plus_nexus/build/tmp/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/linux-libc-headers/6.12/temp/log.do_package.1893820 ERROR: Task (/home/rpjday/layers/oe/walnascar/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_6.12.bb:do_package) failed with exit code '1' OK, i find that puzzling, that a well-established recipe like linux-libc-headers could have such a blatant packaging flaw. i went looking in the STM layer and in the local layers for anything that might have modified that recipe with a bbappend file or something, but found nothing. and then i ran across this little nugget. the STM layer insists that it is compatible with walnascar, so that's the branch i checked out. but when i looked closer, their kernel recipe file is linux-stm32mp_6.6.bb. that is, 6.6, not 6.12 that one would find in the OE layer for the walnascar branch. so it seems that the build is trying to build a 6.6 kernel based on the STM layer, but is trying to build 6.12 of linux-libc-headers based on the poky layer. if i go to the STM layer and check out the scarthgap branch, sure enough, it has the same linux-stm32mp_6.6.bb, so it seems STM bumped their layer compatibility from scarthgap to walnascar but never updated their kernel recipe. is that a possible explanation as to what is going on here?
You can have kernel headers newer than the kernel recipes you're building. The kernel *should* report whether it actually supports something when requested by userspace (e.g. ioctl, syscalls). The kernel headers are supposed to be stable API/ABI as far as I remember, so newer headers only mean you can use newer features (if your kernel supports it).
We also have multiple linux-yocto recipes which are older than the linux-libc-headers, that's not an issue. If you look at meta-cherry-es, you'll see you're building a 6.1 kernel for Jaguar and Tiger while linux-libc-headers is 6.6.
The only limitation is the minimum kernel supported by glibc. This is handled by the OLDEST_KERNEL variable (which is 5.15 right now).
As for the issue, I **think** it's been reported a few times but the vague recollection I have of it was that it goes away after cleaning and that the fix wasn't straightforward?
Cheers, Quentin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229422): https://lists.openembedded.org/g/openembedded-core/message/229422 Mute This Topic: https://lists.openembedded.org/mt/117280937/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
