On Wed, 2021-02-24 at 09:50 -0600, Joshua Watt wrote: > Instead of trying to shove a non-zero SDE into the deployed sstate > files which has bad interactions, let it naturally resolve to 0 and do a > "last chance" correction to the fallback SOURCE_DATE_EPOCH. > > Also, stop exporting the fallback source date epoch since we don't want > to invalidate *all* tasks when it changes. Instead, make do_unpack > depend on the fallback value to invalidate all the downstream tasks when > it changes. > > Finally, we need to make sure that do_deploy_source_date_epoch() gets > rerun when the actual SDE value changes. Introduce a new variable > (SOURCE_DATE_EPOCH_DEP) that this task (and others like it) can depend > on when they need to be invalidated by a change in the source date epoch > value. > > Signed-off-by: Joshua Watt <[email protected]> > --- > meta/classes/reproducible_build.bbclass | 23 ++++++++++++++--------- > meta/lib/oe/reproducible.py | 8 ++------ > 2 files changed, 16 insertions(+), 15 deletions(-) > > diff --git a/meta/classes/reproducible_build.bbclass > b/meta/classes/reproducible_build.bbclass > index f06e00d70d..74ef8da3c9 100644 > --- a/meta/classes/reproducible_build.bbclass > +++ b/meta/classes/reproducible_build.bbclass > @@ -42,7 +42,13 @@ SDE_FILE = "${SDE_DIR}/__source_date_epoch.txt" > SDE_DEPLOYDIR = "${WORKDIR}/deploy-source-date-epoch" > > > > > # A SOURCE_DATE_EPOCH of '0' might be misinterpreted as no SDE > -export SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400" > +SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400" > + > +# Some tasks do actually depend on the value of the source date epoch, even > +# though it is generally excluded from task signatures. For those tasks, they > +# can add a vardep on this variable > +SOURCE_DATE_EPOCH_DEP = "${SOURCE_DATE_EPOCH}" > +SOURCE_DATE_EPOCH_DEP[vardepvalue] = "${SOURCE_DATE_EPOCH_DEP}" >
Just for the mailing list record, I believe the above would not allow task checksums to be calculated in advance which is why we didn't do this originally. It would certainly make some things easier if we could do that but I'm not sure it would be possible. The sstate tests in oe-selftest would likely flag this problem as they're designed to detect this. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#148697): https://lists.openembedded.org/g/openembedded-core/message/148697 Mute This Topic: https://lists.openembedded.org/mt/80879528/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
