Bug#876055: Environment variable handling for reproducible builds

2017-10-02 Thread Ximin Luo
Ximin Luo: > [..] > > OTOH, developer reproducibility checkers (such as reprotest) can be a little > bit more strict. I can imagine something like: > > - reprotest runs 3 builds: > - build 0 with current env > - build 1 with current env + varying some "blacklist" envvars > - build 2 with

Bug#876055: Environment variable handling for reproducible builds

2017-09-19 Thread Ximin Luo
Russ Allbery: > [..] It does mean that discovery of any new > such environment variable would require a change to our whitelist in > approach (3), so there would be some lag and the whitelist would become > long over time (with a corresponding testing load). But (3) does try to > achieve that

Bug#876055: Environment variable handling for reproducible builds

2017-09-19 Thread Ximin Luo
Ximin Luo: > [..] > > (The last time I erroneously included PATH in the final "excluded" list - > because we have varied PATH but in a really trivial way on tests.r-b.org for > ages - but I now agree with you that we shouldn't expect reproducibility when > PATH is varied.) > Actually

Bug#876055: Environment variable handling for reproducible builds

2017-09-19 Thread Ximin Luo
Simon McVittie: > On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote: >> [..] >> >> I consider unintended variables that affect the build output a bug, and >> variables designed and intended to change the behavior of the toolchain >> expected, reasonable behavior. > > There is a

Bug#876055: Environment variable handling for reproducible builds

2017-09-19 Thread Simon McVittie
(Re-sending this to the bug rather than to debian-policy, sorry for the duplicate on -policy) On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote: > There is a huge difference between variables that *might* affect the > build as an unintended input that gets stored in a resulting

Re: Bug#876055: Environment variable handling for reproducible builds

2017-09-19 Thread Simon McVittie
On Mon, 18 Sep 2017 at 18:00:51 -0700, Vagrant Cascadian wrote: > There is a huge difference between variables that *might* affect the > build as an unintended input that gets stored in a resulting packages in > some manner, and variables that are designed to change the behavior of > parts of the

Bug#876055: Environment variable handling for reproducible builds

2017-09-18 Thread Vagrant Cascadian
On 2017-09-18, Vagrant Cascadian wrote: > On 2017-09-18, Russ Allbery wrote: >> Daniel Kahn Gillmor writes: >>> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote: >>> Does everything in policy need to be rigorously testable? or is it ok >>> to have Policy state the

Bug#876055: Environment variable handling for reproducible builds

2017-09-18 Thread Vagrant Cascadian
On 2017-09-18, Russ Allbery wrote: > Daniel Kahn Gillmor writes: >> On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote: > >>> I personally lean towards 2, which is consistent with what's in Policy >>> right now, but I can see definite merits in 3. I believe the >>>

Bug#876055: Environment variable handling for reproducible builds

2017-09-18 Thread Russ Allbery
Daniel Kahn Gillmor writes: > On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote: >> I personally lean towards 2, which is consistent with what's in Policy >> right now, but I can see definite merits in 3. I believe the >> reproducible builds project is currently sort

Bug#876055: Environment variable handling for reproducible builds

2017-09-18 Thread Daniel Kahn Gillmor
On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote: > I personally lean towards 2, which is consistent with what's in Policy > right now, but I can see definite merits in 3. I believe the reproducible > builds project is currently sort of doing 1, but I have a hard time seeing > how to make

Bug#876055: Environment variable handling for reproducible builds

2017-09-18 Thread Paul Sherwood
On 2017-09-18 00:26, Russ Allbery wrote: 2. Set the entire environment to the environment specified in buildinfo when doing a reproducible build. I think this is conceptually the simplest, but it means that we should make every tool that builds official Debian packages use the same

Bug#876055: Environment variable handling for reproducible builds

2017-09-17 Thread Russ Allbery
Package: debian-policy Version: 4.1.0.0 Severity: normal Currently, Debian Policy requires all environment variables be held the same across builds for the build to be expected to be reproducible. However, the current approach of some reproducible build tools is to instead enumerate a set of