From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Date: Tue, 21 Jul 2015 18:18:41 +0200 Subject: [U-Boot] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH In-Reply-To: <877fpuevlw.fsf@aikidev.net> References: <1437379261-21163-1-git-send-email-contact@paulk.fr> <877fpuevlw.fsf@aikidev.net> Message-ID: <1437495521.21200.6.camel@collins> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le lundi 20 juillet 2015 ? 07:45 -0700, Vagrant Cascadian a ?crit : > On 2015-07-20, Paul Kocialkowski wrote: > > In order to achieve reproducible builds in U-Boot, timestamps that are defined > > at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH environment > > variable allows setting a fixed value for those timestamps. > ... > > diff --git a/Makefile b/Makefile > > index 37cc4c3..71aeac7 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1231,9 +1231,10 @@ define filechk_version.h > > endef > > > > define filechk_timestamp.h > > - (LC_ALL=C date +'#define U_BOOT_DATE "%b %d %C%y"'; \ > > - LC_ALL=C date +'#define U_BOOT_TIME "%T"'; \ > > - LC_ALL=C date +'#define U_BOOT_TZ "%z"') > > + (SOURCE_DATE="$${SOURCE_DATE_EPOCH:+@$$SOURCE_DATE_EPOCH}"; \ > > + LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_DATE "%b %d %C%y"'; \ > > + LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TIME "%T"'; \ > > + LC_ALL=C date -u -d "$${SOURCE_DATE:-now}" +'#define U_BOOT_TZ "%z"' ) > > endef > > > > $(version_h): include/config/uboot.release FORCE > > This does effectively hard-code U_BOOT_TZ to UTC; may as well not call > date for setting U_BOOT_TZ. Or conditionally set it to UTC only when > SOURCE_DATE_EPOCH is set? That's true, but I like how consistent those commands look. Either way, it's not a dramatic overhead, but I agree it's slightly confusing. If you really think it's worth it, I could simply hardcode UTC in v2. Just let me know! I'd rather keep everything in one call (doing UTC only when SOURCE_DATE_EPOCH is set looks overkill). > Any reason not to use the longhand options for date, e.g. --utc and > --date ? They're more readable; are they less portable? I don't think they are, but the short options look fine to me. Note that out of those lines, two still fit in a 80 chars column. Adding long options would make readability harder in that regard. As far as I'm concerned, it's fine as it is, but if you really think it would be a worthwhile addition to use the long options, let me know. Please do check that it doesn't break portability, too. Thanks for the review! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: