On Mon Jun 22, 2026 at 11:14 PM CEST, Joshua Watt wrote: > On Sat, Jun 20, 2026 at 11:45 PM Mathieu Dubois-Briand > <[email protected]> wrote: >> >> On Thu Jun 18, 2026 at 5:38 PM CEST, Joshua Watt via lists.openembedded.org >> wrote: >> > The SPDX use case for file system image has been well defined since SPDX >> > was first implemented, however there has always been a desire to also >> > express SPDX output for other non-image deliverables (primarily, those >> > that have a do_deploy task or similar). These types of tasks cannot >> > easily use the traditional method of having a separate SPDX task that >> > runs to create their SPDX output as this causes lots of problems with >> > the way dependencies are specified. Instead, it is desirable for these >> > tasks to directly produce SPDX output that can be consumed by other >> > tasks that depend on them. >> > >> > This patch series adds support for this. Any sstate task that starts >> > with "do_deploy" can now be added to the SPDX_DEPLOY_TASKS list and it >> > will run a postfunc to generate SPDX output that describes what is being >> > deployed. For classical do_deploy tasks, this is setup to be easy by >> > automatically capturing all the deployed output files in the SPDX data, >> > but other tasks can be added as well. >> > >> > Finally, the do_create_image_spdx task is removed and replaced with a >> > SPDX deploy postfunc using this new system. This means that any task >> > that depends on do_image_complete will automatically also get the SPDX >> > output for the image, simplifying the dependency handling. >> > >> > V2: Fixed SPDX documents missing at SBoM creation time when the >> > documents were not a direct dependency of the SBoM, and were present in >> > a sstate object. Previously, these sstate objects were not restored >> > because they were "covered" by the later sstate tasks, but now they are >> > restored if they are depended on by a task that creates SPDX output. >> > >> >> Hi Joshua, >> >> Thanks for the new version, but I'm still seeing some errors on the >> autobuilder: >> >> ERROR: systemd-boot-259.5-r0 do_deploy_setscene: Recipe systemd-boot is >> trying to install files into a shared area when those files already exist. >> The files and the manifests listing them are: >> >> /srv/pokybuild/yocto-worker/wic/build/build/tmp/deploy/spdx/3.0.1/core2-32/by-task/systemd-boot:do_deploy.spdx.json >> (matched in manifest-qemux86-systemd-boot.deploy) >> >> /srv/pokybuild/yocto-worker/wic/build/build/tmp/deploy/spdx/3.0.1/core2-32/deploy/systemd-boot-do_deploy-deploy.spdx.json >> (matched in manifest-qemux86-systemd-boot.deploy) >> >> /srv/pokybuild/yocto-worker/wic/build/build/tmp/deploy/spdx/3.0.1/core2-32/by-spdxid-hash/c0/c00d8889d28fc9521178ce481c8e76cfc116eb5f57bb1c1bb7d9d98271b16e07.spdx.json >> (matched in manifest-qemux86-systemd-boot.deploy) >> Please adjust the recipes so only one recipe provides a given file. >> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/15/builds/3927 >> >> 2026-06-20 11:34:04,962 - oe-selftest - INFO - >> spdx.SPDX30Check.test_baremetal_helloworld (subunit.RemotedTestCase) >> 2026-06-20 11:34:04,963 - oe-selftest - INFO - ... FAIL >> ... >> 2026-06-20 11:34:04,963 - oe-selftest - INFO - >> testtools.testresult.real._StringException: Traceback (most recent call >> last): >> File >> "/srv/pokybuild/yocto-worker/oe-selftest-debian/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/spdx.py", >> line 155, in test_baremetal_helloworld >> self.check_objset_missing_ids(objset) >> File >> "/srv/pokybuild/yocto-worker/oe-selftest-debian/build/layers/openembedded-core/meta/lib/oeqa/selftest/cases/spdx.py", >> line 73, in check_objset_missing_ids >> self.assertTrue( >> File "/usr/lib/python3.11/unittest/case.py", line 715, in assertTrue >> raise self.failureException(msg) >> AssertionError: False is not true : The following SPDXIDs are unresolved: >> >> http://spdxdocs.org/openembedded-alias/by-doc-hash/de503ed2af15b13f05a8f9025f181bbb421f080060947c2e31b480bd76d017b7/linux-libc-headers/UNIHASH/recipe/linux-libc-headers >> >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/4105 >> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3936 > > Mathieu, I looked at these links, but they do not seem to be related > to the error you listed; are they perhaps wrong? If so can you provide > the correct links? > > Thanks >
I believe the links are correct, but maybe the fact that we have unrelated (weston) failures is a bit misleading. Yet I confirm we have test_baremetal_helloworld failures: - lines 7695 / 7803 of https://autobuilder.yoctoproject.org/valkyrie/?#/builders/35/builds/4105/steps/15/logs/stdio - lines 7330 / 7478 of https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/3936/steps/15/logs/stdio 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 (#239342): https://lists.openembedded.org/g/openembedded-core/message/239342 Mute This Topic: https://lists.openembedded.org/mt/119870457/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
