(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? rday
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229418): https://lists.openembedded.org/g/openembedded-core/message/229418 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]] -=-=-=-=-=-=-=-=-=-=-=-
