[PureOS] Bits from PureOS

[Jeremiah C. Foster]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20190705/e6812c89/attachment-0001.sig>