Yocto build issues when using create-spdx-3.0.bbclass

I noticed that in recent Toradex BSP 7.5.0, there is the bbclass to build SBOM in the format SPDX v3.0.

We want to use that for our image (for Colibri-IMX8x), but the whole thing has 2 issues, where 1 of them is likely toradex specific:

I add this configuration to my local.conf:

INHERIT:remove = “create-spdx”
INHERIT:append = " create-spdx-3.0 "

Issue 1 (Likely Toradex specific):

When building linux-toradex, the function do_populate_lic fails.

WARNING: linux-toradex-6.6+git-r0 do_populate_lic: Could not copy license file /home/xxx…/build/tmp/work/nox_imx8x-tdx-linux/linux-toradex/6.6+git/git/COPYING to /home/xxx…/build/tmp/work/nox_imx8x-tdx-linux/linux-toradex/6.6+git/license-destdir/nox_imx8x/linux-toradex/COPYING: [Errno 2] No such file or directory: ‘/home/xxx…/build/tmp/work/nox_imx8x-tdx-linux/linux-toradex/6.6+git/git/COPYING’
ERROR: linux-toradex-6.6+git-r0 do_populate_lic: QA Issue: linux-toradex: LIC_FILES_CHKSUM points to an invalid file: /home/xxx…/build/tmp/work/nox_imx8x-tdx-linux/linux-toradex/6.6+git/git/COPYING [license-checksum]
ERROR: linux-toradex-6.6+git-r0 do_populate_lic: Fatal QA errors were found, failing task.
ERROR: Logfile of failure stored in: /home/xxx…/build/tmp/work/nox_imx8x-tdx-linux/linux-toradex/6.6+git/temp/log.do_populate_lic.3602930
ERROR: Task (/home/xxx…/build/../layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex_6.6-2.2.x.bb:do_populate_lic) failed with exit code ‘1’

This is likely becausedo_create_spdx seems to move the source from ../git to ../spdx/3.0.1/work/git

I was able to workaround this adding this to my .bbappend:

python do_populate_lic:prepend() {
    import os, glob
    s = d.getVar('S')
    copying = os.path.join(s, 'COPYING')
    if not os.path.exists(copying):
        pattern = os.path.join(d.getVar('WORKDIR'), 'spdx', '*', 'work', 'git', 'COPYING')
        matches = glob.glob(pattern)
        if matches:
            spdx_git = os.path.dirname(matches[0])
            bb.warn(f"do_populate_lic: {s} is empty, symlinking from {spdx_git}")
            if os.path.islink(s):
                os.remove(s)
            elif os.path.isdir(s):
                os.rmdir(s)
            os.symlink(spdx_git, s)
        else:
            bb.warn(f"do_populate_lic: {s} is empty and no spdx source found either!")
}

This is only a workaround, IMO there should be a proper fix addressing this.

Issue 2:

It seems that do_create_spdx consumes a lot more memory for 3.0 than for 2.2.

We are using a Ryzen 5900X with 64GB of RAM as a build server, so we build on 24Threads. When the SPDX is generated, we run out of memory quickly and have to restart the build several times to complete it. I can see the amount of RAM beeing used growing steady from ~2GB to almost full, then the processes in yocto start to fail with error 137.

Example:

ERROR: Task (/home/xxx.../build/../layers/openembedded-core/meta/recipes-bsp/u-boot/libubootenv_0.3.5.bb:do_create_spdx) failed with exit code ‘137’

After that, no more processes are spawned/build is soft-cancelled, and if the others complete, the RAM usage goes down again.

Not sure if this is expected to happen with SPDX 3.0, AI suggested that it consumes way more memory than generating SPDX 2.2?

Is anyone able to reproduce this two issues?

Thanks and regards,

Simon

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I can help you with information about SBOM generation in Toradex BSP. Based on the available documentation, Toradex provides SBOM support for Torizon OS builds(1).

Current SBOM Support in Toradex

Toradex currently publishes both complete and actionable SBOMs for every Torizon release(1). The SPDX SBOM is generated by Yocto’s create-spdx class, which lists Yocto package names and versions based on the PN and PV variables, and includes every file in the filesystem with its hash(1).

SBOM Generation Process

For Torizon OS builds, SBOMs are automatically generated and published to Toradex’s Artifactory instance(1). The SPDX SBOM files are located at specific paths for each System On Module (SoM) and Torizon release(1).

You can download and parse SBOM documents using standardized tooling. For example, using cve-bin-tool(1):

$ wget "https://artifacts.toradex.com:443/artifactory/<sbom-file-path>" -O sbom.spdx
$ cve-bin-tool --sbom spdx --sbom-file sbom.spdx
$ wget "https://artifacts.toradex.com:443/artifactory/<sbom-file-path>" -O bom.json
$ cve-bin-tool --sbom cyclonedx --sbom-file bom.json

(1)

Platform Information Needed

To provide more specific guidance for your Colibri iMX8X setup, could you specify which exact version of the BSP you are running? You can use the tdx-info command to get detailed information about your system configuration: Getting Device Information with Tdx-Info | Toradex Developer Center

Building with Reduced RAM Usage

For memory-intensive builds, you can limit the number of threads used by BitBake and Make to reduce RAM usage(2):

