On Sat, 2026-03-14 at 09:47 +0000, Richard Purdie via lists.openembedded.org wrote: > Currently, the dummy SDK packages are re-running for different SDKMACHINE > values > when they should not. The usage of allarch is broken and not triggering the > right > PACKAGE_ARCH value due to the deferred nature of nativesdk. This was probably > broken when we switched to add deferred classes. > > To try and make this all more explict and less prone to breakage, switch to > calling > oe.utils.make_arch_independent() directly. > > Add the 'special' package architecture values to SSTATE_ARCHS so the system > cna properly > track them. > > Remove the pointless tasks we don't need from the dummy recipes, mark the > packagedata > as machine independent and then remove from the conflict list in > sstate.bbclass. > > Signed-off-by: Richard Purdie <[email protected]>
This patch fixes real issues with the way the dummy recipes are currently being handled. Unfortunately this change still isn't without issues, this is shown by the failure in meta-virtualization it introduces. It is starting to feel like I'm somehow targeting Bruce recently, sorry! The failure this patchset triggers in meta-virtualization is here: https://autobuilder.yoctoproject.org/valkyrie/#/builders/89/builds/3215 The reason is that it is doing this: recipes-core/meta/container-dummy-provides.bb:require recipes-core/meta/dummy-sdk-package.inc which is fine, I hadn't realised layers were using that but it should be something you can do. At first glance, the fix looks easy, just add: DUMMYSDK_PKGDATA_VARNAME = "PKGDATA_DIR" DUMMYSDK_EXTRASTAMP_VARNAME = "MACHINE" to the recipe. That doesn't account for the sstate.bbclass and sstatesig.py changes this patch is making though. I've never been happy at having to add these individually to the "feed" lists in the first place and another layer trying to do this illustrates why. I'm at a bit of a loss on what to do from here. Options could be: a) move the recipe to core and add another entry to sstate.bbclass/sstatesig.py . That doesn't help it anyone else does this b) Create some layer.conf variables which allow these to be defined/added generically. That would need careful manipulation of the hash variable dependencies to stop things rebuilding like crazy. c) Find a way for the core not to need this list hardcoded. That would be nicer and removes what looks like a horrible scaling issue we have right now I don't know how to do that. d) Something else I'm open to ideas, these changes are needed to unblock the spdx changes. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233081): https://lists.openembedded.org/g/openembedded-core/message/233081 Mute This Topic: https://lists.openembedded.org/mt/118311505/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
