From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gilles Chanteperdrix Date: Tue, 10 May 2016 21:42:57 +0200 Subject: [Buildroot] [PATCH 09/34] reproducibility/libglib2: allow removing codegen In-Reply-To: <00b9819d-dbe3-52ce-75f7-6d7a8217f47a@mind.be> References: <20160430074358.GE1781@hermes.click-hack.org> <1462002570-14706-1-git-send-email-gilles.chanteperdrix@xenomai.org> <1462002570-14706-9-git-send-email-gilles.chanteperdrix@xenomai.org> <88864677-f612-bd6b-3158-5c2980bb9825@mind.be> <20160508202511.GT13285@hermes.click-hack.org> <00b9819d-dbe3-52ce-75f7-6d7a8217f47a@mind.be> Message-ID: <20160510194257.GE13285@hermes.click-hack.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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