| Message ID | 20171116170316.19081-1-john@metanate.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | systemd: set time epoch for reproducible builds | expand |
Hello, On Thu, 16 Nov 2017 17:03:16 +0000, John Keeping wrote: > Systemd embeds a timestamp which is used to impose a minimum bound on > the system time during boot. Normally this comes from stat'ing the NEWS > file included with the systemd source, but this makes the build > non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic > timestamp when reproducible builds are enabled. > > Signed-off-by: John Keeping <john@metanate.com> Hum, systemd uses 'stat -c %Y NEWS', which returns: %Y time of last data modification, seconds since Epoch I just extracted the systemd tarball with Buildroot, and: output/build/systemd-234 (master)$ stat NEWS File: NEWS Size: 378872 Blocks: 744 IO Block: 4096 regular file Device: 10302h/66306d Inode: 34473900 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ thomas) Gid: ( 1000/ thomas) Access: 2017-11-17 10:51:07.369562977 +0100 Modify: 2017-07-12 16:01:10.000000000 +0200 Change: 2017-11-17 10:51:07.510563710 +0100 Birth: - So the modification date is July 12th, and not today. So for a given systemd release, the output of "stat -c %Y NEWS" is therefore stable, and will not change. Look: $ stat -c %Y NEWS 1499868070 $ date -d @1499868070 +%Y-%m-%d 2017-07-12 So I'm not sure why your patch would be necessary. Could you check what's going on? Thanks! Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, > $ stat -c %Y NEWS > 1499868070 > $ date -d @1499868070 +%Y-%m-%d > 2017-07-12 > So I'm not sure why your patch would be necessary. Could you check > what's going on? Exactly my thought as well. Tar should restore the modification time. If you use OVERRIDE_SRCDIR things may naturally be different though, I'm not sure git/rsync handles that correct.
Hello, On Thu, 16 Nov 2017 17:03:16 +0000, John Keeping wrote: > Systemd embeds a timestamp which is used to impose a minimum bound on > the system time during boot. Normally this comes from stat'ing the NEWS > file included with the systemd source, but this makes the build > non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic > timestamp when reproducible builds are enabled. > > Signed-off-by: John Keeping <john@metanate.com> > --- > package/systemd/systemd.mk | 5 +++++ > 1 file changed, 5 insertions(+) Following the feedback from Peter Korsgaard and myself, and the lack of additional justification, I've marked this patch as "Rejected" in our patch tracking system. John: don't hesitate to get back to us with a more detailed explanation of the issue if you have not been convinced by Peter's explantion and mine. Thanks! Thomas
On Wed, 22 Nov 2017 22:16:39 +0100, Thomas Petazzoni wrote: > On Thu, 16 Nov 2017 17:03:16 +0000, John Keeping wrote: > > Systemd embeds a timestamp which is used to impose a minimum bound on > > the system time during boot. Normally this comes from stat'ing the NEWS > > file included with the systemd source, but this makes the build > > non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic > > timestamp when reproducible builds are enabled. > > > > Signed-off-by: John Keeping <john@metanate.com> > > --- > > package/systemd/systemd.mk | 5 +++++ > > 1 file changed, 5 insertions(+) > > Following the feedback from Peter Korsgaard and myself, and the lack of > additional justification, I've marked this patch as "Rejected" in our > patch tracking system. > > John: don't hesitate to get back to us with a more detailed explanation > of the issue if you have not been convinced by Peter's explantion and > mine. I'm convinced! The original problem I was investigating wasn't actually reproducible builds, but was related to the time set by systemd when the hardware clock has an invalid time. It seems that e2fsck will update the superblock timestamp when it is in the future, which means that programming an ext4 filesystem image will trigger systemd-fsck-root.service to attempt a reboot halfway through the first boot. I've solved this by setting options.broken_system_clock in e2fsck.conf, but not before going down the root of trying to get systemd and the rootfs to agree on a timestamp, which resulted in this patch to make the timestamp included in systemd consistent with the rest of buildroot.
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk index 9f286fd54b..d87c9d33dd 100644 --- a/package/systemd/systemd.mk +++ b/package/systemd/systemd.mk @@ -40,6 +40,11 @@ SYSTEMD_CONF_OPTS += \ --with-default-dnssec=no \ --without-python +ifeq ($(BR2_REPRODUCIBLE),y) +SYSTEMD_CONF_OPTS += \ + --with-time-epoch=$(SOURCE_DATE_EPOCH) +endif + SYSTEMD_CFLAGS = $(TARGET_CFLAGS) -fno-lto # Override paths to a few utilities needed at runtime, to
Systemd embeds a timestamp which is used to impose a minimum bound on the system time during boot. Normally this comes from stat'ing the NEWS file included with the systemd source, but this makes the build non-reproducible. Pass in $SOURCE_DATE_EPOCH to use a deterministic timestamp when reproducible builds are enabled. Signed-off-by: John Keeping <john@metanate.com> --- package/systemd/systemd.mk | 5 +++++ 1 file changed, 5 insertions(+)