Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling
On 2026-03-14 6:28 a.m., Richard Purdie via lists.openembedded.org wrote: On Sat, 2026-03-14 at 10:00 +, Richard Purdie via lists.openembedded.org wrote: 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. Having said this all out loud, b) is the only realistic option so I've just sent a patch which does that. I don't like it but it is the least worst option I can see right now. Cheers, Richard Notes from patch review meeting: Joshua said that he'd write a test based on the native-sstate being machine independent. Here the sdk dummy packages should be independent of SDK machine. Is that right Joshua? Want a YP BZ ? ../Randy -- # Randy MacLeod # Wind River Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233259): https://lists.openembedded.org/g/openembedded-core/message/233259 Mute This Topic: https://lists.openembedded.org/mt/118311680/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling
On Sat Mar 14, 2026 at 10:47 AM CET, 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
> ---
Hi Richard,
I get some failures with this commit:
ERROR: core-image-sato-1.0-r0 do_populate_sdk: Error executing a python
function in exec_func_python() autogenerated:
...
File:
'/srv/pokybuild/yocto-worker/genericx86-64/build/layers/openembedded-core/meta/lib/oe/package_manager/__init__.py',
lineno: 529, function: create_packages_dir
0525:start = next
0526:
0527:for dep in pkgdeps:
0528:c = taskdepdata[dep][0]
*** 0529:manifest, d2 = oe.sstatesig.find_sstate_manifest(c,
taskdepdata[dep][2], taskname, d, multilibs)
0530:if not manifest:
0531:bb.fatal("No manifest generated from: %s in %s" % (c,
taskdepdata[dep][2]))
0532:if not os.path.exists(manifest):
0533:continue
File:
'/srv/pokybuild/yocto-worker/genericx86-64/build/layers/openembedded-core/meta/lib/oe/sstatesig.py',
lineno: 536, function: find_sstate_manifest
0532:if os.path.exists(manifest):
0533:return manifest, d2
0534:searched_manifests.append(manifest)
0535:bb.fatal("The sstate manifest for task '%s:%s' (multilib variant
'%s') could not be found.\nThe pkgarchs considered were: %s.\nBut none of these
manifests exists:\n%s"
*** 0536:% (taskdata, taskname, variant, d2.expand(",
".join(pkgarchs)),"\n".join(searched_manifests)))
0537:return None, d2
0538:
0539:def OEOuthashBasic(path, sigfile, task, d):
0540:"""
Exception: TypeError: sequence item 2: expected str instance, list found
https://autobuilder.yoctoproject.org/valkyrie/#/builders/4/builds/3385
https://autobuilder.yoctoproject.org/valkyrie/#/builders/8/builds/3416
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#233199):
https://lists.openembedded.org/g/openembedded-core/message/233199
Mute This Topic: https://lists.openembedded.org/mt/118311457/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling
On Sat, Mar 14, 2026 at 6:00 AM Richard Purdie < [email protected]> wrote: > On Sat, 2026-03-14 at 09:47 +, 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 > > 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]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling
On Sat, 2026-03-14 at 10:00 +, Richard Purdie via lists.openembedded.org wrote: > 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. Having said this all out loud, b) is the only realistic option so I've just sent a patch which does that. I don't like it but it is the least worst option I can see right now. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#233083): https://lists.openembedded.org/g/openembedded-core/message/233083 Mute This Topic: https://lists.openembedded.org/mt/118311680/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling
On Sat, 2026-03-14 at 09:47 +, 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 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]] -=-=-=-=-=-=-=-=-=-=-=-
