On 10/09/21 1:05 pm, Mark Hatle wrote:
Unfortunately I'm having problems sending email to the list currently. But I
can reply directly (feels free to forward this to the list).
On 9/9/21 7:32 PM, Douglas Royds wrote:
On 9/09/21 2:51 pm, Mark Hatle wrote:
From: Mark Hatle <mark.ha...@xilinx.com>
Externalsrc removes do_fetch, do_unpack, and do_patch. The system normally
discovers the correct reproducible date as a postfuncs on do_unpack, so this
date is never found, so it goes back to the default epoch.
Instead we can move the discovery function to a prefuncs on the epoch
deploy task. This task will run before do_configure, and since the source
is already available can run anytime safely.
Signed-off-by: Mark Hatle <mark.ha...@xilinx.com>
Signed-off-by: Mark Hatle <mark.ha...@kernel.crashing.org>
---
meta/classes/reproducible_build.bbclass | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/classes/reproducible_build.bbclass
b/meta/classes/reproducible_build.bbclass
index a9c117c3b9..ae0723ab21 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -128,7 +128,13 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH"
python () {
if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
# Generate the timestamp with create_source_date_epoch_stamp.
- d.appendVarFlag("do_unpack", "postfuncs", "
create_source_date_epoch_stamp")
+ # In most cases this will be a postfuncs of do_unpack.
+ # If we're running in external source, add
create_source_date_epoch_stamp
+ # to do_deploy_source_date_epoch instead because there is no do_unpack.
+ if d.getVar('EXTERNALSRC') and bb.data.inherits_class('externalsrc',
d):
+ d.appendVarFlag('do_deploy_source_date_epoch', 'prefuncs', '
create_source_date_epoch_stamp')
+ else:
+ d.appendVarFlag("do_unpack", "postfuncs", "
create_source_date_epoch_stamp")
d.appendVar('SSTATETASKS', " do_deploy_source_date_epoch")
bb.build.addtask('do_deploy_source_date_epoch_setscene', None, None,
d)
bb.build.addtask('do_deploy_source_date_epoch', 'do_configure',
'do_patch', d)
Why was create_source_date_epoch_stamp ever added as a do_unpack postfunc in the
first place? Why wasn't it invoked directly from do_deploy_source_date_epoch all
along? This task runs after do_patch and before do_configure anyway. What am I
missing? Are you there, Juro?
It was put in that place to ensure it was based on the original upstream source,
and not the patched source. As the act of patching the source may change the
dates based on the behavior of patch, filesystem, etc.
So really we do want the date/time from the do_unpack, and before do_patch (or
any random tasks added between do_unpack and do_patch run.)
True. Good point.
If we create_source_date_epoch_stamp (either as a do_deploy_source_date_epoch
prefunc or directly invoked), then it should work either way, for externalsrc or
not.
I've got a new set of patches coming shortly. (I can send patches, but can't
reply to the list currently. I've got a configuration problem on my ISP side
which will hopefully be fixed tomorrow.)
As an aside, perhaps do_deploy_source_date_epoch should come after do_unpack as
well, just in case someone has deleted do_patch:
addtask do_deploy_source_date_epoch before do_configure after do_unpack
do_patch
The new set will keep things as is, removing the confusing
BUILD_REPRODUCIBLE_BINARIES switching in this class, while moving the special
behavior to the externalsrc class. So if we remove the do_unpack, we'll move
the function to the prefuncs of the do_deploy_source_date_epoch.
Nice.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155875):
https://lists.openembedded.org/g/openembedded-core/message/155875
Mute This Topic: https://lists.openembedded.org/mt/85476714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
