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. > > > > > > > > > Cheers, > > > > > > Richard > > > > > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232999): https://lists.openembedded.org/g/openembedded-core/message/232999 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]] -=-=-=-=-=-=-=-=-=-=-=-
