Re: [OE-core][PATCH v2 0/5] Implement SPDX for deploy tasks

["Mathieu Dubois-Briand" <mathieu.dubois-briand@bootlin.com>]

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
> <mathieu.dubois-briand@bootlin.com> 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