[Buildroot] [PATCH 09/34] reproducibility/libglib2: allow removing codegen

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Tue, May 10, 2016 at 01:40:30AM +0200, Arnout Vandecappelle wrote:
> On 05/08/16 22:25, Gilles Chanteperdrix wrote:
> > On Sat, May 07, 2016 at 11:04:25PM +0200, Arnout Vandecappelle wrote:
> >> On 04/30/16 09:49, Gilles Chanteperdrix wrote:
> >>> But this is not sufficient, compiling the python bytecode with the
> >>> same interpreter in different environments yields different binaries,
> >>
> >>   Er, this is worrisome... You are saying that we don't have a chance in hell of
> >> generating reproducible python bytecode?
> >
> > I am not a python specialist, but it seems to me four bytes in the
> > python generated bytecode are the build timestamp, so unless there
> > is a way to override it with SOURCE_DATE_EPOCH, I do not see that
> > possible.
> 
>   I've checked the docs. What is saved is the timestamp of the .py file, not the 
> build time.

Mmmm I don't remember. I would run a compilation manually, twice at
a different time, to make sure that the problem is only the file
date.

> 
>   I think it would make sense to run 'touch -d @$(SOURCE_DATE_EPOCH)' on all 
> files after patching to capture this aspect. This was also proposed for 
> Fedora[1] (though there it was only for the .py files). Not sure what happened 
> with that proposal in the end.

I think I tried running "touch" before compiling, unfortunately
playing with file dates before running "make" is a bit like playing
with fire. For instance with autotools based projects for which
autoreconf is not run, the project may use versions of the autotools
not installed on the user machine, and because of file dates may
want to rerun autoconf or autmake and whine because the right
versions are not available. Doing this only for .py files is much
more reasonable.

-- 
					    Gilles.
https://click-hack.org