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
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
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
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
(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
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
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
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
>>>
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
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
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
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
12 matches
Mail list logo