$ PARALLEL_MAKE="-j 4" BB_NUMBER_THREADS="6" bitbake <image>

(2)

The PARALLEL_MAKE variable controls the number of threads used by make, while BB_NUMBER_THREADS controls the number of threads used by bitbake(2).

Additional Resources

For more information on vulnerability scanning and management with SBOMs, refer to the detailed Torizon vulnerability reports documentation(1).

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

I don’t have the tdx-info tool installed. here are my layers:

cat /etc/buildinfo
Build Configuration:
DISTRO = nox-devel
DISTRO_VERSION = 7.5.0-devel-20260213053951-nox.1
DISTRO_CODENAME = scarthgap

Layer Revisions:
meta-freescale    = scarthgap:902dde8c5bd29bb507ac8d37772565a6c9ab77cd
meta-freescale-3rdparty = scarthgap:70c83e96c7f75e73245cb77f1b0cada9ed4bbc6d
meta-nox          = scarthgap:4c41430dd2043081c0e4b28a3e4d9a4245a99630 – modified
meta-filesystems  = scarthgap:2b26d30fc7f478f5735d514f0c1bc28f6a4148b6
meta-networking   = scarthgap:2b26d30fc7f478f5735d514f0c1bc28f6a4148b6
meta-oe           = scarthgap:2b26d30fc7f478f5735d514f0c1bc28f6a4148b6
meta-python       = scarthgap:2b26d30fc7f478f5735d514f0c1bc28f6a4148b6
meta-secure-imx   = scarthgap-simon:8b41f2698a131825eb10c5b29e7989ff2faafe8f
meta-swupdate     = scarthgap:226701adf0f7c8ed08d4d6a7783e88d34ef2d5e9
meta              = scarthgap:6988157ad983978ffd6b12bcefedd4deaffdbbd1
meta-toradex-bsp-common = patched-3fead3b1e2dcf83e086647b4f0e4185a94f12f11:22a7f0c7cb74ba6e1d6a2311bd25f266fdd5d63a
meta-toradex-distro = scarthgap-7.x.y:65a1511acecc37d9e9252c588bc57ac7944c92f5
meta-toradex-nxp  = scarthgap-7.x.y:e43ed4b34727f351a63232013de205b27f09180f
meta-poky         = scarthgap:bf6aea52c4009e08f26565c33ce432eec7cfb090

I could work around the OOM issue: I set BB_NUMBER_THREADS = "16" this peaks at around ~46GB RAM usage maximum.

First issue remains open.

Thank you for providing the layer information. I can see you’re using Toradex BSP 7.5.0 with a custom nox-devel distribution based on the scarthgap Yocto branch.

SBOM 3.0 Issues Analysis

Based on the available documentation, Toradex currently provides SBOM support using the standard Yocto create-spdx class(1). The SPDX SBOM is generated by Yocto’s create-spdx class and lists Yocto package names and versions based on the PN and PV variables, plus includes every file in the filesystem with its hash(1).

Memory Usage Resolution

Good work on resolving the memory issue by setting BB_NUMBER_THREADS = "16". This aligns with the documented approach for reducing RAM usage during intensive builds(2). The documentation recommends limiting both PARALLEL_MAKE and BB_NUMBER_THREADS to manage memory consumption(2).

Issue 1: Linux-Toradex License File Problem

The issue you’re experiencing with the do_populate_lic task failing due to missing COPYING file appears to be related to how the SPDX 3.0 class moves source files during processing. Your workaround of symlinking from the SPDX work directory is a reasonable approach, but you’re correct that this needs a proper upstream fix.

Current SBOM Implementation

The available documentation shows that Toradex publishes both complete and actionable SBOMs for Torizon releases(1):

  • Complete SBOM: SPDX format listing every constituent part
  • Actionable SBOM: CycloneDX format with standardized identifiers (CPE/PURL) for vulnerability analysis

Next Steps

Since you’re working with a custom distribution (nox-devel) and encountering issues with the experimental SPDX 3.0 class that aren’t covered in the current documentation, I’d recommend:

  1. For the license file issue: Your symlink workaround is functional, but consider reporting this upstream to the Yocto Project as it appears to be a general issue with the SPDX 3.0 class
  2. Memory usage: Your BB_NUMBER_THREADS = "16" adjustment successfully resolved the OOM issue
  3. Alternative approach: Consider using the standard create-spdx class (SPDX 2.x) which is well-tested and documented(1)

The SPDX 3.0 class appears to be experimental and may have stability issues that aren’t yet addressed in the stable Toradex BSP releases.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hello @SimonG,

This is the best way to limit the number of concurrent tasks if they can be an issue for your setup.


Regarding SPDX 3.0, we do not use it yet.
Therefore, we have not validated it to work yet with our BSP.

We also don’t do anything particularly different with the license on linux-toradex*.bb.
Therefore, I would recommend that you keep using your workaround while this is not resolved.
When we enable SPDX 3.0, adjustments to make our BSP work with it are expected.
However, this may only come with BSP 8.

Best Regards,
Bruno

@bruno.tx

Thanks for your response.

Okay, I guess in this case I’ll leave it as is and use my patch until this is released officially.

Best regards,
Simon