On Tue, Aug 15, 2017 at 04:01:00PM -0700, Sean Whitton wrote:
> On Wed, Aug 16 2017, Adrian Bunk wrote:
>
> > This is about the reproducible builds team not using policy as a stick
> > for claiming a bar higher than what policy actually defines.
> >
> > Is it really allowed to claim that a
On Wed, Aug 16 2017, Adrian Bunk wrote:
> This is about the reproducible builds team not using policy as a stick
> for claiming a bar higher than what policy actually defines.
>
> Is it really allowed to claim that a package is not reproducible,
> when it actually is reproducible according to
Adrian Bunk writes:
> This is not about experimenting for raising the bar in the future.
> This is about the reproducible builds team not using policy as a stick
> for claiming a bar higher than what policy actually defines.
> Is it really allowed to claim that a package is
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Future policy versions might change this definition, but whatever latest
> > policy states has to be the definition used by both packages and the
> > reproducible builds team.
>
> >
On Tue, Aug 15, 2017 at 07:49:55PM +, Holger Levsen wrote:
> Also what you are saying ("a package that is reproducible according to the
> policy definition must not show up as non-reproducible in tracker/DDPO based
> on results from the reproducible infrastructure") doesnt really makes sense:
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
>...
> This in absolutely no way constrains the reproducible build team from
> working on raising the bar in the future, just as the absence of this
> language from Policy did not prevent them from starting to work on this
> problem
Hello,
On Tue, Aug 15 2017, Russ Allbery wrote:
> Adrian Bunk writes:
>
>> Future policy versions might change this definition, but whatever
>> latest policy states has to be the definition used by both packages
>> and the reproducible builds team.
>
>> Another example is that
Adrian Bunk writes:
> Future policy versions might change this definition, but whatever latest
> policy states has to be the definition used by both packages and the
> reproducible builds team.
> Another example is that a package that is reproducible according to the
> policy
On Tue, Aug 15, 2017 at 09:05:29PM +0300, Adrian Bunk wrote:
> Is identical building on any kernel required (and tested)?
no and no.
it's only required that the results is reproducible, that is bit by bit
identical…
> Will every reproducible package in buster build identical on the
>
On Tue, Aug 15, 2017 at 10:09:30PM +0300, Adrian Bunk wrote:
> > > I would expect the reproducible builds team to not submit any bugs
> > > regarding varied environment variables as long as as the official
> > > definition of reproducibility in policy states that this is not required
> > > for a
package: debian-policy
severity: wishlist
x-debbugs-cc: reproduciblle-bui...@lists.alioth.debian.org
Hi,
On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> I believe the planned next step here is to publish the *.buildinfo files,
> which contain a specification of the environment
On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > I would expect the reproducible builds team to not submit any bugs
> > regarding varied environment variables as long as as the official
> > definition of reproducibility in policy states
Adrian Bunk writes:
> I would expect the reproducible builds team to not submit any bugs
> regarding varied environment variables as long as as the official
> definition of reproducibility in policy states that this is not required
> for a package to be reproducible.
I believe
On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
>...
> +Reproducibility
> +---
> +
> +Packages should build reproducibly, which for the purposes of this
> +document [#]_ means that given
> +
> +- a version of a source package unpacked at a given path;
> +- a set of
On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
>...
> - for now, we only require reproducibility when the set of environment
> variable values set is exactly the same
>
> This is because
>
> - the reproducible builds team aren't yet totally clear on the
> variables that
Hi,
On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
>
> > We do when the binary sig is small enough to be stored along with the
> > inode, instead of requiring an entire filesystem block (4KiB), and the
> > armored signature
16 matches
Mail list logo