On Sat, Mar 14, 2026 at 6:00 AM Richard Purdie < [email protected]> wrote:
> 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! > It's probably more that I'm doing strange and niche things :) I see your patch, I'll pull it in shortly, thanks for the fixup, I would have taken ages to figure that out! Bruce > > 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 > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233087): https://lists.openembedded.org/g/openembedded-core/message/233087 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]] -=-=-=-=-=-=-=-=-=-=-=-
