linux/poky.git/meta/classes/create-spdx-3.0.bbclass, branch master-next

create-spdx-3.0: add SPDX_LICENSES to SPDX3_DEP_FILES

2025-10-27T11:37:43+00:00

If we have changes on SPDX_LICENSES content we ended up building invalid sstate-cache archives. The default value for the SPDX_LICENSES is the file meta/files/spdx-licenses.json but this file don't use the bitbake fetcher and because of this their checksum is not validated. So we need to add this file to the build dependency chain of the SPDX. For example, currently we have bump from 3.24.0 to 3.27.0 on master-next for the file meta/files/spdx-licenses.json. Since the file content is not taken into account, we end up creating invalid sstate-cache artifacts on the autobuilder on master-next builds. This created sstate-cache artifacts will also be available to master branch users that are using the upstream sstate-cache mirror. If someone is using the public mirror but still following the master branch they will encounter something like the following error which this change aims to resolve. | ERROR: initramfs-rootfs-image-1.0-r0 do_create_image_sbom_spdx: http://spdxdocs.org/openembedded-alias/by-doc-hash/57301e8063a8bf25308226271627db2b78675cda9f648c5c6c14a2b9c18f48dc/zlib/UNIHASH/license/3_27_0/Zlib not found in /work/build/tmp/deploy/spdx/3.0.1/armv8a/by-spdxid-hash/57/57301e8063a8bf25308226271627db2b78675cda9f648c5c6c14a2b9c18f48dc.spdx.json (From OE-Core rev: 10669f6f615058293671fb16454601580b7b34e9) Signed-off-by: Jose Quaresma Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

spdx-3.0: replace SPDX3_LIB_DEP_FILES with SPDX3_DEP_FILES

2025-10-27T11:37:43+00:00

We can have more files types in the chain of dependencies and not just libs. (From OE-Core rev: f400ba75f2d7987abb177a43f94874a7fdc1ec0a) Signed-off-by: Jose Quaresma Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

spdx30: Provide software_packageUrl field in SPDX 3.0 SBOM

2025-05-08T09:28:18+00:00

Define var-SPDX_PACKAGE_URL to provide software_packageUrl field [1][2] in SPDX 3.0 SBOM, support to override with package name SPDX_PACKAGE_URL: Currently, the format of purl is not defined in Yocto, set empty for now until we have a comprehensive plan for what Yocto purls look like. But users could customize their own purl by setting var-SPDX_PACKAGE_URL [1] https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Properties/packageUrl/ [2] https://spdx.github.io/spdx-spec/v3.0.1/annexes/pkg-url-specification/ (From OE-Core rev: c8e6953a0b6f59ffca994c440069db39e60b12d2) Signed-off-by: Hongxu Jia Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx3: support to override the version of a package in SBOM 3

2025-03-24T17:29:16+00:00

By default, still use ${PV} as the the version of a package in SBOM 3 $ bitbake acl $ jq . tmp/deploy/spdx/3.0.1/core2-64/packages/package-acl.spdx.json ... { "type": "software_Package", ... "name": "acl", "software_packageVersion": "2.3.2" }, ... Support to override it by setting SPDX_PACKAGE_VERSION, such as set SPDX_PACKAGE_VERSION = "${EXTENDPKGV}" in local.conf to append PR to software_packageVersion in SBOM 3 $ echo 'SPDX_PACKAGE_VERSION = "${EXTENDPKGV}"' >> conf/local.conf $ bitbake acl $ jq . tmp/deploy/spdx/3.0.1/core2-64/packages/package-acl.spdx.json ... { "type": "software_Package", ... "name": "acl", "software_packageVersion": "2.3.2-r0" }, ... (From OE-Core rev: e6ff5f4d870624795bd36572f5c2bfeec90d83ce) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

lib: Fix dependencies on SPDX code

2025-03-11T21:29:50+00:00

The SPDX library code was being ignored from taskhash calculations due to accidentally being omitted from BBIMPORTS. This meant that changes in the code or dependent variables would not cause the task to rebuild correctly. In order to add spdx_common, convert the `Dep` object from a named tuple to a frozen dataclass. These function more or less equivalently, but the bitbake code parser cannot handle named tuples. Finally, the vardepsexclude that used to be present on the recipe tasks needs to be moved to the python code in order for the variables to be correctly ignored. Several unused exclusions were removed (From OE-Core rev: eb597bf61cbcb0a4d43149404c93eec0894fb4c7) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

classes: create-spdx: Fix variable dependencies

2024-12-05T17:07:10+00:00

A few variable dependencies were incorrect from the SPDX tasks, which prevented rebuilds from occurring, or caused them to occur when they should not. (From OE-Core rev: 38a5dd136b3a3713e63d23598011efe1c4b0f459) Signed-off-by: Joshua Watt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

spdx: Fix SPDX tasks not running when code changes

2024-11-23T14:44:54+00:00

The SPDX code makes heavy use of python classes. While this works very well, the bitbake dependency parser is unable to understand how to deal with them, and thus changes to the class code do not cause rebuilds to occur. To correct this, add the library files that include SPDX code as file checksums for the SPDX tasks. If this method works well for SPDX, we will look at implementing something similar in the bitbake dependency parser that should allow correct checksums without having to explicitly add them to each class. (From OE-Core rev: 6ac3033b77a0d1f7ab15801c5c65931adede3923) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

create-spdx-{2.2,3.0}: fix do_create_spdx dependency while spdx include sources

2024-11-01T12:07:12+00:00

Call function ${@create_spdx_source_deps(d)} or ${create_spdx_source_deps(d)} along with addtask not working, use task do_create_spdx flag 'depends' to instead Move function create_spdx_source_deps to spdx-common.bbclass for both of create-spdx-2.2.bbclass and create-spdx-3.0.bbclass (From OE-Core rev: dda4b7ccd416ef370634babd150e944f2aa9116e) Signed-off-by: Hongxu Jia Reviewed-by: Joshua Watt Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

create-spdx-3.0: Upgrade to SPDX 3.0.1

2024-09-30T16:07:18+00:00

Upgrades the SPDX 3.0 implementation from 3.0.0 -> 3.0.1. This version introduced some breaking changes. Effectively, 3.0.0 was a pre-release version that we do not need to support any longer. (From OE-Core rev: 7e6509a19f6146f0dad0be7037ff4b3268d0128c) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

create-spdx-3.0/populate_sdk_base: Add SDK_CLASSES inherit mechanism to fix tarball SPDX manifests

2024-07-26T11:28:42+00:00

Currently, "tarball" sdk based recipes don't generate SPDX manifests as they don't include the rootfs generation classes. Split the SPDX 3.0 image class into two so the SDK components can be included where needed. To do this, introduce an SDK_CLASSES variable similar to IMAGE_CLASSES which the SDK code can use. Migrate testsdk usage to this. Also move the image/sdk spdx classes to classes-recipe rather than the general classes directory since they'd never be included on a global level. For buildtools-tarball, it has its own testsdk functions so disable the class there as a deferred inherit would overwrite it. (From OE-Core rev: 662396533177b72cc1d83e95841b27f7e42dcb20) Signed-off-by: Richard Purdie