On Thu, 2019-07-04 at 18:00 -0300, Chris Lamb wrote:
Dear Jeremiah,
In regard to reproducible builds, Chris Lamb and I have been meeting regularly to discuss PureOS builds and their reproducibility.
[…]
I believe that we'll be able to say that the PureOS ISO is reproducible when the builds are byte-for-byte identical.
That is absolutely correct, but I would go further in that I would underline that is no other definition of "reproducible" from our point of view.
+1
One remaining "policy" question here is what value we use for the SOURCE_DATE_EPOCH environment variable:
https://reproducible-builds.org/docs/source-date-epoch/
As in, a build of the PureOS issue needs to have a single, fixed, date associated with it. This can be as simple as the date of the relevant Git commit or tag that was built from but we need to decide on where it comes from, one way or another.
While I want to implement this as soon as possible, if not sooner, I want to confer with Matthias about where this ought to be set. I'm currently using debspawn but that wraps a container around Debian's live-build I believe. The build script recommended in the PureOS documentation requires cloning make-live, so perhaps the latest git commit can be used for source date epoch? Line 24 in the URL below;
https://source.puri.sm/pureos/infra/make-live/blob/master/auto/config
The question otherwise is where do I put SOURCE_DATE_EPOCH? I assume in some makefile as a variable.
Then in our test framework or if anyone else wished to reproduce the same .ISO themselves, we would export that very SOURCE_DATE_EPOCH value to the environment in all builds of that specific version.
Various tools and utilities that I have already patched upstream to detect & use that value and it would make a bunch of stuff immediately reproducible. For example, casper which is — at the time of writing — is introducing variances between the builds. It would use that value in its metadata rather than the current date/time etc.
This makes me suspicious that I can just export SOURCE_DATE_EPOCH in a top level shell file and everything'll work?
Well, just a medium length email this time, if they get too long they tend to get a bit boring.
Beethoven's second-most famous letter contains the phrase: "only a few words today and with a pencil" … so you are in good company in sending shorter messages. What I'm really trying to say here is please keep sending these mails.
Will do!
[…] encourage greater use of our mailing list to compliment our chat channel and this irregular (but hopefully frequent) email is a collection of "bits" in the spirit of a Debian's "Bits from . . . "
Huzzah! Indeed, this "Debian" thing you refer to sounds like they have a bunch of good ideas. How can I find out more about it? ;)
It's complex. It's anarchic. You have to be technical. But it returns on your investment of time and energy a thousand fold - in bug reports.
Best,
Jeremiah