Hi Paul,
Retested the original do_sbom_cve_check bug.
If you enable the sbom_cve_check class after a successful build it fails as
do_create_image_sbom_spdx stays cached from the earlier build and its
output keeps the old build's DATETIME. Result:
sbom-cve-check: error: [Errno 2] No such file or directory:
'.../core-image-minimal-qemux86-64.rootfs-20260902135131.spdx.json'
Before: path built as ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.spdx.json as
IMAGE_NAME carries DATETIME, so it only matches the SBOM written in the
same bitbake run.
After: build path from IMAGE_LINK_NAME instead (link_name or image_name,
falls back when link name empty). IMAGE_LINK_NAME is the stable,
non-timestamped symlink do_create_image_sbom_spdx maintains pointing at the
current SBOM. create-spdx-image-3.0.bbclass keeps it updated to the latest
build's file. Reading through it means do_sbom_cve_check finds the SBOM
regardless of which invocation wrote it, since the symlink always points
at the current one, not just this run's timestamp.
bitbake core-image-minimal # build once, class
not yet enabled
bitbake-config-build --set-fragment sbom-cve-check # or add fragment
manually
git checkout 1a32e30~1 -- meta/classes-recipe/sbom-cve-check.bbclass #
pre-fix code
bitbake core-image-minimal # ENOENT on
do_sbom_cve_check
git checkout HEAD -- meta/classes-recipe/sbom-cve-check.bbclass #
restore fix
bitbake -c sbom_cve_check core-image-minimal -f #
succeeds
The pattern is pre-existing, not part of this series, it was already
established:
- meta/classes-recipe/testexport.bbclass:52 (testexport_main()) —
d.getVar('IMAGE_LINK_NAME') or d.getVar('IMAGE_NAME')
- meta/classes-recipe/testimage.bbclass:228 — same IMAGE_LINK_NAME or
IMAGE_NAME fallback, reading testdata.json back
Plus the empty-guard pattern (skip symlink creation rather than fail):
- meta/classes-recipe/image.bbclass:610 (create_symlinks) — if not
link_name: return
- meta/classes-recipe/rootfs-postcommands.bbclass:402,479
(write_image_manifest) — if ... and link_name
- meta/classes-recipe/qemuboot.bbclass:147 — if
d.getVar('IMAGE_LINK_NAME'): before writing the symlink
- meta/classes-recipe/kernel.bbclass:804 — if [ -n
"${KERNEL_IMAGE_LINK_NAME}" ] before the kernel symlink
- meta/classes-recipe/license_image.bbclass:300 — same link_name guard
pattern
- meta/classes-recipe/baremetal-image.bbclass:73 — same
I'm not dying if these series are not merged, I just think this fix is
useful and there are already places using the same pattern!
Please correct me if I'm wrong, also agree on not adding more code
complexity. May a central place is better, but I do not know one!
Cheers, Thomas
Am Do., 27. Aug. 2026 um 17:37 Uhr schrieb Paul Barker <[email protected]>:
> On Wed, 2026-08-19 at 08:22 +0200, Thomas Roos wrote:
> > v1 fixed the sbom-cve-check input path. Paul noted that 2a80840a4fe0
> > ("sbom-cve-check: Fix breakage with empty IMAGE_LINK_NAME") had already
> > touched this class, and that other classes make the same assumption. That
> > commit guarded the export symlinks; the input path is separate and still
> > built from IMAGE_NAME. Patch 1 now uses the shape Paul suggested, and
> > patches 2-4 fix the other sites found by auditing meta/classes*,
> > meta/lib/oe and meta/lib/oeqa.
> >
> > Read and write sites need opposite handling of an empty value: read sites
> > fall back to IMAGE_NAME, write sites skip the link. A central default
> (pin
> > IMAGE_LINK_NAME to IMAGE_NAME when empty) does not work, as
> create_symlinks
> > and multiubi_mkfs have no link != target check and IMAGE_NAME is itself
> > derived from IMAGE_LINK_NAME.
> >
> > Tested on qemux86-64, each fix confirmed in both directions. Patch 5
> covers
> > patches 2-4 in one build; patch 1 was checked by hand, as a selftest
> would
> > need the sbom-cve-check databases (~8.7G of git).
> >
> > AI-Generated: Uses Claude Opus 5
>
> Hi Thomas,
>
> I discussed this with Richard, we want to avoid increasing the
> complexity of the code unnecessarily.
>
> IMAGE_LINK_NAME is intended to always be valid, we need the link because
> IMAGE_NAME is dependent on the date and time that an image was built. Do
> we really need to support the case where IMAGE_LINK_NAME is unset?
>
> If we don't need to support IMAGE_LINK_NAME being unset then perhaps we
> should just print a better error message in that case and give up.
>
> Best regards,
>
> --
> Paul Barker
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#245018):
https://lists.openembedded.org/g/openembedded-core/message/245018
Mute This Topic: https://lists.openembedded.org/mt/120826000/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
