On Thu, Mar 12, 2026 at 12:02 PM Joshua Watt <[email protected]> wrote:
>
> On Thu, Mar 12, 2026 at 10:43 AM Joshua Watt <[email protected]> wrote:
> >
> > On Thu, Mar 12, 2026 at 10:06 AM Joshua Watt <[email protected]> wrote:
> > >
> > > On Thu, Mar 12, 2026 at 9:58 AM Richard Purdie
> > > <[email protected]> wrote:
> > > >
> > > > On Thu, 2026-03-12 at 08:24 -0600, Joshua Watt wrote:
> > > > > On Thu, Mar 12, 2026 at 5:59 AM Richard Purdie
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via
> > > > > > lists.openembedded.org wrote:
> > > > > > > The dummy SDK packages do not need SPDX support, and since they
> > > > > > > play
> > > > > > > some games with allarch that cause problems, it's simplest to
> > > > > > > disable
> > > > > > > their SPDX output.
> > > > > > >
> > > > > > > Signed-off-by: Joshua Watt <[email protected]>
> > > > > > > ---
> > > > > > > meta/recipes-core/meta/dummy-sdk-package.inc | 1 +
> > > > > > > 1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc
> > > > > > > b/meta/recipes-core/meta/dummy-sdk-package.inc
> > > > > > > index bf453cac9b..71e788b0b9 100644
> > > > > > > --- a/meta/recipes-core/meta/dummy-sdk-package.inc
> > > > > > > +++ b/meta/recipes-core/meta/dummy-sdk-package.inc
> > > > > > > @@ -4,6 +4,7 @@ LICENSE = "MIT"
> > > > > > > PACKAGE_ARCH = "all"
> > > > > > >
> > > > > > > inherit allarch
> > > > > > > +inherit nospdx
> > > > > > >
> > > > > > > INHIBIT_DEFAULT_DEPS = "1"
> > > > > >
> > > > > > I know why you did this, but after thinking about this, I'm worried
> > > > > > and
> > > > > > I'm not sure this is the right move.
> > > > > >
> > > > > > The SDK dummy packages are "odd" but they are actual package files
> > > > > > that
> > > > > > are generated and would be present in manifests and as such, if
> > > > > > they're
> > > > > > missing from the SPDX manifests and docs, this is going to raise
> > > > > > questions. I appreciate they don't have content and their main use
> > > > > > is
> > > > > > their 'provides'.
> > > > > >
> > > > > > Taking a step back, we do support generic/multiple levels of package
> > > > > > arch and since we support that, the SPDX code does need to handle
> > > > > > that
> > > > > > too. I'm therefore starting to worry that SPDX can't cope with the
> > > > > > multiple package levels. Can you remind me what the issue is with
> > > > > > the
> > > > > > "all" arch here?
> > > > >
> > > > > The problem is specifically the anonymous python that does:
> > > > >
> > > > > d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
> > > > >
> > > > > Which seems specifically intended to bypass the allarch logic in a
> > > > > weird way. It's specifically doing this to put the package in a place
> > > > > no-one can find it (this includes SPDX); I didn't think it provided
> > > > > much value hence disabling it, but looking closer, I think we can do:
> > > > >
> > > > > SSTATE_MULTILIB_SSTATE_ARCHS:append = " ${SDK_PACKAGE_ARCH}"
> > > > >
> > > > > in create-spdx-sdk-3.0.bbclass and that should fix it. I'll try it.
> > > >
> > > > That code was to put these packages into their own separate feed.
> > > > Specifically:
> > > >
> > > > meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb:DUMMYARCH =
> > > > "buildtools-dummy-${SDKPKGSUFFIX}"
> > > > meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb:DUMMYARCH =
> > > > "sdk-provides-dummy-${SDKPKGSUFFIX}"
> > > > meta/recipes-core/meta/dummy-sdk-package.inc:
> > > > d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
> > > > meta/recipes-core/meta/target-sdk-provides-dummy.bb:DUMMYARCH =
> > > > "sdk-provides-dummy-target"
> > > >
> > > > so there are separate package feeds being created and then the SDK code
> > > > can select which package feeds it wants to use for a given
> > > > configuration/recipe.
> > > >
> > > > That isn't to bypass allarch but just to customise the end package feed
> > > > naming and allow different forms of SDK to be built by bringing in the
> > > > different package combinations.
> > > >
> > > > My worry is that the SPDX code isn't going to handle the scenario where
> > > > PACKAGE_ARCH is changed (for example for a specialist graphics stack)
> > > > and that one of our general features will be lost.
> > >
> > > Right, SPDX is (supposed) to do whatever sstate does, so if it works
> > > for sstate it works for SPDX. The problem isn't that this code does
> > > the arch changing (specifically), it's that it changes the arch to an
> > > arbitrary one that isn't part of the normal package search order (on
> > > purpose), and then expects everyone to manually add in that arch when
> > > they need the package (which, SPDX was _not_ doing but all of the
> > > other SDK code obviously is). I think my proposed fix is thus correct
> > > and I will test it which should cover this corner case.
> > >
> > > In general, I think most packages are handled correctly because again,
> > > SPDX does whatever sstate does, and SPDX even respects SSTATE_ARCHS
> > > which is how I think other recipes would deal with a similar
> > > situation. However, the SDKs are different specifically because they
> > > expect SDK_PACKAGE_ARCH to be respected by anything dealing with the
> > > sdk generation code, which is what was missing in SPDX.
> >
> > Hang on, I think I'm getting this confused with a different problem.....
>
> Ok, I remember this one correctly now (who needs AI to
> hallucinate....). I think the correct thing to do here is to add:
>
> do_create_recipe_spdx[vardeps] += "PACKAGE_ARCH"
>
> because it's not rebuilding when this recipe changes PACKAGE_ARCH. The
> other SPDX tasks are because of an implicit dependency on PACKAGE_ARCH
> that re-triggers them. In the back of my mind I seem to recall we
> maybe didn't want to do this for some reason, but PACKAGE_ARCH isn't
> in BB_*_IGNORE_VARS so maybe I'm just mis-remembering.
>
> Anyway, if this fix seems correct I'll make it.
After trying this it doesn't work either. I'll write down my analysis
of why and maybe we can figure it out:
First of all, the SPDX code writes out SPDX files based on their
SSTATE_PKGARCH (which is why I say SPDX behaves like sstate). This was
done back in 2023 [1]. SSTATE_PKGARCH is in BB_HASHEXCLUDE_COMMON, so
changes in SSTATE_PKGARCH do not cause SPDX code to rebuild; I think
this is intentional, but I'm not sure.
nativesdk-sdk-provides-dummy sets `PACKAGE_ARCH = "all"` and inherits
allarch, but in sstate.bbclass, there is this:
elif bb.data.inherits_class('nativesdk', d):
d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
So, SSTATE_PKGARCH is set to "${SDK_ARCH}_${SDK_OS}"
After this, the anon python in dummy-sdk-package.inc set PACKAGE_ARCH
to ${DUMMYARCH}, which in this case is always
"sdk-provides-dummy-nativesdk" -- FWIW, this really wants to look like
the culprit but actually is irrelevant to the problem.
Now, the problem is that there is nothing to retrigger running
do_create_recipe_spdx() when SDKMACHINE changes. This task (on
purpose) has pretty minimal dependencies, but specifically nothing
related to SDKMACHINE changing re-triggers this task. Thus consider
the following command sequence which will trigger the bug (with a
clean tmp dir):
SDKMACHINE=x86_64 bitbake nativesdk-sdk-provides-dummy &&
SDKMACHINE=i686 bitbake -fc create_spdx nativesdk-provided-dummy
In this case, the first command runs and puts the
nativesdk-sdk-provides-dummy do_create_recipe_spdx files in
"${SDK_ARCH}_${SDK_OS}" ("x86_64_linux"). The second command reruns
do_create_spdx, but because SDKMACHINE doesn't factor into the
taskhash of do_create_recipe_spdx, it does not rerun that task,
assuming it's fine. Now, do_create_spdx cannot find the required SPDX
file, because "x86_64_linux" is not in sstate search path
(SSTATE_ARCHS) anymore.
Maybe allarch.bbclass and nativesdk.bbclass just don't interact well
(esp. when sstate.bbclass appears to be making some assumptions about
those two)? I did some digging and there are not many other recipes
that inherit both allarch and nativesdk, however the other one I found
was ca-certificates, and indeed it has the same error when building
nativesdk-ca-certificates and switching SDKMACHINE.
I'm at a loss for where the actual bug is here. If it's true that SPDX
should be using SSTATE_PKGARCH, I cannot see what it's doing wrong
here (as I said, it more or less just copies what sstate does).
I'm kinda surprised we don't have other sstate problems with this
recipe, given all of this, but maybe sstate isn't hard failing on
missing files.
[1]: b2db10e966 ("create-spdx/sbom: Ensure files don't overlap between
machines")
>
>
> >
> > >
> > > >
> > > > Cheers,
> > > >
> > > > Richard
> > > >
> > > >
> > > >
> > > >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#233004):
https://lists.openembedded.org/g/openembedded-core/message/233004
Mute This Topic: https://lists.openembedded.org/mt/118246396/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
