Hi Paul,

Thank you for looking into this.

> -----Ursprüngliche Nachricht-----
> Von: Paul Barker <[email protected]>
> Gesendet: Mittwoch, 30. September 2026 11:19
> An: Jonas Mark (BT-EL/ESW1) <[email protected]>; openembedded-
> [email protected]
> Cc: [email protected]; [email protected]; Simoes
> Ricardo (BT-EL/ESW2) <[email protected]>
> Betreff: Re: [PATCH] xorgproto: Set ALLOW_EMPTY for the main package
> 
> On Fri, 2026-09-18 at 16:18 +0200, [email protected] wrote:
> > From: Ricardo Simoes <[email protected]>
> >
> > When creating an SDK, the populate_sdk task relies on
> > COMPLEMENTARY_GLOB[dev-pkgs] to decide which packages to install
> [1].
> >
> > However, xorgproto is a header-only library, so bitbake does not
> emit
> > a main package. The only reference to the -dev package is an
> > RRECOMMENDS from the -dbg package, and such weak links are not
> honored
> > when installing complementary packages [2].
> >
> > Fix this by setting ALLOW_EMPTY for the xorgproto package. The main
> > package is now emitted, which makes ${PN}-dev reachable through the
> > complementary packages and lets recipes that depend on xorgproto be
> > built with the SDK.
> >
> > [1]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
> > openembedded.org%2Fopenembedded-core%2Ftree%2Fmeta%2Fclasses-
> recipe%2F
> >
> populate_sdk_base.bbclass%23n38&data=05%7C02%7Cmark.jonas%40de.bosch.c
> >
> om%7Caab8cf3183ca4239566f08df1ed3e999%7C0ae51e1907c84e4bbb6d648ee58410
> >
> f4%7C0%7C0%7C639263567650300241%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> >
> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> >
> fQ%3D%3D%7C0%7C%7C%7C&sdata=f9cFsWo%2BKHygCkswyUibFR5HSatvEJebVEPq6%2F
> > n%2BEso%3D&reserved=0 [2]
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .yoctoproject.org%2Fref-manual%2Fvariables.html%23term-
> COMPLEMENTARY_G
> >
> LOB&data=05%7C02%7Cmark.jonas%40de.bosch.com%7Caab8cf3183ca4239566f08d
> >
> f1ed3e999%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C639263567650353
> >
> 303%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMC
> >
> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> > bj372IW8yy1wIQ3J7oIMEXlv2knUrzqUGxtFSPrNhNg%3D&reserved=0
> >
> > Signed-off-by: Ricardo Simoes <[email protected]>
> > Signed-off-by: Mark Jonas <[email protected]>
> > ---
> >  meta/recipes-graphics/xorg-proto/xorgproto_2025.1.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-graphics/xorg-proto/xorgproto_2025.1.bb
> > b/meta/recipes-graphics/xorg-proto/xorgproto_2025.1.bb
> > index e187c56fbc..df09135e27 100644
> > --- a/meta/recipes-graphics/xorg-proto/xorgproto_2025.1.bb
> > +++ b/meta/recipes-graphics/xorg-proto/xorgproto_2025.1.bb
> > @@ -23,3 +23,6 @@ DEV_PKG_DEPENDENCY = ""
> >  RRECOMMENDS:${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
> >
> >  BBCLASSEXTEND = "native nativesdk"
> > +
> > +# This is a header only library - thus everything lands in the -dev
> > +package ALLOW_EMPTY:${PN} = "1"
> 
> Hi Mark, Ricardo,
> 
> I built the SDK for core-image-sato, and this already includes
> xorgproto-dev without applying this patch. I can see the package
> listed in the target manifest and I can see usr/include/X11/X.h in the
> target sysroot.
> 
> Could you provide a bit more info on the SDK you're building, any
> local config changes, etc, so I can reproduce the issue?

We were a little brief on our explanations in the commit message. So we sat 
down to create a hopefully reproducible demo of the problem.

For reproducing with used core-image-base and local.conf containing the 
following:

MACHINE ??= "qemuarm"
USER_CLASSES ?= "buildstats"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    HALT,${TMPDIR},100M,1K \
    HALT,${DL_DIR},100M,1K \
    HALT,${SSTATE_DIR},100M,1K \
    HALT,/tmp,10M,1K"
CONF_VERSION = "2"
DEPENDS:append:pn-base-files = " xorgproto"
RDEPENDS:base-files:append = " xorgproto"
DISTRO_FEATURES:forcevariable = "systemd usrmerge ext2 ipv4 vfat 
gobject-instrospection-data ldconfig multiarch"
DISTRO_FEATURES_OPTED_OUT = "*"

When we compile core-image-base then without our fix we get the following error:

$ bitbake core-image-base -c populate_sdk

NOTE: Executing Tasks
ERROR: core-image-base-1.0-r0 do_populate_sdk: Unable to install packages. 
Command 
'['/media/workspace/yocto_master/build/tmp/work/qemuarm-oe-linux-gnueabi/core-image-base/1.0/recipe-sysroot-native/usr/bin/opkg',
 '--volatile-cache', '-f', 
'/media/workspace/yocto_master/build/tmp/work/qemuarm-oe-linux-gnueabi/core-image-base/1.0/opkg-sdk-target.conf',
 '-t', 
'/media/workspace/yocto_master/build/tmp/work/qemuarm-oe-linux-gnueabi/core-image-base/1.0/temp/ipktemp/',
 '-o', 
'/media/workspace/yocto_master/build/tmp/work/qemuarm-oe-linux-gnueabi/core-image-base/1.0/sdk/image/usr/local/oe-sdk-hardcoded-buildpath/sysroots/cortexa15t2hf-neon-oe-linux-gnueabi',
 '--force-postinstall', '--prefer-arch-to-version', '--force-checksum', 
'install', 'packagegroup-base-extended', 'packagegroup-core-boot', 
'packagegroup-core-standalone-sdk-target', 'psplash', 'run-postinsts', 
'target-sdk-provides-dummy']' returned 1:
Solver encountered 1 problem(s):
Problem 1/1:
  - package packagegroup-core-boot-1.0-r0.qemuarm requires base-files, but none 
of the providers can be installed
  - conflicting requests
  - nothing provides xorgproto needed by base-files-3.0.14-r0.qemuarm

Solution 1:
  - do not ask to install a package providing packagegroup-core-boot



ERROR: Logfile of failure stored in: 
/media/workspace/yocto_master/build/tmp/work/qemuarm-oe-linux-gnueabi/core-image-base/1.0/temp/log.do_populate_sdk.3071259
ERROR: Task 
(/media/workspace/yocto_master/openembedded-core/meta/recipes-core/images/core-image-base.bb:do_populate_sdk)
 failed with exit code '1'
NOTE: Tasks Summary: Attempted 4485 tasks of which 4475 didn't need to be rerun 
and 1 failed.


Are you able to reproduce the problem using our setup above?

Is our fix the right way to tackle the build issue we see?

> 
> Best regards,
> 
> --
> Paul Barker

Cheers,
Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#247018): 
https://lists.openembedded.org/g/openembedded-core/message/247018
Mute This Topic: https://lists.openembedded.org/mt/121314987/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to