From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 00/15] Reproducible builds
Date: Thu, 17 Nov 2016 15:08:55 +0100 [thread overview]
Message-ID: <20161117150855.4b2c99b9@free-electrons.com> (raw)
In-Reply-To: <9798cfe2186532e99707f24481a2a03a@sysmic.org>
Hello,
On Thu, 17 Nov 2016 14:17:41 +0100, J?r?me Pouiller wrote:
> >> - since gcc versions supporting SOURCE_DATE_EPOCH are not widely
> >> available,
> >> external toolchains probably won't work.
> >
> > Instead of patching gcc, can we solve the problem in the toolchain
> > wrapper? I.e, maybe the toolchain wrapper can set __DATE__ and __TIME__
> > by passing -D__DATE__=... -D__TIME__=... to gcc ?
>
> Yes, I can switch to this solution.
I think it's a reasonable use of the wrapper, and makes the thing work
fine for external toolchain as well, which is nice.
Another (unrelated) question: how can we test this stuff? You're
providing the initial steps for it, but at some point, we will want to
validate which packages behave properly and which packages don't behave
properly. Have you already thought of automated testing we can do (in
the autobuilders perhaps?) to exercise this "reproducible builds"
functionality? Should we from time to time do a given builds twice,
each time in a different environment (different date, different time,
different user, different path, different timezone, different locale,
etc.) ?
To what extent do we try to be reproducible? Do we try to have
something that produces the same result when executed multiple times,
but on the same machine, in the same environment (i.e only date/time
changes) ? Or do we try to go the point where a given Buildroot .config
gives a byte identical output regardless of the host machine on which
you do the build? It would be great to know what our definition of
"reproducible is", and document it in the help text of the
BR2_REPRODUCIBLE option.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-11-17 14:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-17 10:00 [Buildroot] [PATCH 00/15] Reproducible builds Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 01/15] gcc6: honor SOURCE_DATE_EPOCH Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 02/15] gcc5: " Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 03/15] reproducibility: generate SOURCE_DATE_EPOCH Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 04/15] reproducible: add '-n' to gzip invocations Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 05/15] fs/tar: make results reproducible Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 06/15] reproducibility/linux: override build timestamp Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 07/15] reproducibility/linux: inhibit build-id Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 08/15] reproducibility/busybox: disable build timestamps Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 09/15] reproducible: lock modification times in $TARGET_DIR Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 10/15] fakedate: new package Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 11/15] reproducible: enable fakedate Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 12/15] python2: generate reproducible .pyc Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 13/15] python3: " Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 14/15] python2: remove full path from .pyc Jérôme Pouiller
2016-11-17 10:00 ` [Buildroot] [PATCH 15/15] python3: " Jérôme Pouiller
2016-11-17 11:13 ` [Buildroot] [PATCH 00/15] Reproducible builds Thomas Petazzoni
2016-11-17 13:17 ` Jérôme Pouiller
2016-11-17 14:08 ` Thomas Petazzoni [this message]
2016-11-18 8:49 ` Jérôme Pouiller
2016-11-18 9:09 ` Thomas Petazzoni
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=20161117150855.4b2c99b9@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox