On Mon, 2026-09-28 at 21:03 +0200, Daniel Turull via lists.openembedded.org wrote: > From: Daniel Turull <[email protected]> > > Record each recipe's release date in the releaseTime property of its > software_Package object, using the SOURCE_DATE_EPOCH already computed > for reproducible builds. > > Accuracy depends on how SOURCE_DATE_EPOCH was derived: exact for > git-tagged recipes, best-effort for tarball/http(s) sources. Some > Python sdists (e.g. cryptography, hypothesis, maturin) normalize all > file mtimes to a fixed placeholder, so their releaseTime reflects > packaging-tool behavior, not the real release date. > > Tested with oe-selftest -r spdx, and with `bitbake world > --runall=do_create_spdx`: 1011/1150 recipes got a releaseTime (range > 1998-12-30 to 2026-09-17), 139 correctly had none. > > AI-Generated: Uses Kiro with Claude Sonnet 5 > Signed-off-by: Daniel Turull <[email protected]> > --- > v2: > - Dropped all options per Joshua's feedback; read SDE_FILE directly. > - Dropped the redundant else: delattr(recipe, "releaseTime") branch. > - Selftest compares against SDE_FILE content directly instead of > SOURCE_DATE_EPOCH, which can diverge from it. > - Fixed a leak: recipes with no git checkout and no fetched source > had SDE_FILE holding only SOURCE_DATE_EPOCH_FALLBACK, showing a > bogus 2011-04-05T23:00:00Z releaseTime instead of none. > v3: > - Also run after do_unpack: do_deploy_source_date_epoch's setscene > shortcut can skip it, leaving SOURCE_DATE_EPOCH unset. > - get_release_date() reads SOURCE_DATE_EPOCH again instead of > SDE_FILE, now that they're guaranteed equivalent. > - test_release_date_source_date_epoch: switched to tar (base-files > has S == UNPACKDIR and never gets a real SOURCE_DATE_EPOCH). > - Added test_release_date_omitted_for_fallback_value. > --- > meta/classes/create-spdx-3.0.bbclass | 2 +- > meta/lib/oe/spdx30_tasks.py | 19 ++++++++++++++ > meta/lib/oeqa/selftest/cases/spdx.py | 39 ++++++++++++++++++++++++++++ > 3 files changed, 59 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/create-spdx-3.0.bbclass > b/meta/classes/create-spdx-3.0.bbclass > index 56fd01fd53..2b1465b5a6 100644 > --- a/meta/classes/create-spdx-3.0.bbclass > +++ b/meta/classes/create-spdx-3.0.bbclass > @@ -192,7 +192,7 @@ python do_create_recipe_spdx() { > import oe.spdx30_tasks > oe.spdx30_tasks.create_recipe_spdx(d) > } > -addtask do_create_recipe_spdx > +addtask do_create_recipe_spdx after do_unpack do_deploy_source_date_epoch > > SSTATETASKS += "do_create_recipe_spdx" > do_create_recipe_spdx[sstate-inputdirs] = "${SPDXRECIPEDEPLOY}"
I'm not really very happy about this part of the change. The "recipe" SPDX data was meant to be the data which can be obtained from the recipe without fetching the sources. This changes that and adds a fetch/unpack requirement. At this point it may as well be merged with other SPDX data that being generated "later" in the build as the "recipe" only data is losing it's meaning? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246801): https://lists.openembedded.org/g/openembedded-core/message/246801 Mute This Topic: https://lists.openembedded.org/mt/121478119/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
