If spdx is generated without inheriting cve/vex classes (which is poky
default), only explicitly set CVE_STATUS fields are handled.
Calculated ones (e.g. from CVE_STATUS_GROUPS) are ignored.
Fix this by expanding the CVE_STATUS in spdx classes.
(From OE-Core rev: ead9c6a8770463c21210a57cc5320f44f7754dd3)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Setting SPDX_ARCHIVE_SOURCES and SPDX_ARCHIVE_PACKAGED makes no
difference when using the spdx-3.0 class. Move these two in the spdx-2.0
class since they are only used there.
(From OE-Core rev: 8ce06538c9cde0f09909a5a2e61ec10b0d35df49)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While two projects share one sstate cache, the 1st project builds kernel-devsrc without
setting SPDX_INCLUDE_SOURCES, and 2nd project build kernel-devsrc with setting
SPDX_INCLUDE_SOURCES = "1". Then the 2nd build failed with kernel-source not found
1. In 1st build
$ cd path-to-first-build
$ bitbake kernel-devsrc
2. In 2nd build, share sstate cache of 1st build and SPDX_INCLUDE_SOURCES = "1"
$ cd path-to-second-build
$ echo 'SSTATE_DIR = "path-to-first-build/sstate-cache"' >> conf/local.conf
$ echo 'SPDX_INCLUDE_SOURCES = "1"' >> conf/local.conf
$ bitbake kernel-devsrc
...
NOTE: copyhardlinktree path-to-second-build/tmp-glibc/work-shared/axxiaarm64/kernel-source to path-to-second-build/tmp-glibc/work/axxiaarm64-wrs-linux/kernel-devsrc/1.0/spdx/3.0.1/work/kernel-source
ERROR: Error executing a python function in exec_func_python() autogenerated:
...
0208: bb.note(f"copyhardlinktree {share_src} to {src_dir}")
*** 0209: oe.path.copyhardlinktree(share_src, src_dir)
...
tar: path-to-second-build/tmp-glibc/work-shared/axxiaarm64/kernel-source: Cannot open: No such file or directory
...
The recipe kernel-devsrc or the recipe to inherit kernelsrc.bbclass, they do not
have task do_shared_workdir but depends on virtual/kernel:do_shared_workdir.
In this situation(the ${S} == ${STAGING_KERNEL_DIR}), explicitly make do_create_spdx
depends on virtual/kernel:do_shared_workdir could fix the racing issue
(From OE-Core rev: b05ff49de1e58f5696e8ee28fceaf9319be70e1f)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Originally, while SPDX_INCLUDE_SOURCES = "1" [1], there is bug in scan
for gcc, libgcc in which the sources locates in work-share directory.
Copy source from ${WORKDIR} to ${SPDXWORK} did not satisfy the situation
while ${S} was not included in ${WORKDIR}
This commit aim to support SPDX include source for work-share directory
1. If is_work_shared_spdx, Copy source from ${S} to ${SPDXWORK},
normally the dest dir in ${SPDXWORK} has the same basename dir of ${S};
but for kernel source, rename basename dir 'kernel-source' to ${BP} (${BPN}-${PV})
2. For SPDX source copy, do hard link copy to save copy time
3. Move do_patch to no work shared situation along with do_unpack
4. Tweak task do_create_spdx dependencies to assure the patched source
in work share is ready for SPDX source copy
5. Remove bb.data.inherits_class('kernel', d) from is_work_shared_spdx,
the kernel source locates in 'work-shared', test kernel.bbclass is not
necessary
[1] https://docs.yoctoproject.org/dev/ref-manual/variables.html#term-SPDX_INCLUDE_SOURCES
(From OE-Core rev: 64454b1956a9b50d6c89a3f3d7c594c1272cb289)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <hongxu.jia@windriver.com>
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Loading a load of json files into a memory structure and stashing in a bitbake
variable is relatively anti-social making bitbake -e output hard to read for
example as well as other potential performance issues.
Defer loading of that data until it is actually needed/used in a funciton
where it is now passed as a parameter.
(From OE-Core rev: 6f21cc9598178288784ff451ab3c40b174c0ef3e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a create-spdx-* classes is processing documents, it needs to
find the document in a path that is related to the SSTATE_ARCH
when a packge is generated. The SSTATE_ARCH can be affected by
multilib configurations, resulting is something like armv8a-mlib.
When the image (or SDK) is being generated and the components are
collected, the system has no knowledge of the multilib arch and
will fail to find it, such as:
ERROR: meta-toolchain-1.0-r0 do_populate_sdk: No SPDX file found
for package libilp32-libgcc-dbg,
False sstate:libilp32-libgcc:armv8a-ilp32-mllibilp32-elf:14.1.0:r0:armv8a-ilp32:12:
sstate:libilp32-libgcc::14.1.0:r0::12:
Adding in the new SPDX_MULTILIB_SSTATE_ARCHS will provide a full
set of SSTATE_ARCHS including ones that contain the multilib
extension which will allow create-spdx-* to correctly find the
document it is looking for. This would also be valuable to any
other function doing a similar search through SSTATE_ARCH that may
have been extended with multilib configurations.
(From OE-Core rev: f1499c36c1054fc90f7b7268cc95285f2eca72f7)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves the bulk of the code in the spdx-common bbclass into library code
(From OE-Core rev: 3f9b7c7f6b15493b6890031190ca8d1a10f2f384)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a class to generate SPDX 3.0 output and an image class that is used
when generating images
(From OE-Core rev: b63f6f50458fc6898e4deda5d6739e7bf3639c15)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the SPDX_SUPPLIER variable to create-spdx-2.2 since it's format
only has meaning in SPDX 2.2 (SPDX 3 uses SPDX_PACKAGE_SUPPLIER with a
different format)
(From OE-Core rev: 628c1e04072178d2c8095e53d5f6600c45a2679f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is nicer as the normal return type is a list, so the calling code
doesn't have to deal with a None sometimes and a list others.
(From OE-Core rev: e200aa9cc6ceb8ca58ef239a1a5565287b38ce55)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since multiple versions of SPDX are available, use the version in the
path
(From OE-Core rev: 35c061a4514905b3ebbb7f0633a584927519445c)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves SPDX code that can be shared between different SPDX versions into
a common class
(From OE-Core rev: 769a390adc9fc0b52978abe0f19f885967af0117)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
