From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Kocialkowski Date: Mon, 28 Sep 2015 19:42:50 +0200 Subject: [U-Boot] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH In-Reply-To: <87oagriz0p.fsf@aikidev.net> References: <1437929295-9642-1-git-send-email-contact@paulk.fr> <87oagriz0p.fsf@aikidev.net> Message-ID: <1443462170.2516.7.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 jeudi 24 septembre 2015 ? 09:05 -0700, Vagrant Cascadian a ?crit : > On 2015-07-26, 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. > ... > > However, some other devices might need some more tweaks, especially regarding > > the image generation tools. > > With this patch, there is still variation based on timezone in any of > the u-boot.img and u-boot-sunxi-with-spl.bin produced in the Debian > packages: > > https://reproducible.debian.net/rb-pkg/unstable/armhf/u-boot.html Thanks for reporting this! > The good news is that all the u-boot.bin targets are produced > reproducibly, so here's to progress! Good, that's a nice first step forward. > I think the use of "time = mktime(time_universal);" is where the problem > lies: [?] > According to the mktime manpage: > > The mktime() function converts a broken-down time structure, > expressed as local time, to calendar time representation. > > So my interpetation is that it's taking the UTC time and converts it > into local time using the configured timezone... not sure what would be > a viable alternative to mktime. That seems to make sense. Come to think of it, it probably was not necessary to call gmtime in the first place: if SOURCE_DATE_EPOCH is always in UTC, we should be able to stick that as-is in the time variable. At best, gmtime + mktime (assuming mktime working in UTC) would give us back the same timestamp. What do you think? Please let me know if I'm wrong. > Running with the TZ=UTC environment variable exported works around the > problem; not sure if it would be appropriate to always run with TZ=UTC > when SOURCE_DATE_EPOCH is set... Well that's too much of a workaround to be a reliable solution for the long term, IMHO. -- 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: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://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: