On Thu, 15 Jan 2026, Quentin Schulz wrote:
> 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?
after digging around, i found the following lines buried in the
internal distro file that i just started using, i wasn't sure of their
correctness so i commented them out and things are building:
=========================================================================
# License texts
#
=========================================================================
-COPY_LIC_MANIFEST = "1"
-COPY_LIC_DIRS = "1"
-PACKAGES += " ${PN}-lic"
-LICENSE_CREATE_PACKAGE = "1"
+# COPY_LIC_MANIFEST = "1"
+# COPY_LIC_DIRS = "1"
+# PACKAGES += " ${PN}-lic"
+# LICENSE_CREATE_PACKAGE = "1"
it's not clear to me what all of that *should* have said to have
properly built and packaged linux-libc-headers, but that's research
for another day. (wondering if there are any other booby traps in this
code.)
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229426):
https://lists.openembedded.org/g/openembedded-core/message/229426
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]]
-=-=-=-=-=-=-=-=-=-=-=-
