The issue encountered is about local stos builds failing (when these builds are
preceded by a local SoC OS or MOS build). Essentially, the failure is seen when
building two different configs with shared state, one where gcc-cross-<arch> has a dependency
and one where it doesn't (specifically, one where the abicheck class in meta-binaryaudit
is inherited and one where it isn't). Hence, the task signatures change but a rerun of those said tasks
does not occur. The result is that when the config with the dependency is built and then the one without
is built, due to incorrect dependencies, the SPDX manifest creation stage errors out.
create-spdx relies on BB_TASKDEPDATA to get dependencies and then adds that variable to
vardepsexclude. A change in dependencies therefore, does not result in a
re-execution of the tasks. This commit adds an explicit dependency on DEPENDS which influences
BB_TASKDEPDATA and triggers reruns for new config builds having different dependencies.
(From OE-Core rev: 1a0dac4f45c489d107d9627d3c3ab7ccf1c60920)
Signed-off-by: Maanya Goenka <maanyagoenka@microsoft.com>
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves the downloaded items from SRC_URI into separate packages in the
recipe document. This is much better than the previous implementation
because:
1) It can report multiple download locations in SRC_URI, instead of
just the first one reported.
2) It prevents the assumption that the source files listed in the
recipe are the exact file from the source URL; in particular, files
that come from file:// SRC_URI entries, and source files that have
been patched were problematic, since these aren't from the upstream
source.
3) It allows the checksums to be specified
(From OE-Core rev: 1dd4369b3638637a2cbba2a3c37c6b6f4df335cd)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change adds a new variable to track which recipe variables
are added as SPDX Annotations.
Usage: add SPDX_CUSTOM_ANNOTATION_VARS = <some recipe variable>
The recipe spdx json will contain an annotation stanza that looks
something like this:
"annotations": [
{
"annotationDate": "2023-02-13T19:44:20Z",
"annotationType": "OTHER",
"annotator": "Tool: oe-spdx-creator - 1.0",
"comment": "CUSTOM_VARIABLE=some value or string"
},
(From OE-Core rev: 33ced8338f0facb412b5f24cf9df4a84226a2a94)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Per feedback from users, remove the top level image SPDX file and the
JSON index file from DEPLOYDIR. Having these files here is confusing to
end users because these files are not very useful by themselves, and
having them in DEPLOYDIR makes it unclear which they should be using.
(From OE-Core rev: 4e081802ecb352e0a300a98c924354f8393e4163)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
if a source is using work-shared but isn't a kernel,
like for instance llvm-source from meta-clang, share_src was
previously undefined leading to a crash of the python code.
Default to WORKDIR and just override it in case the source being
a kernel recipe.
Additionally changes the variable names in the following, as
they imply that it's only about the kernel, which is not the case
in every case
(From OE-Core rev: 34fa68a0b07328c4ed4eef81f8cde80137a91f18)
Signed-off-by: Konrad Weihmann <kweihmann@witekio.com>
On-behalf-of: Avnet Embedded <AvnetEmbedded@avnet.eu>
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In expectation of SPDX 3.0 support, move the create-spdx.bbclass ->
create-spdx-2.2.bbclass. The create-spdx.bbclass class still exists and
can be used if a user doesn't care about which specific version of SPDX
they get.
(From OE-Core rev: 9ec01fe3e59be66331c14ab5391ecb0b6f140c22)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
