Daniel Kahn Gillmor <d...@fifthhorseman.net> 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 build
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
Bill Allombert <ballo...@debian.org> writes:
> On Wed, Aug 16, 2017 at 12:14:53PM -0700, Russ Allbery wrote:
>> If you have specific wording suggestions that you believe would bring
>> this Policy requirement closer in line with what we're already doing in
>> the proje
Just to be completely, 100% clear: I will not be responding further to
this line of argument in this bug. If you disagree with my decision as a
project delegate, I've spelled out your possible next steps under Debian's
governance process.
--
Russ Allbery (r...@debian.org) <h
Bill Allombert <ballo...@debian.org> writes:
> On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote:
>> Note that, for most developers, this is pretty much equivalent to the
>> current situation with FTBFS on, say, s390 architectures. Or even
>> issues with r
ther elaborations or rephrasings of your
current arguments are going to change my mind.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Lintian and build log analysis and many other things,
that is not required by Policy. This is no different.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
___
Reproducible-builds mailing list
Reproducible
aring about the location of the build
tree) in reporting infrastructure like tracker. But I'm totally fine with
surfacing failures on new, higher bars in places like tracker before we
change Policy, just like we've been surfacing reproducibility failures
before Policy said anything about it at a
d
certainly update the definition of reproducible to reference matching the
environment specified in the corresponding *.buildinfo file.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
___
Reproducible-builds mailing
patch for this
> reason.
Oh, that's a good way to capture that. This seems fine to me, and I have
no objections to adding this advice. Seconded the original with or
without this addition.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
__
fixed, I don't see the harm
in documenting this as a prerequisite for a reproducible build. If we can
relax that prerequisite later, great, but nothing about listing it here
should reduce the pressure on making variable build paths work. It just
documents the current state of the world.
--
Ru
g
> more constraints, but we're not there yet.
> [1] https://reproducible-builds.org/docs/definition/
We should add a link to that page (maybe in a footnote).
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
__
Mattia Rizzolo <mat...@debian.org> writes:
> On Fri, Jul 22, 2016 at 12:14:56PM -0700, Russ Allbery wrote:
>> I think that's fine in this case, since not setting that variable
>> doesn't break the build. It just means the build isn't reproducible,
>> which is an o
nconditionally force a reproducible build.
In other words, I think this is more akin to DEB_BUILD_OPTIONS than it is
to DEB_HOST_ARCH.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
___
Reproducible-builds
of the staleness of the
documentation and the recentness of the last release of the software.
While this isn't a huge deal, it does feel somewhat less than ideal to
lose that data. Replacing it with the last modification date of the
Debian package isn't perfect, but it's fairly reasonable.
--
Russ Allbery
15 matches
Mail list logo
