All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <contact@paulk.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
Date: Tue, 21 Jul 2015 18:18:41 +0200	[thread overview]
Message-ID: <1437495521.21200.6.camel@collins> (raw)
In-Reply-To: <877fpuevlw.fsf@aikidev.net>

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: <http://lists.denx.de/pipermail/u-boot/attachments/20150721/1d0bf2bf/attachment.sig>

      reply	other threads:[~2015-07-21 16:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20  8:01 [U-Boot] [PATCH] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH Paul Kocialkowski
2015-07-20  8:06 ` Paul Kocialkowski
2015-07-20 11:21   ` Heiko Schocher
2015-07-20 13:30     ` Paul Kocialkowski
2015-07-20 15:13       ` Heiko Schocher
2015-07-21 16:20         ` Paul Kocialkowski
2015-07-27 17:36         ` Paul Kocialkowski
2015-07-20 14:45 ` Vagrant Cascadian
2015-07-21 16:18   ` Paul Kocialkowski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1437495521.21200.6.camel@collins \
    --to=contact@paulk.fr \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.