On Mon, 2026-09-28 at 21:59 +0100, Richard Purdie wrote: > 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? > ok, I was a bit hesitant on this change as well. I'll check how can it be added later in the process without touching the task dependencies and order.
Cheers, Daniel > Cheers, > > Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#246818): https://lists.openembedded.org/g/openembedded-core/message/246818 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]] -=-=-=-=-=-=-=-=-=-=-=-
