844431">

Debian Bug report logs - #844431
debian-policy: Packages should be reproducible

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy Editors <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy (PTS, buildd, popcon).

Reported by: Chris Lamb <lamby@debian.org>

Date: Tue, 15 Nov 2016 17:30:01 UTC

Owned by: Sean Whitton <spwhitton@spwhitton.name>

Severity: normal

Found in version debian-policy/3.9.8.0

Fixed in version debian-policy/4.1.0.0

Done: Sean Whitton <spwhitton@spwhitton.name>

Bug is archived. No further changes may be made.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, reproducible-builds@lists.alioth.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Tue, 15 Nov 2016 17:30:04 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
New Bug report received and forwarded. Copy sent to reproducible-builds@lists.alioth.debian.org, Debian Policy List <debian-policy@lists.debian.org>. (Tue, 15 Nov 2016 17:30:04 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.debian.org (full text, mbox, future date. > > [As a mild suggestion to streamline this; we should probably come to some > consensus on principle of this addition to Policy first and only then > move to the more difficult topic of defining exactly what reproducibility > means in a technical sense.] > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` lamby@debian.org / chris-lamb.co.uk > `- > > &subject=Re: Packages should be reproducible">reply):

From: Chris Lamb <lamby@debian.org>
To: submit@bugs.debian.org
Subject: Packages should be reproducible
Date: Tue, 15 Nov 2016 17:27:44 +0000
Package: debian-policy
Version: 3.9.8.0
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Policy maintainers,

Whilst anyone can inspect the source code in Debian for malicious
flaws, we distribute pre-compiled to end users. The motivation behind
the Reproducible Builds effort is to permit verification that no flaws
have been introduced — either maliciously or accidentally — during this
compilation process by promising identical results are always generated
from a given source, thus allowing multiple third-parties to come to a
consensus on whether a build was compromised.

Debian has been making great strides to make itself reproducible,
contributing 100s patches, not only within Debian itself but also to
upstream projects. We have also been running a comprehensive and non-
trivial CI framework to test for reproducibility of packages for quite
some time.

However, the recent arrival of the final pieces of the toolchain into
unstable encourages me to propose that we add a recommendation that
packages in Debian should be reproducible.

This would be act both as documentation of a modern best practice, but
also act as a "placeholder" so that we can increase its severity at some
future date.

[As a mild suggestion to streamline this; we should probably come to some
consensus on principle of this addition to Policy first and only then
move to the more difficult topic of defining exactly what reproducibility
means in a technical sense.]


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Changed Bug title to 'debian-policy: Packages should be reproducible' from 'Packages should be reproducible'. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 15 Nov 2016 17:57:05 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Tue, 15 Nov 2016 19:45:02 GMT) (full text, mbox, link).


Acknowledgement sent to Henrique de Moraes Holschuh <hmh@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 15 Nov 2016 19:45:02 GMT) (full text, mbox, link).


Message #12 received at 844431@bugs.debian.org (full text, mbox, reproducibility mandatory right now, only to define stuff like "*if* it > is built for reproducibility, it must do so in such a way that...", etc. > > Enforcing package reproducibility (should/must in policy) has to wait > until a majority of the package is effectively being reproducibly built > for a small while (to shaken up any issues), and the tooling echosystem > is complete so that it is actually usable to verify things. IMHO, this > would be best done only after stretch is released, even if we reach >85% > reproducibility levels *and* a full, working toolset before that. > > As a suggestion, since a "may build reproducibly" policy is not going to > give the readers the desired idea, the policy text proposal could use > words to the effect that "it is recommended that", and "in the future, > this will become a requirement". > > Any packages that absolutely cannot be built in a reproducible way[1], > can become oficially allowed exceptions -- and we could likely teach the > verification tools that specific regions of a package/file are to be > random, and ignore those when comparing for reproducibility, too. But > this would be tackled on in the future, between an already implemented > policy of SHOULD is out, and >95% of the packages are being built > reproducibly and policy is about to be changed to MUST. Therefore, the > initial proposal just needs to acknowledge that this fact could happen > and will be dealt with in time. > > [1] Such as random noise added to kernel and firmware data structures > during local builds, to be used as a last defense to avoid the *herd > using same keys* effects, etc. > > -- > Henrique Holschuh > > &subject=Re: Bug#844431: Packages should be reproducible">reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>
To: Chris Lamb <lamby@debian.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Packages should be reproducible
Date: Tue, 15 Nov 2016 17:40:58 -0200
On Tue, 15 Nov 2016, Chris Lamb wrote:
> [As a mild suggestion to streamline this; we should probably come to some
> consensus on principle of this addition to Policy first and only then
> move to the more difficult topic of defining exactly what reproducibility
> means in a technical sense.]

I don't think there will be much of a contention about this.

Please propose wording (i.e. the diff to the policy text), but I
recommend that you do *not* use "should" or "must" to make such
reproducibility mandatory right now, only to define stuff like "*if* it
is built for reproducibility, it must do so in such a way that...", etc.

Enforcing package reproducibility (should/must in policy) has to wait
until a majority of the package is effectively being reproducibly built
for a small while (to shaken up any issues), and the tooling echosystem
is complete so that it is actually usable to verify things.  IMHO, this
would be best done only after stretch is released, even if we reach >85%
reproducibility levels *and* a full, working toolset before that.

As a suggestion, since a "may build reproducibly" policy is not going to
give the readers the desired idea, the policy text proposal could use
words to the effect that "it is recommended that", and "in the future,
this will become a requirement".

Any packages that absolutely cannot be built in a reproducible way[1],
can become oficially allowed exceptions -- and we could likely teach the
verification tools that specific regions of a package/file are to be
random, and ignore those when comparing for reproducibility, too.  But
this would be tackled on in the future, between an already implemented
policy of SHOULD is out, and >95% of the packages are being built
reproducibly and policy is about to be changed to MUST.  Therefore, the
initial proposal just needs to acknowledge that this fact could happen
and will be dealt with in time.

[1] Such as random noise added to kernel and firmware data structures
during local builds, to be used as a last defense to avoid the *herd
using same keys* effects, etc.

-- 
  Henrique Holschuh



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Thu, 17 Nov 2016 14:30:10 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 17 Nov 2016 14:30:10 GMT) (full text, mbox, link).


Message #17 received at 844431@bugs.debian.org (full text, mbox, > reproducibility mandatory right now. > > Completely agreed. Any requirement would be counter-productive and > ultimately premature at this stage. > > I've attached an initial wording to get us going. I'm not 100% convinced > with it myself but it should help start any discussion in this area. > > > Regards, > > -- > ,''`. > : :' : Chris Lamb > `. `'` lamby@debian.org / chris-lamb.co.uk > `- ">reply):

From: Chris Lamb <lamby@debian.org>
To: Henrique de Moraes Holschuh <hmh@debian.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Packages should be reproducible
Date: Thu, 17 Nov 2016 12:30:44 +0100
[Message part 1 (text/plain, inline)]
Henrique de Moraes Holschuh wrote:

> I don't think there will be much of a contention about this.

Great :)

> Please propose wording (i.e. the diff to the policy text), but
> I recommend that you do *not* use "should" or "must" to make such
> reproducibility mandatory right now.

Completely agreed. Any requirement would be counter-productive and
ultimately premature at this stage.

I've attached an initial wording to get us going. I'm not 100% convinced
with it myself but it should help start any discussion in this area.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-
[debian-policy.diff.txt (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 07 May 2017 15:39:03 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 07 May 2017 15:39:03 GMT) (full text, mbox, link).


Message #22 received at 844431@bugs.debian.org (full text, mbox, we plan that starting with the development phase of "buster" we'll consider > bugs about reproducible builds issues to be of severity "normal", not "wishlist". > > This shall be announced on d-d-a soon & given there is no disagrement on this > procedure on this bug. > > Last and least for now: the wording of > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17 > IMO is almost good as it is, though I'll try to amend it to include the > definition of reproducible builds from reproducible-builds.org. > > > -- > cheers, > Holger &subject=Re: policy: packages should be reproducible&References=<20170507153500.GB31497@layer-acht.org>&In-Reply-To=<20170507153500.GB31497@layer-acht.org>">reply):

From: Holger Levsen <holger@layer-acht.org>
To: 844431@bugs.debian.org
Cc: Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: policy: packages should be reproducible
Date: Sun, 7 May 2017 15:35:00 +0000
[Message part 1 (text/plain, inline)]
hi,

unsurprisingly I'm also in favor of making this policy change, now.

I also believe there is quite a consensus (definitly a rough one…) in Debian
for making this change, judging by the feedback we got at 3 DebConfs since 2013,
several mini Debconfs and other events, plus the general feedback in the form
of code merges and uploads.

At the Reproducible Builds Hackathon in Hamburg we were reminded of the former
DPL asking DDs to be "more bold" doing sensible changes forward, and as such
we plan that starting with the development phase of "buster" we'll consider
bugs about reproducible builds issues to be of severity "normal", not "wishlist".

This shall be announced on d-d-a soon & given there is no disagrement on this
procedure on this bug.

Last and least for now: the wording of
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
IMO is almost good as it is, though I'll try to amend it to include the
definition of reproducible builds from reproducible-builds.org. 


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 07 May 2017 17:18:03 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 07 May 2017 17:18:03 GMT) (full text, mbox, link).


Message #27 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>
To: Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Cc: Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: policy: packages should be reproducible
Date: Sun, 07 May 2017 18:15:38 +0100
Hi Holger,

> unsurprisingly I'm also in favor of making this policy change, now.

Actually, yes, why were we waiting for stretch to be released? :)

> Last and least for now: the wording of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
> IMO is almost good as it is, though I'll try to amend it to include the
> definition of reproducible builds from reproducible-builds.org. 

That seems the next concrete step.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 07 May 2017 20:57:04 GMT) (full text, mbox, link).


Acknowledgement sent to Daniel Shahaf <danielsh@apache.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 07 May 2017 20:57:04 GMT) (full text, mbox, link).


Message #32 received at 844431@bugs.debian.org (full text, mbox, > > Note that the id should be changed before applying, since there already > is a sect with this id value. > > &subject=Re: Bug#844431: Packages should be reproducible&References=<1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20161115194058.GA11081@khazad-dum.debian.net> <1479382244.1038393.790727865.43695B82@webmail.messagingengine.com> <20170507205416.GA17929@fujitsu.shahaf.local2>&In-Reply-To=<20170507205416.GA17929@fujitsu.shahaf.local2>">reply):

From: Daniel Shahaf <danielsh@apache.org>
To: 844431@bugs.debian.org
Subject: Re: Bug#844431: Packages should be reproducible
Date: Sun, 7 May 2017 20:54:16 +0000
Chris Lamb wrote on Thu, Nov 17, 2016 at 12:30:44 +0100:
> +++ b/policy.sgml
> @@ -2503,6 +2503,20 @@ endif
> +      <sect id="readmesource">

Note that the id should be changed before applying, since there already
is a sect with this id value.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Thu, 11 May 2017 12:57:02 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Thu, 11 May 2017 12:57:02 GMT) (full text, mbox, link).


Message #37 received at 844431@bugs.debian.org (full text, mbox, > we plan that starting with the development phase of "buster" we'll consider > > bugs about reproducible builds issues to be of severity "normal", not "wishlist". > > I really think there should be an official tool to do build packages > reproducibly with an interface like cowbuilder. > > Currently, there are too much uncertainty about the process for bug > reports to be of severity normal. > > Cheers, > -- > Bill. > > Imagine a large red swirl here. > > ">reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Thu, 11 May 2017 14:42:43 +0200
On Sun, May 07, 2017 at 03:35:00PM +0000, Holger Levsen wrote:
> hi,
> 
> unsurprisingly I'm also in favor of making this policy change, now.
> 
> I also believe there is quite a consensus (definitly a rough one…) in Debian
> for making this change, judging by the feedback we got at 3 DebConfs since 2013,
> several mini Debconfs and other events, plus the general feedback in the form
> of code merges and uploads.
> 
> At the Reproducible Builds Hackathon in Hamburg we were reminded of the former
> DPL asking DDs to be "more bold" doing sensible changes forward, and as such
> we plan that starting with the development phase of "buster" we'll consider
> bugs about reproducible builds issues to be of severity "normal", not "wishlist".

I really think there should be an official tool to do build packages
reproducibly with an interface like cowbuilder. 

Currently, there are too much uncertainty about the process for bug
reports to be of severity normal.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 14:39:06 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 14:39:06 GMT) (full text, mbox, link).


Message #42 received at 844431@bugs.debian.org (full text, mbox, > > -- > cheers, > Holger &References=<20170507153500.GB31497@layer-acht.org> <20170511124243.GB6785@yellowpig> <20170514143646.GA7254@layer-acht.org>&In-Reply-To=<20170514143646.GA7254@layer-acht.org>">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 14:36:46 +0000
[Message part 1 (text/plain, inline)]
On Thu, May 11, 2017 at 02:42:43PM +0200, Bill Allombert wrote:
> I really think there should be an official tool to do build packages
> reproducibly with an interface like cowbuilder. 
 
the official tool to build packages reproducible in sid is called
"dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 14:54:05 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 14:54:05 GMT) (full text, mbox, link).


Message #47 received at 844431@bugs.debian.org (full text, mbox, > So if your package builds with "dpkg-buildpackage" then the build is > reproducible and any bug report to the contrary is in error ? > > Cheers, > -- > Bill. > > Imagine a large red swirl here. > > &In-Reply-To=<20170514145147.GE24876@yellowpig>&References=<20170507153500.GB31497@layer-acht.org> <20170511124243.GB6785@yellowpig> <20170514143646.GA7254@layer-acht.org> <20170514145147.GE24876@yellowpig>">reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 16:51:47 +0200
On Sun, May 14, 2017 at 02:36:46PM +0000, Holger Levsen wrote:
> On Thu, May 11, 2017 at 02:42:43PM +0200, Bill Allombert wrote:
> > I really think there should be an official tool to do build packages
> > reproducibly with an interface like cowbuilder. 
>  
> the official tool to build packages reproducible in sid is called
> "dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).

So if your package builds with "dpkg-buildpackage" then the build is
reproducible and any bug report to the contrary is in error ? 

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 15:03:05 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 15:03:05 GMT) (full text, mbox, link).


Message #52 received at 844431@bugs.debian.org (full text, mbox, > So if your package builds with "dpkg-buildpackage" then the build is > > reproducible and any bug report to the contrary is in error ? > > almost. 93% of the packages in stretch today can be re-build bit by bit > identically. > > that's why we're now aiming at "packages should be reproducible" and not > for "must be reproducible"… (but plan to later aim for "must be"). > > > -- > cheers, > Holger &subject=Re: Bug#844431: policy: packages should be reproducible">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 14:58:27 +0000
[Message part 1 (text/plain, inline)]
On Sun, May 14, 2017 at 04:51:47PM +0200, Bill Allombert wrote:
> > the official tool to build packages reproducible in sid is called
> > "dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).
> So if your package builds with "dpkg-buildpackage" then the build is
> reproducible and any bug report to the contrary is in error ? 

almost. 93% of the packages in stretch today can be re-build bit by bit
identically. 

that's why we're now aiming at "packages should be reproducible" and not
for "must be reproducible"… (but plan to later aim for "must be").


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 15:06:08 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 15:06:08 GMT) (full text, mbox, link).


Message #57 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: Chris Lamb <lamby@debian.org>
Cc: 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: policy: packages should be reproducible
Date: Sun, 14 May 2017 15:04:40 +0000
[Message part 1 (text/plain, inline)]
On Sun, May 07, 2017 at 06:15:38PM +0100, Chris Lamb wrote:
> > unsurprisingly I'm also in favor of making this policy change, now.
> Actually, yes, why were we waiting for stretch to be released? :)

good question. I guess because of a mental barrier against doing changes
targeted post-stretch now :)
 
> > Last and least for now: the wording of
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=844431;filename=debian-policy.diff.txt;msg=17
> > IMO is almost good as it is, though I'll try to amend it to include the
> > definition of reproducible builds from reproducible-builds.org. 
> That seems the next concrete step.

indeed! Will see to work on this the next days…


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 15:06:13 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 15:06:13 GMT) (full text, mbox, link).


Message #62 received at 844431@bugs.debian.org (full text, mbox, > > So if your package builds with "dpkg-buildpackage" then the build is > > > reproducible and any bug report to the contrary is in error ? > > > > almost. 93% of the packages in stretch today can be re-build bit by bit > > identically. > > OK, but how can I check that my package build is reproducible before uploading > it ? > > Cheers, > -- > Bill. > > Imagine a large red swirl here. > > &subject=Re: Bug#844431: policy: packages should be reproducible&References=<20170507153500.GB31497@layer-acht.org> <20170511124243.GB6785@yellowpig> <20170514143646.GA7254@layer-acht.org> <20170514145147.GE24876@yellowpig> <20170514145827.GB8693@layer-acht.org> <20170514150536.GA27362@yellowpig>&In-Reply-To=<20170514150536.GA27362@yellowpig>">reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 17:05:36 +0200
On Sun, May 14, 2017 at 02:58:27PM +0000, Holger Levsen wrote:
> On Sun, May 14, 2017 at 04:51:47PM +0200, Bill Allombert wrote:
> > > the official tool to build packages reproducible in sid is called
> > > "dpkg-buildpackage" (since dpkg 1.18.16 in sid since 2016-12-17).
> > So if your package builds with "dpkg-buildpackage" then the build is
> > reproducible and any bug report to the contrary is in error ? 
> 
> almost. 93% of the packages in stretch today can be re-build bit by bit
> identically. 

OK, but how can I check that my package build is reproducible before uploading
it ?

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 15:24:02 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 15:24:02 GMT) (full text, mbox, link).


Message #67 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 15:20:54 +0000
[Message part 1 (text/plain, inline)]
On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> OK, but how can I check that my package build is reproducible before uploading
> it ?

in general you cannot find out with 100% certainity whether a given source package
will be reproducible. You can only find out with certainity if a package is *not*
reproducible…

that said

a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.

	Bill, did you do this for your packages?
	And then there is also https://tests.reproducible-builds.org/debian/unstable/index_dd-list.html#ballombe@debian.org
		which shows that half of your 26 packages in sid (main) are unreproducible
		with build path variation, though most of those unreproducible ones
		are reproducible without build path variation…
	-> https://tests.reproducible-builds.org/debian/testing/index_dd-list.html#ballombe@debian.org
		only shows 4 unreproducible packages…

b.) build it twice and compare using diffoscope
c.) use reprotest


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 20:00:10 GMT) (full text, mbox, link).


Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 20:00:10 GMT) (full text, mbox, link).


Message #72 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>
To: Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Cc: Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 21:58:12 +0200
On Sun, 2017-05-14 at 15:20:54 +0000, Holger Levsen wrote:
> On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > OK, but how can I check that my package build is reproducible before uploading
> > it ?
> 
> in general you cannot find out with 100% certainity whether a given source package
> will be reproducible. You can only find out with certainity if a package is *not*
> reproducible…
> 
> that said
> 
> a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.
> 
> 	Bill, did you do this for your packages?
> 	And then there is also https://tests.reproducible-builds.org/debian/unstable/index_dd-list.html#ballombe@debian.org
> 		which shows that half of your 26 packages in sid (main) are unreproducible
> 		with build path variation, though most of those unreproducible ones
> 		are reproducible without build path variation…
> 	-> https://tests.reproducible-builds.org/debian/testing/index_dd-list.html#ballombe@debian.org
> 		only shows 4 unreproducible packages…

b.0.) use debrepro (from devscripts)

> b.) build it twice and compare using diffoscope
> c.) use reprotest

Thanks,
Guillem



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 22:00:04 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 22:00:04 GMT) (full text, mbox, link).


Message #77 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: Guillem Jover <guillem@debian.org>
Cc: 844431@bugs.debian.org, Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 21:57:53 +0000
[Message part 1 (text/plain, inline)]
On Sun, May 14, 2017 at 09:58:12PM +0200, Guillem Jover wrote:
> On Sun, 2017-05-14 at 15:20:54 +0000, Holger Levsen wrote:
> > 	Bill, did you do this for your packages?

on re-reading what I wrote here, it occurred to me that this could be
read *hostile* despite me having *zero* intentions to be hostile… I
just wanted to be friendly and give helpful URLs to you, Bill… I'm
sorry if this came across differently!

> b.0.) use debrepro (from devscripts)
 
Thanks for this additional hint, Guillem!


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 22:09:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 22:09:03 GMT) (full text, mbox, link).


Message #82 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Mon, 15 May 2017 00:05:17 +0200
On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.

As I said, I would like to check that my package build is reproducible before
I upload it, not after, so I can be sure that any bug is fixed in the
upload.

Some of my package were listed as reproducible for several months and
then became unreproducible without any new upload. I do not mind that.
However from a policy point of view, reproducible need to be defined
precisely. Generally speaking, reproducible means that the build will
not change if some (but not all) parameters are changed. What parameters
are allowed to change need to be defined.

One way is specify that would be to provide an authoritative tool to
validate packages.

Cheers,
PS: I thanks you for your advices, I will reply to you privately if I
need to.
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 14 May 2017 23:18:04 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 14 May 2017 23:18:04 GMT) (full text, mbox, link).


Message #87 received at 844431@bugs.debian.org (full text, mbox, (some) variation(s) and compare the results*. > > "Reproducible Builds" (in the sense of bit by bit identicall builds) is > really a rather new field in the era of software (well, not really, but > thats history and bit rotted until it was rediscovered in the early 2010s…) > > What is trivial, if given, is to show that a package is *un*reproducible. > > It's much harder to show that a package is reproducible. > > And given that this is a new field I think it's ok, while somewhat unsatisfying, > that maybe some unreproducibility will only be detected by a more advanced > tool, like reproducible.debian.net (which aint a,b,c nor d, but e.) > after an upload has taken place. > > This is one of the reasons we are aiming for "packages *should* be reproducible" > now, and not "*must* be". > > > Some of my package were listed as reproducible for several months and > > then became unreproducible without any new upload. I do not mind that. > > I guess this is because we introduced many more variations during 2014 and 2015. > During 2016 I don't recall us introducing many varitions, or rather many > causing many new unreproducibilty issues… > > For 2017 there weren't any. > > > However from a policy point of view, reproducible need to be defined > > precisely. > > Yes! > > > Generally speaking, reproducible means that the build will > > not change if some (but not all) parameters are changed. > > Yes. > > > What parameters > > are allowed to change need to be defined. > > I sadly think this is impossible. > > > One way is specify that would be to provide an authoritative tool to > > validate packages. > > the tool to validate builds should be diff/sha256sum. a tool to simulate all possible > variations in the wild would probably need endless time to operate… > > > PS: I thanks you for your advices, I will reply to you privately if I > > need to. > &In-Reply-To=<20170514231526.GB26052@layer-acht.org>&References=<20170507153500.GB31497@layer-acht.org> <20170511124243.GB6785@yellowpig> <20170514143646.GA7254@layer-acht.org> <20170514145147.GE24876@yellowpig> <20170514145827.GB8693@layer-acht.org> <20170514150536.GA27362@yellowpig> <20170514152053.GA9434@layer-acht.org> <20170514220517.GA2384@yellowpig> <20170514231526.GB26052@layer-acht.org>">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Sun, 14 May 2017 23:15:26 +0000
[Message part 1 (text/plain, inline)]
On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.
> As I said, I would like to check that my package build is reproducible before
> I upload it, not after, so I can be sure that any bug is fixed in the
> upload.
 
b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
(some) variation(s) and compare the results*.

"Reproducible Builds" (in the sense of bit by bit identicall builds) is
really a rather new field in the era of software (well, not really, but 
thats history and bit rotted until it was rediscovered in the early 2010s…)

What is trivial, if given, is to show that a package is *un*reproducible.

It's much harder to show that a package is reproducible.

And given that this is a new field I think it's ok, while somewhat unsatisfying,
that maybe some unreproducibility will only be detected by a more advanced
tool, like reproducible.debian.net (which aint a,b,c nor d, but e.)
after an upload has taken place.

This is one of the reasons we are aiming for "packages *should* be reproducible"
now, and not "*must* be".

> Some of my package were listed as reproducible for several months and
> then became unreproducible without any new upload. I do not mind that.

I guess this is because we introduced many more variations during 2014 and 2015.
During 2016 I don't recall us introducing many varitions, or rather many
causing many new unreproducibilty issues…

For 2017 there weren't any.

> However from a policy point of view, reproducible need to be defined
> precisely.

Yes!

> Generally speaking, reproducible means that the build will
> not change if some (but not all) parameters are changed.

Yes.

> What parameters
> are allowed to change need to be defined.

I sadly think this is impossible.

> One way is specify that would be to provide an authoritative tool to
> validate packages.

the tool to validate builds should be diff/sha256sum. a tool to simulate all possible
variations in the wild would probably need endless time to operate… 

> PS: I thanks you for your advices, I will reply to you privately if I
> need to.

While you surely can do so (and I will happily reply) I would even more happily
prefer if you could ask me on public list (and ping in private if you havent 
gotten a reply in whatever you think is appropriate)… a.) then more people can 
learn b.) you'll probably get faster *and better replies* (esp. on language
specific details) and c.) this helps me getting my inbox under control :-)


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Mon, 15 May 2017 06:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to Wouter Verhelst <wouter@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 15 May 2017 06:51:03 GMT) (full text, mbox, link).


Message #92 received at 844431@bugs.debian.org (full text, mbox, > (some) variation(s) and compare the results*. > > > > "Reproducible Builds" (in the sense of bit by bit identicall builds) is > > really a rather new field in the era of software (well, not really, but > > thats history and bit rotted until it was rediscovered in the early 2010s…) > > > > What is trivial, if given, is to show that a package is *un*reproducible. > > > > It's much harder to show that a package is reproducible. > > > > And given that this is a new field I think it's ok, while somewhat unsatisfying, > > that maybe some unreproducibility will only be detected by a more advanced > > tool, like reproducible.debian.net (which aint a,b,c nor d, but e.) > > after an upload has taken place. > > I think it's probably not a good idea to (when we've moved to mandate > "packages must be reproducible") allow packages to become insta-buggy by > things that are out of their control and not clearly specified in > policy. That's not how we do things in Debian. > > As such, I would favour the following approach: > - You guys (= the reproducible builds guys) come up with a list of > things that commonly make a package nonreproducible today, and policy > adds those as "should not"s. If I'm not mistaken, such a list already > exists, you may simply need to generalize it a bit? > - Actually, I'm sure there may be things that packages failed to > comply with in the past, but that are not a problem anymore today; > we can make those "must not" rules already today. > - If you find new and interesting ways to make packages nonreproducible > at some point in the future, those can be added (as "should" first, > and as "must" later). > > This would result in a section in policy of this form: > > --- > # Reproducible builds > > Packages should generally be reproducible. That is, a package build > should result in a bit-by-bit identical package from one build to the > next. > > Specifically, packages must not do any of the following things: > - non-reproducible thing A > - non-reproducible thing B > - ... > > Moreover, while the following are not must rules yet, packages should > also not do any of the following things: > - still-in-the-wild non-reproducible thing A > - still-in-the-wild non-reproducible thing B &subject=Re: Bug#844431: policy: packages should be reproducible&References=<20170507153500.GB31497@layer-acht.org> <20170511124243.GB6785@yellowpig> <20170514143646.GA7254@layer-acht.org> <20170514145147.GE24876@yellowpig> <20170514145827.GB8693@layer-acht.org> <20170514150536.GA27362@yellowpig> <20170514152053.GA9434@layer-acht.org> <20170514220517.GA2384@yellowpig> <20170514231526.GB26052@layer-acht.org> <20170515064823.yq2o3sxovm2nqztb@grep.be>&In-Reply-To=<20170515064823.yq2o3sxovm2nqztb@grep.be>">reply):

From: Wouter Verhelst <wouter@debian.org>
To: Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Cc: Bill Allombert <ballombe@debian.org>
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Mon, 15 May 2017 08:48:23 +0200
On Sun, May 14, 2017 at 11:15:26PM +0000, Holger Levsen wrote:
> On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> > On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > > a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.
> > As I said, I would like to check that my package build is reproducible before
> > I upload it, not after, so I can be sure that any bug is fixed in the
> > upload.
>  
> b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
> (some) variation(s) and compare the results*.
> 
> "Reproducible Builds" (in the sense of bit by bit identicall builds) is
> really a rather new field in the era of software (well, not really, but 
> thats history and bit rotted until it was rediscovered in the early 2010s…)
> 
> What is trivial, if given, is to show that a package is *un*reproducible.
> 
> It's much harder to show that a package is reproducible.
> 
> And given that this is a new field I think it's ok, while somewhat unsatisfying,
> that maybe some unreproducibility will only be detected by a more advanced
> tool, like reproducible.debian.net (which aint a,b,c nor d, but e.)
> after an upload has taken place.

I think it's probably not a good idea to (when we've moved to mandate
"packages must be reproducible") allow packages to become insta-buggy by
things that are out of their control and not clearly specified in
policy. That's not how we do things in Debian.

As such, I would favour the following approach:
- You guys (= the reproducible builds guys) come up with a list of
  things that commonly make a package nonreproducible today, and policy
  adds those as "should not"s. If I'm not mistaken, such a list already
  exists, you may simply need to generalize it a bit?
- Actually, I'm sure there may be things that packages failed to
  comply with in the past, but that are not a problem anymore today;
  we can make those "must not" rules already today.
- If you find new and interesting ways to make packages nonreproducible
  at some point in the future, those can be added (as "should" first,
  and as "must" later).

This would result in a section in policy of this form:

---
# Reproducible builds

Packages should generally be reproducible. That is, a package build
should result in a bit-by-bit identical package from one build to the
next.

Specifically, packages must not do any of the following things:
- non-reproducible thing A
- non-reproducible thing B
- ...

Moreover, while the following are not must rules yet, packages should
also not do any of the following things:
- still-in-the-wild non-reproducible thing A
- still-in-the-wild non-reproducible thing B
- ...
---

(wording may need some tweaking)

The above wording makes "bit-by-bit identical" a should (so packagers
are encouraged to reach that goal), but already allows you to file RC
bugs on some subset of "is not reproducible" package issues, and a
subset that will improve over time.

With that wording, I don't think we should ever make "bit-by-bit
identical" a must; I also don't think we would need to. As you say,
building packages nonreproducibly is difficult to define, and it
certainly is difficult to test for in a definite manner.

> > What parameters
> > are allowed to change need to be defined.
> 
> I sadly think this is impossible.

I agree that it will probably be a neverending effort, but I also think
it's the only way that it can reasonably be done.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Wed, 17 May 2017 22:54:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 17 May 2017 22:54:03 GMT) (full text, mbox, link).


Message #97 received at 844431@bugs.debian.org (full text, mbox, > (some) variation(s) and compare the results*. > > > > "Reproducible Builds" (in the sense of bit by bit identicall builds) is > > really a rather new field in the era of software (well, not really, but > > thats history and bit rotted until it was rediscovered in the early 2010s…) > > > > What is trivial, if given, is to show that a package is *un*reproducible. > > > > It's much harder to show that a package is reproducible. > > We should avoid a terminological confusion... > > Unreproducible means that "it will never be reproduced", which is quite > different from "it will always be reproduced". > Reproducible means that "it is possible to reproduce". > > So in fact it is much easier to show that something is reproducible > than unreproducible. > > There are situations where policy mandates that the build will be > different (for example setting DEB_BUILD_OPTIONS). > > And actually, we do not need packages to build always identically. > Instead we need a reliable way to rebuild them identically, which is a > lower bar. > > If (as it is planned) all packages are built by the autobuilders, then > we could provide a tool that rebuild a package (maybe by taking a > .buildinfo as input and downloading the same versions of the build > dependencies from snapshot.d.o) using the same setting as the autobuilders. > > Then policy would cover the issues that could still lead to a different > build (for example using timestamp, hardcoding hardware characteristic > of the build machine , etc.). > > Cheers, > -- > Bill. > > Imagine a large red swirl here. > > ">reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>
Cc: 844431@bugs.debian.org
Subject: Re: Bug#844431: policy: packages should be reproducible
Date: Thu, 18 May 2017 00:50:36 +0200
On Sun, May 14, 2017 at 11:15:26PM +0000, Holger Levsen wrote:
> On Mon, May 15, 2017 at 12:05:17AM +0200, Bill Allombert wrote:
> > On Sun, May 14, 2017 at 03:20:54PM +0000, Holger Levsen wrote:
> > > On Sun, May 14, 2017 at 05:05:36PM +0200, Bill Allombert wrote:
> > > a.) go to http://reproducible.debian.net/$srcpkg and see if its reproducible today.
> > As I said, I would like to check that my package build is reproducible before
> > I upload it, not after, so I can be sure that any bug is fixed in the
> > upload.
>  
> b.), b.0), c.) and d.) were given as possible "tools" *to build twice with 
> (some) variation(s) and compare the results*.
> 
> "Reproducible Builds" (in the sense of bit by bit identicall builds) is
> really a rather new field in the era of software (well, not really, but 
> thats history and bit rotted until it was rediscovered in the early 2010s…)
> 
> What is trivial, if given, is to show that a package is *un*reproducible.
> 
> It's much harder to show that a package is reproducible.

We should avoid a terminological confusion...

Unreproducible means that "it will never be reproduced", which is quite
different from "it will always be reproduced".
Reproducible means that "it is possible to reproduce".

So in fact it is much easier to show that something is reproducible
than unreproducible.

There are situations where policy mandates that the build will be
different (for example setting DEB_BUILD_OPTIONS).

And actually, we do not need packages to build always identically.
Instead we need a reliable way to rebuild them identically, which is a
lower bar.

If (as it is planned) all packages are built by the autobuilders, then
we could provide a tool that rebuild a package (maybe by taking a
.buildinfo as input and downloading the same versions of the build
dependencies from snapshot.d.o) using the same setting as the autobuilders.

Then policy would cover the issues that could still lead to a different
build (for example using timestamp, hardcoding hardware characteristic
of the build machine , etc.).

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Mon, 24 Jul 2017 21:12:02 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 24 Jul 2017 21:12:02 GMT) (full text, mbox, link).


Message #102 received at 844431@bugs.debian.org (full text, mbox, > we believe reproducible builds to be among the best practices today. > >... > > If it could be interpreted in the future to include things that are > not current practice today, it would be a stick to impose new rules. > > The main problem is the lack of an exact definition what > "packages build in a reproducible manner" includes, and what not. > > Bill already explained that "it is possible to reproduce" is a much > easier problem to solve than "it will always be reproduced". > > I would suggest a top-down approach to that: > > What are the high-level guarantees reproducible builds plans to make > for all packages in buster? > > What exactly is required from every single package for that, > and also realistic to achieve for buster? > > Once you have these plus a list of all remaining bugs, you can > go to the release team asking whether these can be considered > as release critical for buster. > > At that point documenting this status quo for policy should > be straightforward. > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > ">reply):

From: Adrian Bunk <bunk@debian.org>
To: reproducible-builds@lists.alioth.debian.org, 844431@bugs.debian.org
Subject: Re: Status update from the Reproducible Builds project
Date: Tue, 25 Jul 2017 00:08:21 +0300
>...
> Debian Policy
> =============
> 
> We are in the process of making reproducibility of packages something
> properly documented in policy.  Writing patches for policy is not easy,
> so we welcome input from everyone to be able to better consider all the
> needed facets.  See bug #844431 [16] for it.
> Also, we wish to remind everyone that Debian Policy aims at documenting
> current practices, it's not a "stick" to impose new rules.  That said,
> we believe reproducible builds to be among the best practices today.
>...

If it could be interpreted in the future to include things that are
not current practice today, it would be a stick to impose new rules.

The main problem is the lack of an exact definition what
"packages build in a reproducible manner" includes, and what not.

Bill already explained that "it is possible to reproduce" is a much 
easier problem to solve than "it will always be reproduced".

I would suggest a top-down approach to that:

What are the high-level guarantees reproducible builds plans to make 
for all packages in buster?

What exactly is required from every single package for that,
and also realistic to achieve for buster?

Once you have these plus a list of all remaining bugs, you can
go to the release team asking whether these can be considered
as release critical for buster.

At that point documenting this status quo for policy should
be straightforward.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Fri, 11 Aug 2017 23:21:06 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 11 Aug 2017 23:21:06 GMT) (full text, mbox, link).


Message #107 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Reproducibility in Policy
Date: Fri, 11 Aug 2017 16:08:47 -0700
[Message part 1 (text/plain, inline)]
control: user debian-policy@packages.debian.org
control: usertag = normative proposal

Hello,

==== Proposal: ====

This is what Holger and I think we should add to Policy, after
readability tweaks:

    Packages should build reproducibly, which for purposes of this
    document means that given

    - a version of a source package unpacked at a given path;
    - a set of versions of installed build-dependencies; and
    - a build architecture,

    repeatedly building the source package on the architecture with those
    versions of the build dependencies installed will produce bit-for-bit
    identical binary packages.

==== Explanation: ====

The definition from the reproducible builds group[1] says:

    A build is reproducible if given the same source code, build
    environment and build instructions, any party can recreate
    bit-by-bit identical copies of all specified artifacts.

    The relevant attributes of the build environment, the build
    instructions and the source code as well as the expected
    reproducible artifacts are defined by ... distributors.

i.e. Debian has to define the build environment, source code and build
instructions.  I think that my wording defines these as Debian currently
understands them.

Later, we could narrow the definition of build environment by adding
more constraints, but we're not there yet.

[1]  https://reproducible-builds.org/docs/definition/

-- 
Sean Whitton
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 00:33:07 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 00:33:07 GMT) (full text, mbox, link).


Message #112 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Reproducibility in Policy
Date: Fri, 11 Aug 2017 20:25:30 -0400
Dear Sean & Holger,

Thank you so much for working on this at the end of a tiring DebConf!

> […]
> Later, we could narrow the definition of build environment by adding
> more constraints, but we're not there yet.

That makes sense. Indeed, that even feels like the optimal approach
as it allows flexibility and experimentation, probably more important
the closer and closer we get to to 100% reproducibility.

Thanks again :)


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 01:09:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 01:09:03 GMT) (full text, mbox, link).


Message #117 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Fri, 11 Aug 2017 17:57:44 -0700
Sean Whitton <spwhitton@spwhitton.name> writes:

> ==== Proposal: ====

> This is what Holger and I think we should add to Policy, after
> readability tweaks:

>     Packages should build reproducibly, which for purposes of this
>     document means that given

>     - a version of a source package unpacked at a given path;
>     - a set of versions of installed build-dependencies; and
>     - a build architecture,

>     repeatedly building the source package on the architecture with those
>     versions of the build dependencies installed will produce bit-for-bit
>     identical binary packages.

I think we need to add all environment variables starting with DEB_* to
the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
package, for instance.

I feel like there are a bunch of other environment variables that have to
be consistent, although I'm not sure how to specify that since other
environment variables shouldn't matter.  But, say, setting GNUTARGET is
very likely to cause weirdness by changing how ld works.  There are
probably more interesting examples.

How does the current reproducible build testing work with the environment?
Maybe we should just document that for right now and relax it later if
needed?

> ==== Explanation: ====

> The definition from the reproducible builds group[1] says:

>     A build is reproducible if given the same source code, build
>     environment and build instructions, any party can recreate
>     bit-by-bit identical copies of all specified artifacts.

>     The relevant attributes of the build environment, the build
>     instructions and the source code as well as the expected
>     reproducible artifacts are defined by ... distributors.

> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

> Later, we could narrow the definition of build environment by adding
> 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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 01:39:03 GMT) (full text, mbox, link).


Acknowledgement sent to Daniel Kahn Gillmor <dkg@fifthhorseman.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 01:39:03 GMT) (full text, mbox, link).


Message #122 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Reproducibility in Policy
Date: Fri, 11 Aug 2017 20:22:22 -0400
Thanks for the proposal.  I like it!  A few nit-picks below:

On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:

>     - a version of a source package unpacked at a given path;

I don't like the idea of hard-coding a fixed build path requirement into
debian policy.  We're over 80% with variable build paths in unstable
already, and i want to keep the pressure up on this.  The build location
should not influence the binary output.


>     repeatedly building the source package on the architecture with

maybe s/on the architecture/on any machine of the same architecture/ ?

all the best,

    --dkg



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 03:39:05 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 03:39:05 GMT) (full text, mbox, link).


Message #127 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Fri, 11 Aug 2017 20:35:47 -0700
Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:

>>     - a version of a source package unpacked at a given path;

> I don't like the idea of hard-coding a fixed build path requirement into
> debian policy.  We're over 80% with variable build paths in unstable
> already, and i want to keep the pressure up on this.  The build location
> should not influence the binary output.

It shouldn't, but my understanding is that it currently does.  If you can
fix that, that's great, but until that's been 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.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 08:35:37 GMT) (full text, mbox, link).


Message #130 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>
To: Russ Allbery <rra@debian.org>, Sean Whitton <spwhitton@spwhitton.name>
Cc: reproducible-builds@lists.alioth.debian.org, 844431@bugs.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Sat, 12 Aug 2017 17:24:49 +0100
[Message part 1 (text/plain, inline)]
Hi,

Quoting Russ Allbery (2017-08-12 09:57:44)
> I think we need to add all environment variables starting with DEB_* to
> the prerequisites.  If you set DEB_BUILD_OPTIONS=nostrip or
> DEB_BUILD_MAINT_OPTIONS=hardening=all, you'll definitely get a different
> package, for instance.
> 
> I feel like there are a bunch of other environment variables that have to
> be consistent, although I'm not sure how to specify that since other
> environment variables shouldn't matter.  But, say, setting GNUTARGET is
> very likely to cause weirdness by changing how ld works.  There are
> probably more interesting examples.
> 
> How does the current reproducible build testing work with the environment?
> Maybe we should just document that for right now and relax it later if
> needed?

currently, dpkg-genbuildinfo records all environment variables in a .buildinfo
file which pass a whitelist check. The current whitelist is stored here:

https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Build/Info.pm#n50

I'm not proposing that this whole list should be added to policy. But the list
that ends up in policy must be a subset of the list of environment variables
that dpkg-genbuildinfo stores in the .buildinfo file. Thus:

 - this list from dpkg should give a number of good suggestions of which
   environment variables should be added to policy

 - if any additional variables are added, then they must be added to
   dpkg-genbuildinfo as well.

Thanks!

cheers, josch
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 10:03:05 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 10:03:05 GMT) (full text, mbox, link).


Message #135 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Sat, 12 Aug 2017 11:59:57 +0200
On Fri, Aug 11, 2017 at 04:08:47PM -0700, Sean Whitton wrote:
> control: user debian-policy@packages.debian.org
> control: usertag = normative proposal
> 
> Hello,
> 
> ==== Proposal: ====
> 
> This is what Holger and I think we should add to Policy, after
> readability tweaks:
> 
>     Packages should build reproducibly, which for purposes of this
>     document means that given
> 
>     - a version of a source package unpacked at a given path;
>     - a set of versions of installed build-dependencies; and
>     - a build architecture,
> 
>     repeatedly building the source package on the architecture with those
>     versions of the build dependencies installed will produce bit-for-bit
>     identical binary packages.
> 
> ==== Explanation: ====
> 
> The definition from the reproducible builds group[1] says:
> 
>     A build is reproducible if given the same source code, build
>     environment and build instructions, any party can recreate
>     bit-by-bit identical copies of all specified artifacts.
> 
>     The relevant attributes of the build environment, the build
>     instructions and the source code as well as the expected
>     reproducible artifacts are defined by ... distributors.
> 
> i.e. Debian has to define the build environment, source code and build
> instructions.  I think that my wording defines these as Debian currently
> understands them.

This require policy to define the build environment and build
instruction much more precisely than it does now, which does not
seems to be practical. Unless maybe if a reference implementation
is provided.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Owner recorded as Sean Whitton <spwhitton@spwhitton.name>. Request was from Sean Whitton <spwhitton@spwhitton.name> to control@bugs.debian.org. (Sat, 12 Aug 2017 16:33:09 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 18:27:05 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 18:27:05 GMT) (full text, mbox, link).


Message #142 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 11:23:14 -0700
[Message part 1 (text/plain, inline)]
control: tag -1 +patch

This patch incorporates the feedback given on the proposal I sent
yesterday, both in this bug and in person from Russ and Holger (thank
you to all).

I am seeking formal seconds for this patch, from any DD.

In particular:

- 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 they think may be allowed to vary

  - we should wait until .buildinfo is properly documented in policy,
    and then we can refer to that file

- we don't require reproducibility when build paths vary

  This is because

  - since there is not a consensus on whether we should require this,
    and there is strong consensus on the requirement of reproducibility
    if the path does /not/ vary, this issue should not block this change.
    We should open a separate bug against debian-policy

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 127b125..cc4b020 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or build system (for
 example, a package that builds the same source multiple times to
 generate different binary packages).
 
+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 versions of installed build dependencies;
+- a set of environment variable values; and
+- a build architecture,
+
+repeatedly building the source package on any machine of the same
+architecture with those versions of the build dependencies installed
+and exactly those environment variable values set will produce
+bit-for-bit identical binary packages.
+
 .. [#]
    See the file ``upgrading-checklist`` for information about policy
    which has changed between different versions of this document.
@@ -790,3 +806,7 @@ generate different binary packages).
    often creates either static linking or shared library conflicts, and,
    most importantly, increases the difficulty of handling security
    vulnerabilities in the duplicated code.
+
+.. [#]
+   This is Debian's precisification of the `reproducible-builds.org
+   definition <https://reproducible-builds.org/docs/definition/>`_.

-- 
Sean Whitton
[signature.asc (application/pgp-signature, inline)]

Added tag(s) patch. Request was from Sean Whitton <spwhitton@spwhitton.name> to 844431-submit@bugs.debian.org. (Sat, 12 Aug 2017 18:27:05 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 18:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 18:51:04 GMT) (full text, mbox, link).


Message #149 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 18:40:24 +0000
[Message part 1 (text/plain, inline)]
On Sat, Aug 12, 2017 at 11:23:14AM -0700, Sean Whitton wrote:
> I am seeking formal seconds for this patch, from any DD.
> 
> In particular:
> 
> - 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 they think may be allowed to vary
> 
>   - we should wait until .buildinfo is properly documented in policy,
>     and then we can refer to that file
> 
> - we don't require reproducibility when build paths vary
> 
>   This is because
> 
>   - since there is not a consensus on whether we should require this,
>     and there is strong consensus on the requirement of reproducibility
>     if the path does /not/ vary, this issue should not block this change.
>     We should open a separate bug against debian-policy
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.

very happily seconded, many thanks to everyone who has contributed to this bug
directly or "indirectly" (I'm thinking specifically about Lunar here).


-- 
cheers,
	Holger (who watched http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/reproducible-builds-status-update.vp8.webm today and was equally happy when seeing the whole audience agreeing this should be in policy - and the applause after Russ's closing statement was also very very nice…!)
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 18:54:02 GMT) (full text, mbox, link).


Acknowledgement sent to Ondrej Novy <novy@ondrej.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 18:54:03 GMT) (full text, mbox, link).


Message #154 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Ondrej Novy <novy@ondrej.org>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 14:50:19 -0400
[Message part 1 (text/plain, inline)]
Hi,

2017-08-12 14:23 GMT-04:00 Sean Whitton <spwhitton@spwhitton.name>:

> control: tag -1 +patch
>
> This patch incorporates the feedback given on the proposal I sent
> yesterday, both in this bug and in person from Russ and Holger (thank
> you to all).
>

seconded, thanks for working on this.

-- 
Best regards
 Ondřej Nový

Email: novy@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 19:27:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 19:27:02 GMT) (full text, mbox, link).


Message #159 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 12:25:49 -0700
Sean Whitton <spwhitton@spwhitton.name> writes:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.

Seconded.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 20:03:02 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 20:03:03 GMT) (full text, mbox, link).


Message #164 received at 844431@bugs.debian.org (full text, mbox, > > .. [#] > > See the file ``upgrading-checklist`` for information about policy > > which has changed between different versions of this document. > > @@ -790,3 +806,7 @@ generate different binary packages). > > often creates either static linking or shared library conflicts, and, > > most importantly, increases the difficulty of handling security > > vulnerabilities in the duplicated code. > > + > > +.. [#] > > + This is Debian's precisification of the `reproducible-builds.org > > + definition `_. > > > > "precisification" -> "more precise version" > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > ">reply):

From: Ximin Luo <infinity0@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 19:52:00 +0000
Sean Whitton:
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..cc4b020 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,22 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,
> +
> +repeatedly building the source package on any machine of the same
> +architecture with those versions of the build dependencies installed
> +and exactly those environment variable values set will produce
> +bit-for-bit identical binary packages.
> +

To echo dkg and others' comments, it would be nice if we could add here:

+Packages are encouraged to produce bit-for-bit identical binary packages even
+if most environment variables and build paths are varied. This is technically
+more difficult at the time of writing, but it is intended that this stricter
+definition would replace the above one, when appropriate in the future.

If this type of "intent" wording is not appropriate for Policy then disregard what I'm saying, I don't wish to block this patch for this reason.

>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +806,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.
> 

"precisification" -> "more precise version"

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 20:21:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 20:21:02 GMT) (full text, mbox, link).


Message #169 received at 844431@bugs.debian.org (full text, mbox, > disregard what I'm saying, I don't wish to block this 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 (rra@debian.org) > > &In-Reply-To=<877ey8tu9c.fsf@hope.eyrie.org>&References=<87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <0604e3a9-6572-507c-af88-cab2b8c604fd@debian.org> <877ey8tu9c.fsf@hope.eyrie.org>">reply):

From: Russ Allbery <rra@debian.org>
To: Ximin Luo <infinity0@debian.org>
Cc: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 13:18:23 -0700
Ximin Luo <infinity0@debian.org> writes:

> To echo dkg and others' comments, it would be nice if we could add here:

> +Packages are encouraged to produce bit-for-bit identical binary packages even
> +if most environment variables and build paths are varied. This is technically
> +more difficult at the time of writing, but it is intended that this stricter
> +definition would replace the above one, when appropriate in the future.

> If this type of "intent" wording is not appropriate for Policy then
> disregard what I'm saying, I don't wish to block this 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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 20:33:02 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 20:33:02 GMT) (full text, mbox, link).


Message #174 received at 844431@bugs.debian.org (full text, mbox, > > disregard what I'm saying, I don't wish to block this 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. > > I'm also seconding the original with or without this addition. > > > -- > cheers, > Holger &subject=Re: Bug#844431: Revised patch: seeking seconds&References=<87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <0604e3a9-6572-507c-af88-cab2b8c604fd@debian.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <877ey8tu9c.fsf@hope.eyrie.org> <20170812203034.GA851@layer-acht.org>&In-Reply-To=<20170812203034.GA851@layer-acht.org>">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: Ximin Luo <infinity0@debian.org>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 20:30:34 +0000
[Message part 1 (text/plain, inline)]
On Sat, Aug 12, 2017 at 01:18:23PM -0700, Russ Allbery wrote:
> > +Packages are encouraged to produce bit-for-bit identical binary packages even
> > +if most environment variables and build paths are varied. This is technically
> > +more difficult at the time of writing, but it is intended that this stricter
> > +definition would replace the above one, when appropriate in the future.
> 
> > If this type of "intent" wording is not appropriate for Policy then
> > disregard what I'm saying, I don't wish to block this 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.
 
I'm also seconding the original with or without this addition.


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 20:48:04 GMT) (full text, mbox, link).


Message #177 received at 844431@bugs.debian.org (full text, mbox, already and I think what you mean here is either "host architecture" or at > least "build and host architecture" or you need to mention that you are only > talking about native builds where build and host architecture are equal. > > Thanks! > > cheers, josch &subject=Re: Revised patch: seeking seconds&In-Reply-To=<150257075653.20937.3462548876194624932@localhost>&References=<87poc0zlv1.fsf@iris.silentflame.com> <150257075653.20937.3462548876194624932@localhost>">reply):

From: Johannes Schauer <josch@debian.org>
To: 844431@bugs.debian.org, Sean Whitton <spwhitton@spwhitton.name>
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Revised patch: seeking seconds
Date: Sun, 13 Aug 2017 05:45:56 +0100
[Message part 1 (text/plain, inline)]
Hi,

Quoting Sean Whitton (2017-08-13 03:23:14)
> +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 versions of installed build dependencies;
> +- a set of environment variable values; and
> +- a build architecture,

Policy §4.9 defines "build architecture" in the context of dpkg-architecture
already and I think what you mean here is either "host architecture" or at
least "build and host architecture" or you need to mention that you are only
talking about native builds where build and host architecture are equal.

Thanks!

cheers, josch
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 21:00:06 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 21:00:06 GMT) (full text, mbox, link).


Message #182 received at 844431@bugs.debian.org (full text, mbox, > dpkg-architecture already and I think what you mean here is either "host > > architecture" or at least "build and host architecture" or you need to > > mention that you are only talking about native builds where build and > > host architecture are equal. > > I suspect we want to say build and host architecture for right now. > (Maybe we can later aspire to making the build architecture not matter.) > > Thanks, good catch! > > -- > Russ Allbery (rra@debian.org) > > ">reply):

From: Russ Allbery <rra@debian.org>
To: Johannes Schauer <josch@debian.org>
Cc: 844431@bugs.debian.org, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 13:57:25 -0700
Johannes Schauer <josch@debian.org> writes:

> Policy §4.9 defines "build architecture" in the context of
> dpkg-architecture already and I think what you mean here is either "host
> architecture" or at least "build and host architecture" or you need to
> mention that you are only talking about native builds where build and
> host architecture are equal.

I suspect we want to say build and host architecture for right now.
(Maybe we can later aspire to making the build architecture not matter.)

Thanks, good catch!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 21:03:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 21:03:03 GMT) (full text, mbox, link).


Message #187 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Sat, 12 Aug 2017 14:01:30 -0700
Bill Allombert <ballombe@debian.org> writes:

> This require policy to define the build environment and build
> instruction much more precisely than it does now, which does not seems
> to be practical. Unless maybe if a reference implementation is provided.

I don't see anything in this proposal that would require a more precise
definition than we have in Sean's current proposal.  This is the standard
that we're already using for filing reproducible build bugs in the
archive, and it's been basically fine.

The tools aren't in place yet to make it super-easy for people to test for
themselves, but that's in the works, and that's also why it's a should
(not must) and there's infrastructure in place for Debian to check it for
you.

We can always aspire to get more formal and specific in the future, but
that's true of many other parts of Policy as well.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 21:45:03 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 21:45:03 GMT) (full text, mbox, link).


Message #192 received at 844431@bugs.debian.org (full text, mbox, enemy of good". I don't do reproducible builds for purely academic reasons, > I foremost want them to increase the security of user systems. > > > It shouldn't, but my understanding is that it currently does. If you can > > fix that, that's great, but until that's been 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. > > exactly. > > > -- > cheers, > Holger &subject=Re: Bug#844431: Reproducibility in Policy">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Reproducibility in Policy
Date: Sat, 12 Aug 2017 17:40:27 -0400
[Message part 1 (text/plain, inline)]
On Fri, Aug 11, 2017 at 08:35:47PM -0700, Russ Allbery wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> > I don't like the idea of hard-coding a fixed build path requirement into
> > debian policy. 

I don't *like* it neither but I think it's the sensible thing to do now.

> > We're over 80% with variable build paths in unstable
> > already, and i want to keep the pressure up on this.  The build location
> > should not influence the binary output.

I'd like to keep the pressure on this but and I think we can still that
while OTOH also trying to get closer to 100% first+too.

With build path variation reaching the worthwhile goal of having >98% reproducible
builds will be delayed by 1-2 years at least, so this is a classic "perfect is the
enemy of good". I don't do reproducible builds for purely academic reasons,
I foremost want them to increase the security of user systems.

> It shouldn't, but my understanding is that it currently does.  If you can
> fix that, that's great, but until that's been 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.

exactly.


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 22:39:02 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 12 Aug 2017 22:39:02 GMT) (full text, mbox, link).


Message #197 received at 844431@bugs.debian.org (full text, mbox, "more precise version" > > Our definition is not actually a /version/ of the > reproducible-builds.org definition -- that would imply that our > definition could replace the reproducible-builds.org definition, like > upgrading a package. > > 'precisification' means roughly "filling out the missing specification > when it is appropriate to fill it out", which is what the r-p.org > definition instructs distributors to do. > > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > index 127b125..6e32870 100644 > --- a/policy/ch-source.rst > +++ b/policy/ch-source.rst > @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for > example, a package that builds the same source multiple times to > generate different binary packages). > > +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 versions of installed build dependencies; > +- a set of environment variable values; > +- a build architecture; and > +- a host architecture, > + > +repeatedly building the source package for the build architecture on > +any machine of the host architecture with those versions of the build > +dependencies installed and exactly those environment variable values > +set will produce bit-for-bit identical binary packages. > + ">reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 15:34:35 -0700
[Message part 1 (text/plain, inline)]
Hello,

On Sat, Aug 12 2017, Russ Allbery wrote:

> I suspect we want to say build and host architecture for right now.
> (Maybe we can later aspire to making the build architecture not
> matter.)

On Sat, Aug 12 2017, Ximin Luo wrote:

> To echo dkg and others' comments, it would be nice if we could add
> here:
>
> +Packages are encouraged to produce bit-for-bit identical binary
> packages even +if most environment variables and build paths are
> varied. This is technically +more difficult at the time of writing,
> but it is intended that this stricter +definition would replace the
> above one, when appropriate in the future.

Here is an updated patch addressing these.  I reworded it to use
'recommended' and changed the tone to better suit policy.

Thank you Ximin, Russ and Johannes!

> "precisification" -> "more precise version"

Our definition is not actually a /version/ of the
reproducible-builds.org definition -- that would imply that our
definition could replace the reproducible-builds.org definition, like
upgrading a package.

'precisification' means roughly "filling out the missing specification
when it is appropriate to fill it out", which is what the r-p.org
definition instructs distributors to do.

diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 127b125..6e32870 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for
 example, a package that builds the same source multiple times to
 generate different binary packages).
 
+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 versions of installed build dependencies;
+- a set of environment variable values;
+- a build architecture; and
+- a host architecture,
+
+repeatedly building the source package for the build architecture on
+any machine of the host architecture with those versions of the build
+dependencies installed and exactly those environment variable values
+set will produce bit-for-bit identical binary packages.
+
+It is recommended that packages produce bit-for-bit identical binaries
+even if most environment variables and build paths are varied.  It is
+intended for this stricter standard to replace the above when it is
+easier for packages to meet it.
+
 .. [#]
    See the file ``upgrading-checklist`` for information about policy
    which has changed between different versions of this document.
@@ -790,3 +812,7 @@ generate different binary packages).
    often creates either static linking or shared library conflicts, and,
    most importantly, increases the difficulty of handling security
    vulnerabilities in the duplicated code.
+
+.. [#]
+   This is Debian's precisification of the `reproducible-builds.org
+   definition <https://reproducible-builds.org/docs/definition/>`_.

-- 
Sean Whitton
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sat, 12 Aug 2017 23:12:03 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sat, 12 Aug 2017 23:12:03 GMT) (full text, mbox, link).


Message #202 received at 844431@bugs.debian.org (full text, mbox, "more precise version" > > > > Our definition is not actually a /version/ of the > > reproducible-builds.org definition -- that would imply that our > > definition could replace the reproducible-builds.org definition, like > > upgrading a package. > > > > 'precisification' means roughly "filling out the missing specification > > when it is appropriate to fill it out", which is what the r-p.org > > definition instructs distributors to do. > > > > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > > index 127b125..6e32870 100644 > > --- a/policy/ch-source.rst > > +++ b/policy/ch-source.rst > > @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for > > example, a package that builds the same source multiple times to > > generate different binary packages). > > > > +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 versions of installed build dependencies; > > +- a set of environment variable values; > > +- a build architecture; and > > +- a host architecture, > > + > > +repeatedly building the source package for the build architecture on > > +any machine of the host architecture with those versions of the build > > +dependencies installed and exactly those environment variable values > > +set will produce bit-for-bit identical binary packages. > > + > > +It is recommended that packages produce bit-for-bit identical binaries > > +even if most environment variables and build paths are varied. It is > > +intended for this stricter standard to replace the above when it is > > +easier for packages to meet it. > > + > > .. [#] > > See the file ``upgrading-checklist`` for information about policy > > which has changed between different versions of this document. > > @@ -790,3 +812,7 @@ generate different binary packages). > > often creates either static linking or shared library conflicts, and, > > most importantly, increases the difficulty of handling security > > vulnerabilities in the duplicated code. > > + > > +.. [#] > > + This is Debian's precisification of the `reproducible-builds.org > > + definition `_. &subject=Re: Bug#844431: Revised patch: seeking seconds&In-Reply-To=<6fa5808d-93dd-fad3-7e43-af22ba0e48fd@debian.org>&References=<87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <150257075653.20937.3462548876194624932@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87tw1ca4i2.fsf@hope.eyrie.org> <87fucwza84.fsf@iris.silentflame.com> <6fa5808d-93dd-fad3-7e43-af22ba0e48fd@debian.org>">reply):

From: Ximin Luo <infinity0@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sat, 12 Aug 2017 23:09:00 +0000
Sean Whitton:
> [..]
> 
> Here is an updated patch addressing these.  I reworded it to use
> 'recommended' and changed the tone to better suit policy.
> 
> Thank you Ximin, Russ and Johannes!
> 
>> "precisification" -> "more precise version"
> 
> Our definition is not actually a /version/ of the
> reproducible-builds.org definition -- that would imply that our
> definition could replace the reproducible-builds.org definition, like
> upgrading a package.
> 
> 'precisification' means roughly "filling out the missing specification
> when it is appropriate to fill it out", which is what the r-p.org
> definition instructs distributors to do.
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.
> 
> 

Thanks! Seconded.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Sun, 13 Aug 2017 12:27:03 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 13 Aug 2017 12:27:03 GMT) (full text, mbox, link).


Message #207 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sun, 13 Aug 2017 05:24:35 -0700
On Sat, Aug 12 2017, Ximin Luo wrote:

> Thanks! Seconded.

Just to be clear, we are waiting on one more second for the version
that refers to build and target architecture.

-- 
Sean Whitton



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sun, 13 Aug 2017 13:30:03 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sun, 13 Aug 2017 13:30:03 GMT) (full text, mbox, link).


Message #212 received at 844431@bugs.debian.org (full text, mbox, "more precise version" > > > > Our definition is not actually a /version/ of the > > reproducible-builds.org definition -- that would imply that our > > definition could replace the reproducible-builds.org definition, like > > upgrading a package. > > > > 'precisification' means roughly "filling out the missing specification > > when it is appropriate to fill it out", which is what the r-p.org > > definition instructs distributors to do. > > > > diff --git a/policy/ch-source.rst b/policy/ch-source.rst > > index 127b125..6e32870 100644 > > --- a/policy/ch-source.rst > > +++ b/policy/ch-source.rst > > @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for > > example, a package that builds the same source multiple times to > > generate different binary packages). > > > > +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 versions of installed build dependencies; > > +- a set of environment variable values; > > +- a build architecture; and > > +- a host architecture, > > + > > +repeatedly building the source package for the build architecture on > > +any machine of the host architecture with those versions of the build > > +dependencies installed and exactly those environment variable values > > +set will produce bit-for-bit identical binary packages. > > + > > +It is recommended that packages produce bit-for-bit identical binaries > > +even if most environment variables and build paths are varied. It is > > +intended for this stricter standard to replace the above when it is > > +easier for packages to meet it. > > + > > .. [#] > > See the file ``upgrading-checklist`` for information about policy > > which has changed between different versions of this document. > > @@ -790,3 +812,7 @@ generate different binary packages). > > often creates either static linking or shared library conflicts, and, > > most importantly, increases the difficulty of handling security > > vulnerabilities in the duplicated code. > > + > > +.. [#] > > + This is Debian's precisification of the `reproducible-builds.org > > + definition `_. > > seconded & thanks for these improvements! &subject=Re: Bug#844431: Revised patch: seeking seconds">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sun, 13 Aug 2017 09:27:12 -0400
[Message part 1 (text/plain, inline)]
On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
> Here is an updated patch addressing these.  I reworded it to use
> 'recommended' and changed the tone to better suit policy.
> 
> Thank you Ximin, Russ and Johannes!
> 
> > "precisification" -> "more precise version"
> 
> Our definition is not actually a /version/ of the
> reproducible-builds.org definition -- that would imply that our
> definition could replace the reproducible-builds.org definition, like
> upgrading a package.
> 
> 'precisification' means roughly "filling out the missing specification
> when it is appropriate to fill it out", which is what the r-p.org
> definition instructs distributors to do.
> 
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.

seconded & thanks for these improvements!


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sun, 13 Aug 2017 14:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to gregor herrmann <gregoa@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sun, 13 Aug 2017 14:51:03 GMT) (full text, mbox, link).


Message #217 received at 844431@bugs.debian.org (full text, mbox, reply):

From: gregor herrmann <gregoa@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sun, 13 Aug 2017 10:28:58 -0400
[Message part 1 (text/plain, inline)]
On Sat, 12 Aug 2017 15:34:35 -0700, Sean Whitton wrote:

> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.


Seconded.

Thanks to everyone for their work on this.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Sean Whitton <spwhitton@spwhitton.name> to control@bugs.debian.org. (Mon, 14 Aug 2017 16:24:04 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 17:57:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 17:57:03 GMT) (full text, mbox, link).


Message #224 received at 844431@bugs.debian.org (full text, mbox, of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > &In-Reply-To=<20170815175401.awfox72lfpt5k5p7@localhost>&References=<1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost>">reply):

From: Adrian Bunk <bunk@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 20:54:01 +0300
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 they think may be allowed to vary
> 
>   - we should wait until .buildinfo is properly documented in policy,
>     and then we can refer to that file
>...

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.

> Sean Whitton

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 18:09:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 18:09:03 GMT) (full text, mbox, link).


Message #229 received at 844431@bugs.debian.org (full text, mbox, of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > ">reply):

From: Adrian Bunk <bunk@debian.org>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 21:05:29 +0300
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 versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
>...

Is identical building on any kernel required (and tested)?

Examples:

A self-compiled kernel with CONFIG_IPV6=n

Imagine the next time Linus changes the kernel versioning,
he chooses <year>.<month>.<revision>
Will every reproducible package in buster build identical on the
bullseye+1 kernel 2022.11.321 ? [1]

> Sean Whitton

cu
Adrian

[1] the wheezy LTS updates are now built on buildds running stretch
    kernels, and in buster we will have the similar situation that
    nearly everyting in the initial release will be built on stretch
    kernels while post-release updates will be built on buster,
    bullseye and bullseye+1 kernels

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 18:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 18:51:03 GMT) (full text, mbox, link).


Message #234 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Adrian Bunk <bunk@debian.org>
Cc: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 11:49:22 -0700
Adrian Bunk <bunk@debian.org> 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 the planned next step here is to publish the *.buildinfo files,
which contain a specification of the environment variables the build cares
about, and then Policy can be modified to include a description of
*.buildinfo files and how to use them.  As part of those changes, we'd
certainly update the definition of reproducible to reference matching the
environment specified in the corresponding *.buildinfo file.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 19:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 19:15:03 GMT) (full text, mbox, link).


Message #239 received at 844431@bugs.debian.org (full text, mbox, of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > ">reply):

From: Adrian Bunk <bunk@debian.org>
To: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 22:09:30 +0300
On Tue, Aug 15, 2017 at 11:49:22AM -0700, Russ Allbery wrote:
> Adrian Bunk <bunk@debian.org> 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 the planned next step here is to publish the *.buildinfo files,
> which contain a specification of the environment variables the build cares
> about, and then Policy can be modified to include a description of
> *.buildinfo files and how to use them.  As part of those changes, we'd
> certainly update the definition of reproducible to reference matching the
> environment specified in the corresponding *.buildinfo file.

I do understand that.

My point is that we now have an official definition what is required
for a package to be reproducible, and what is not required.

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 definition must not show up as non-reproducible in tracker/DDPO 
based on results from the reproducible infrastructure.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 19:51:06 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 19:51:06 GMT) (full text, mbox, link).


Message #244 received at 844431@bugs.debian.org (full text, mbox, policy definition must not show up as non-reproducible in tracker/DDPO based > on results from the reproducible infrastructure") doesnt really makes sense: > if a package shows up as unreproducible somewhere, it's not reproducible > according to our definition! > > > -- > cheers, > Holger &References=<1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <20170815194955.GD2458@layer-acht.org>&In-Reply-To=<20170815194955.GD2458@layer-acht.org>">reply):

From: Holger Levsen <holger@layer-acht.org>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 19:49:55 +0000
[Message part 1 (text/plain, inline)]
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 to be reproducible.

I believe we'll continue to file sensible bug reports like we have done in
the last four years.

> Another example is that 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.
 
I disagree that we should modfiy the results of actual tests based on wishful
thinking or some definition somewhere, even if it's our beloved debian-policy.

It's certainly possible that a package becomes unreproducible, for known or
unknown reasons (hopefully by now we understand most of them (or have the means
to find out)), at any point in time. And then tracker/DDPO should certainly
show that…

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:
if a package shows up as unreproducible somewhere, it's not reproducible
according to our definition!


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 20:00:12 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 20:00:12 GMT) (full text, mbox, link).


Message #249 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org
Cc: Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 19:57:27 +0000
[Message part 1 (text/plain, inline)]
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
> bullseye+1 kernel 2022.11.321 ? [1]

my crystal ball is broken, sorry…
 
> [1] the wheezy LTS updates are now built on buildds running stretch
>     kernels, and in buster we will have the similar situation that
>     nearly everyting in the initial release will be built on stretch
>     kernels while post-release updates will be built on buster,
>     bullseye and bullseye+1 kernels
 
there surely are situations where different kernels (much like different
libraries) will cause variations in the build artifacts. many times it
will not matter and sometimes it will and we don't really have much experience
with that *yet*.

I'm inclined to file a bug report against dpkg to document the kernel 
used in the .buildinfo files and (hereby) am asking the reproducible builds team
for comments / advice on this.

And probably we should amend debian-policy for this too, but I also 
think we'd rather do this via a new bug report at some later point in time.

Thanks, Adrian, for making sure we don't forget (this pretty old aspect).


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 20:03:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 20:03:02 GMT) (full text, mbox, link).


Message #254 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Adrian Bunk <bunk@debian.org>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 13:00:00 -0700
Adrian Bunk <bunk@debian.org> 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 definition must not show up as non-reproducible in tracker/DDPO 
> based on results from the reproducible infrastructure.

This seems really inflexible and unnecessarily absolutist.  I don't agree
with taking this approach.

The point of adding this definition to Policy is that we're setting a new
minimum bar for packages in Debian to meet.  We're giving official
blessing to this requirement for Debian packages (at the normal bug level,
not RC bug, for now), meaning this is a goal that the project is working
towards and something every packager should think about at this level.

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 four years ago.  They should continue to work on making package
builds more reproducible and raising the bar for reproducibility as makes
sense for their goals and judging the impact of that.  Once any new
requirements reach maturity and look feasible and have some project
committment, we'll change Policy to set a new baseline for the whole
project.  But the reproducible builds work should not *wait* for that, and
should definitely push forward and experiment just as they have up until
now.

I do think it might be worth considering distinguishing between packages
that are minimally reproducible and packages that meet higher
reproducibility bars (such as not caring 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 all.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 20:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 15 Aug 2017 20:15:03 GMT) (full text, mbox, link).


Message #259 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: Adrian Bunk <bunk@debian.org>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 13:10:37 -0700
[Message part 1 (text/plain, inline)]
Hello,

On Tue, Aug 15 2017, Russ Allbery wrote:

> Adrian Bunk <bunk@debian.org> 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 definition must not show up as non-reproducible in
>> tracker/DDPO based on results from the reproducible infrastructure.
>
> This seems really inflexible and unnecessarily absolutist.  I don't
> agree with taking this approach.
>
> The point of adding this definition to Policy is that we're setting a
> new minimum bar for packages in Debian to meet.

Right.  More generally, the only thing that this new section of policy
constrains is the severities that may be used when filing bugs.  This is
how policy changes are meant to work -- they control bug severities
against packages, not what appears on tracking web pages.

-- 
Sean Whitton
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 21:03:02 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 21:03:02 GMT) (full text, mbox, link).


Message #264 received at 844431@bugs.debian.org (full text, mbox, > DDPO: > https://qa.debian.org/developer.php?email=debian-openoffice@lists.debian.org > red "unrep" entries > > Maintainer dashboard: > https://udd.debian.org/dmd/?email1=debian-openoffice%40lists.debian.org > red "(un)reproducible" entries [1] > > Let's look at the mdds package, that has red unreproducible entries in > the maintainer dashboard: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html > > mdds is unreproducible only in sid since more things (including the > build path) are varied there. The information behind "differences" > confirms that the build path is the only issue. > > According to policy, mdds is reproducible. > > Unless policy is supposed to be completely detached from reality, > the criteria for claiming in various places that a package is > unreproducible have to match the policy definition of reproducibility. > > cu > Adrian > > [1] the FTBFS entries are actually problems in the reproducible infrastructure > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out ">reply):

From: Adrian Bunk <bunk@debian.org>
To: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 00:01:37 +0300
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 four years ago.  They should continue to work on making package
> builds more reproducible and raising the bar for reproducibility as makes
> sense for their goals and judging the impact of that.  Once any new
> requirements reach maturity and look feasible and have some project
> committment, we'll change Policy to set a new baseline for the whole
> project.  But the reproducible builds work should not *wait* for that, and
> should definitely push forward and experiment just as they have up until
> now.
>...

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 not reproducible,
when it actually is reproducible according to policy?

Let me explain with examples how this information is presented 
to maintainers:

Tracker:
https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

DDPO:
https://qa.debian.org/developer.php?email=debian-openoffice@lists.debian.org
red "unrep" entries

Maintainer dashboard:
https://udd.debian.org/dmd/?email1=debian-openoffice@lists.debian.org
red "(un)reproducible" entries [1]

Let's look at the mdds package, that has red unreproducible entries in
the maintainer dashboard:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html

mdds is unreproducible only in sid since more things (including the 
build path) are varied there. The information behind "differences"
confirms that the build path is the only issue.

According to policy, mdds is reproducible.

Unless policy is supposed to be completely detached from reality,
the criteria for claiming in various places that a package is 
unreproducible have to match the policy definition of reproducibility.

cu
Adrian

[1] the FTBFS entries are actually problems in the reproducible infrastructure

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 21:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 21:15:03 GMT) (full text, mbox, link).


Message #269 received at 844431@bugs.debian.org (full text, mbox, > policy definition must not show up as non-reproducible in tracker/DDPO based > > on results from the reproducible infrastructure") doesnt really makes sense: > > if a package shows up as unreproducible somewhere, it's not reproducible > > according to our definition! > > Again, reproducible means that it _can_ be reproduced. As long as a well-know > process allows to reproduce the package, it is reproducible. > > What you define is a different concept that deserve a different name. > > Cheers, > -- > Bill. > > Imagine a large red swirl here. > > &subject=Re: Bug#844431: Revised patch: seeking seconds&References=<1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815194955.GD2458@layer-acht.org> <20170815211016.GB7385@yellowpig>&In-Reply-To=<20170815211016.GB7385@yellowpig>">reply):

From: Bill Allombert <ballombe@debian.org>
To: Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Cc: Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 23:10:16 +0200
On Tue, Aug 15, 2017 at 07:49:55PM +0000, 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:
> if a package shows up as unreproducible somewhere, it's not reproducible
> according to our definition!

Again, reproducible means that it _can_ be reproduced. As long as a well-know
process allows to reproduce the package, it is reproducible.

What you define is a different concept that deserve a different name.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 21:36:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 21:36:03 GMT) (full text, mbox, link).


Message #274 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 23:33:11 +0200
On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
> Adrian Bunk <bunk@debian.org> 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 definition must not show up as non-reproducible in tracker/DDPO 
> > based on results from the reproducible infrastructure.
> 
> This in absolutely no way constrains the reproducible build team from
> working on raising the bar in the future.

Adrian is speaking of DDPO, not of reproducible-builds.org.
reproducible-builds.org website woud still be free to list other
requirements, and DDPO could even display both results.

I am still concerned that there will be no reliable way for maintainers
to check whether a package is reproducible according to policy before
uploading it to the archive.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 21:39:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Tue, 15 Aug 2017 21:39:03 GMT) (full text, mbox, link).


Message #279 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Adrian Bunk <bunk@debian.org>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 14:37:48 -0700
Adrian Bunk <bunk@debian.org> 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 not reproducible,
> when it actually is reproducible according to policy?

Yes.  Ideally one would distinguish between those various definitions of
reproducible, though, and present all of them.

> Unless policy is supposed to be completely detached from reality, the
> criteria for claiming in various places that a package is unreproducible
> have to match the policy definition of reproducibility.

No, I don't agree.  This is not how we do things in Debian.  There is
quite a bit of information that we give developers about possible flaws in
their package, from Lintian and build log analysis and many other things,
that is not required by Policy.  This is no different.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#844431; Package debian-policy. (Tue, 15 Aug 2017 23:03:01 GMT) (full text, mbox, link).


Acknowledgement sent to Sean Whitton <spwhitton@spwhitton.name>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 15 Aug 2017 23:03:01 GMT) (full text, mbox, link).


Message #284 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Tue, 15 Aug 2017 16:01:00 -0700
[Message part 1 (text/plain, inline)]
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 policy?

Yes, if your bug is of 'wishlist' severity.

-- 
Sean Whitton
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 05:33:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 05:33:03 GMT) (full text, mbox, link).


Message #289 received at 844431@bugs.debian.org (full text, mbox, and red warnings in DDPO and Maintainer Dashboard. > > Is it for you as policy editor perfectly fine or a bug in the > reproducible infrastructure when Tracker states (based on the > latest results from the reproducible builds infrastructure) > "Does not build reproducibly during testing" for packages > that are reproducible according to policy? > > > Sean Whitton > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > ">reply):

From: Adrian Bunk <bunk@debian.org>
To: 844431@bugs.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 08:30:17 +0300
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 package is not reproducible,
> > when it actually is reproducible according to policy?
> 
> Yes, if your bug is of 'wishlist' severity.

You are not answering to any of the examples I gave in the email you
answered to.

"Does not build reproducibly during testing" statements in Tracker,
and red warnings in DDPO and Maintainer Dashboard.

Is it for you as policy editor perfectly fine or a bug in the 
reproducible infrastructure when Tracker states (based on the
latest results from the reproducible builds infrastructure)
"Does not build reproducibly during testing" for packages
that are reproducible according to policy?

> Sean Whitton

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 10:27:04 GMT) (full text, mbox, link).


Acknowledgement sent to Mattia Rizzolo <mattia@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 10:27:04 GMT) (full text, mbox, link).


Message #294 received at 844431@bugs.debian.org (full text, mbox, > > > And indeed it's not reproducible according to policy: it's storing the > build user at the very least. > > > > > Let's look at the mdds package, that has red unreproducible entries in > > the maintainer dashboard: > > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html > > > > mdds is unreproducible only in sid since more things (including the > > build path) are varied there. The information behind "differences" > > confirms that the build path is the only issue. > > > > According to policy, mdds is reproducible. > > > > And indeed its unreproducibility is not reported in tracker and ddpo (DMD > does because it's using a source data that includes everything, not just > the state we want to push. But then, DMD has a tendency to show *lots* of > things, if you disagree with it, please take it to the DMD maintainer, not > us). > > Unless policy is supposed to be completely detached from reality, > > the criteria for claiming in various places that a package is > > unreproducible have to match the policy definition of reproducibility. > > > > IMHO, you are arguing about a non existent issue. I believe we are always > being reasonable, otherwise I'd like to ask you to point us to actual > situation where we could have acted better. Yes, I'm aware of the > src:libreoffice case. ">reply):

From: Mattia Rizzolo <mattia@debian.org>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 10:24:07 +0000
[Message part 1 (text/plain, inline)]
On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <bunk@debian.org> wrote:

> Tracker:
> https://tracker.debian.org/pkg/hsqldb1.8.0
> "Does not build reproducibly during testing"
>

And indeed it's not reproducible according to policy: it's storing the
build user at the very least.

>
> Let's look at the mdds package, that has red unreproducible entries in
> the maintainer dashboard:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mdds.html
>
> mdds is unreproducible only in sid since more things (including the
> build path) are varied there. The information behind "differences"
> confirms that the build path is the only issue.
>
> According to policy, mdds is reproducible.
>

And indeed its unreproducibility is not reported in tracker and ddpo (DMD
does because it's using a source data that includes everything, not just
the state we want to push.  But then, DMD has a tendency to show *lots* of
things, if you disagree with it, please take it to the DMD maintainer, not
us).

Unless policy is supposed to be completely detached from reality,
> the criteria for claiming in various places that a package is
> unreproducible have to match the policy definition of reproducibility.
>

IMHO, you are arguing about a non existent issue.  I believe we are always
being reasonable, otherwise I'd like to ask you to point us to actual
situation where we could have acted better.  Yes, I'm aware of the
src:libreoffice case.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 10:57:03 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 10:57:03 GMT) (full text, mbox, link).


Message #299 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Ximin Luo <infinity0@debian.org>
To: Bill Allombert <ballombe@debian.org>, Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 10:51:00 +0000
Bill Allombert:
> On Tue, Aug 15, 2017 at 01:00:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk <bunk@debian.org> 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 definition must not show up as non-reproducible in tracker/DDPO 
>>> based on results from the reproducible infrastructure.
>>
>> This in absolutely no way constrains the reproducible build team from
>> working on raising the bar in the future.
> 
> Adrian is speaking of DDPO, not of reproducible-builds.org.
> reproducible-builds.org website woud still be free to list other
> requirements, and DDPO could even display both results.
> 
> I am still concerned that there will be no reliable way for maintainers
> to check whether a package is reproducible according to policy before
> uploading it to the archive.
> 

Did nobody mention

$ reprotest --dont-vary build_path auto xxx.dsc -- schroot unstable-amd64-sbuild

yet?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 11:24:02 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 11:24:03 GMT) (full text, mbox, link).


Message #304 received at 844431@bugs.debian.org (full text, mbox, > > > And indeed it's not reproducible according to policy: it's storing the > > build user at the very least. > >... > > What makes you so confident that this package is not reproducible > according to policy? > > According to policy, storing the value of $USER in the binary > is clearly permitted for a reproducible package. [1] > > As long as the reproducible builds infrastructure varies $USER instead > of following the policy definition, it is not suitable for determining > whether or not a package is reproducible according to policy. > > And what the reproducible builds infrastructure pushes as > Does not build reproducibly during testing > to tracker and DDPO is therefore not usable for determining > reproducibility according to policy. > > cu > Adrian > > [1] I haven't checked what exactly this package does > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > &References=<87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost>&In-Reply-To=<20170816112108.2vs35dijuhsce5eo@localhost>">reply):

From: Adrian Bunk <bunk@debian.org>
To: 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 14:21:09 +0300
On Wed, Aug 16, 2017 at 10:24:07AM +0000, Mattia Rizzolo wrote:
> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <bunk@debian.org> wrote:
> 
> > Tracker:
> > https://tracker.debian.org/pkg/hsqldb1.8.0
> > "Does not build reproducibly during testing"
> 
> And indeed it's not reproducible according to policy: it's storing the
> build user at the very least.
>...

What makes you so confident that this package is not reproducible 
according to policy?

According to policy, storing the value of $USER in the binary
is clearly permitted for a reproducible package. [1]

As long as the reproducible builds infrastructure varies $USER instead 
of following the policy definition, it is not suitable for determining 
whether or not a package is reproducible according to policy.

And what the reproducible builds infrastructure pushes as
   Does not build reproducibly during testing
to tracker and DDPO is therefore not usable for determining
reproducibility according to policy.

cu
Adrian

[1] I haven't checked what exactly this package does

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 11:42:08 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 11:42:08 GMT) (full text, mbox, link).


Message #309 received at 844431@bugs.debian.org (full text, mbox, >> > >> And indeed it's not reproducible according to policy: it's storing the > >> build user at the very least. > >> ... > > > > What makes you so confident that this package is not reproducible > > according to policy? > > > > According to policy, storing the value of $USER in the binary > > is clearly permitted for a reproducible package. [1] > > > > As long as the reproducible builds infrastructure varies $USER instead > > of following the policy definition, it is not suitable for determining > > whether or not a package is reproducible according to policy. > > > > And what the reproducible builds infrastructure pushes as > > Does not build reproducibly during testing > > to tracker and DDPO is therefore not usable for determining > > reproducibility according to policy. > > > > cu > > Adrian > > > > [1] I haven't checked what exactly this package does > > > > Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time. > > The sentence I amended said "most environment variables" so our intent is clear. If we want to fix this now, I would suggest amending: > > - a set of environment variable values; and > + a set of reserved environment variable values; and > > then later: > > + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > &subject=Re: Bug#844431: Revised patch: seeking seconds&In-Reply-To=<6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org>&References=<87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost> <6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org>">reply):

From: Ximin Luo <infinity0@debian.org>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 11:37:00 +0000
Adrian Bunk:
> On Wed, Aug 16, 2017 at 10:24:07AM +0000, Mattia Rizzolo wrote:
>> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <bunk@debian.org> wrote:
>>
>>> Tracker:
>>> https://tracker.debian.org/pkg/hsqldb1.8.0
>>> "Does not build reproducibly during testing"
>>
>> And indeed it's not reproducible according to policy: it's storing the
>> build user at the very least.
>> ...
> 
> What makes you so confident that this package is not reproducible 
> according to policy?
> 
> According to policy, storing the value of $USER in the binary
> is clearly permitted for a reproducible package. [1]
> 
> As long as the reproducible builds infrastructure varies $USER instead 
> of following the policy definition, it is not suitable for determining 
> whether or not a package is reproducible according to policy.
> 
> And what the reproducible builds infrastructure pushes as
>    Does not build reproducibly during testing
> to tracker and DDPO is therefore not usable for determining
> reproducibility according to policy.
> 
> cu
> Adrian
> 
> [1] I haven't checked what exactly this package does
> 

Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time.

The sentence I amended said "most environment variables" so our intent is clear. If we want to fix this now, I would suggest amending:

- a set of environment variable values; and
+ a set of reserved environment variable values; and

then later:

+ A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 15:09:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 15:09:03 GMT) (full text, mbox, link).


Message #314 received at 844431@bugs.debian.org (full text, mbox, > >> > > >> And indeed it's not reproducible according to policy: it's storing the > > >> build user at the very least. > > >> ... > > > > > > What makes you so confident that this package is not reproducible > > > according to policy? > > > > > > According to policy, storing the value of $USER in the binary > > > is clearly permitted for a reproducible package. [1] > > > > > > As long as the reproducible builds infrastructure varies $USER instead > > > of following the policy definition, it is not suitable for determining > > > whether or not a package is reproducible according to policy. > > > > > > And what the reproducible builds infrastructure pushes as > > > Does not build reproducibly during testing > > > to tracker and DDPO is therefore not usable for determining > > > reproducibility according to policy. > > > > > > cu > > > Adrian > > > > > > [1] I haven't checked what exactly this package does > > > > > > > Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time. > >... > > What is the point of getting "something" into policy, when it is known > to not match existing practice and that what is being added to policy > will be ignored by everyone? > > > The sentence I amended said "most environment variables" so our intent is clear. > >... > > This is not about "intent", this is about giving an exact definition > of reproducibility for Debian. > > The definition should then match what is recorded in .buildinfo > and what the reproducible builds infrastructure is testing. > > > X > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. &subject=Re: Bug#844431: Revised patch: seeking seconds">reply):

From: Adrian Bunk <bunk@debian.org>
To: 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 18:06:08 +0300
On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Aug 16, 2017 at 10:24:07AM +0000, Mattia Rizzolo wrote:
> >> On Tue, 15 Aug 2017, 11:02 p.m. Adrian Bunk <bunk@debian.org> wrote:
> >>
> >>> Tracker:
> >>> https://tracker.debian.org/pkg/hsqldb1.8.0
> >>> "Does not build reproducibly during testing"
> >>
> >> And indeed it's not reproducible according to policy: it's storing the
> >> build user at the very least.
> >> ...
> > 
> > What makes you so confident that this package is not reproducible 
> > according to policy?
> > 
> > According to policy, storing the value of $USER in the binary
> > is clearly permitted for a reproducible package. [1]
> > 
> > As long as the reproducible builds infrastructure varies $USER instead 
> > of following the policy definition, it is not suitable for determining 
> > whether or not a package is reproducible according to policy.
> > 
> > And what the reproducible builds infrastructure pushes as
> >    Does not build reproducibly during testing
> > to tracker and DDPO is therefore not usable for determining
> > reproducibility according to policy.
> > 
> > cu
> > Adrian
> > 
> > [1] I haven't checked what exactly this package does
> > 
> 
> Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time.
>...

What is the point of getting "something" into policy, when it is known 
to not match existing practice and that what is being added to policy 
will be ignored by everyone?

> The sentence I amended said "most environment variables" so our intent is clear.
>...

This is not about "intent", this is about giving an exact definition
of reproducibility for Debian.

The definition should then match what is recorded in .buildinfo
and what the reproducible builds infrastructure is testing.

> X

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 15:30:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@stusta.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 15:30:04 GMT) (full text, mbox, link).


Message #319 received at 844431@bugs.debian.org (full text, mbox, of reproducible builds. > > The definition does not match any past, present or future practice in Debian. > > Including the people who want this change to policy, there seems to be > noone intending to use this definition of reproducibility. > > Adding this to policy would do more harm than good. > > E.g. tracker.d.o saying "Does not build reproducibly during testing" &subject=Re: Bug#844431: Revised patch: Oppose&References=<87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <150257075653.20937.3462548876194624932@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87tw1ca4i2.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87fucwza84.fsf@iris.silentflame.com> <20170816152603.gvyvthm6anechrhi@localhost>&In-Reply-To=<20170816152603.gvyvthm6anechrhi@localhost>">reply):

From: Adrian Bunk <bunk@stusta.de>
To: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 18:26:03 +0300
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, Aug 12, 2017 at 03:34:35PM -0700, Sean Whitton wrote:
>...
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index 127b125..6e32870 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -661,6 +661,28 @@ particularly complex or unintuitive source layout or build system (for
>  example, a package that builds the same source multiple times to
>  generate different binary packages).
>  
> +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 versions of installed build dependencies;
> +- a set of environment variable values;
> +- a build architecture; and
> +- a host architecture,
> +
> +repeatedly building the source package for the build architecture on
> +any machine of the host architecture with those versions of the build
> +dependencies installed and exactly those environment variable values
> +set will produce bit-for-bit identical binary packages.
> +
> +It is recommended that packages produce bit-for-bit identical binaries
> +even if most environment variables and build paths are varied.  It is
> +intended for this stricter standard to replace the above when it is
> +easier for packages to meet it.
> +
>  .. [#]
>     See the file ``upgrading-checklist`` for information about policy
>     which has changed between different versions of this document.
> @@ -790,3 +812,7 @@ generate different binary packages).
>     often creates either static linking or shared library conflicts, and,
>     most importantly, increases the difficulty of handling security
>     vulnerabilities in the duplicated code.
> +
> +.. [#]
> +   This is Debian's precisification of the `reproducible-builds.org
> +   definition <https://reproducible-builds.org/docs/definition/>`_.

I hereby oppose the addition of this to policy.

It is not true that this would be "Debian's precisification"
of reproducible builds. 

The definition does not match any past, present or future practice in Debian.

Including the people who want this change to policy, there seems to be 
noone intending to use this definition of reproducibility.

Adding this to policy would do more harm than good.

E.g. tracker.d.o saying "Does not build reproducibly during testing" 
based on a definition of reproducibility that is quite different from 
the official "Debian precisification" would only create confusion.

> Sean Whitton

cu
Adrian

- -- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlmUZAsACgkQiNJCh6LY
mLG9RhAAjr0dgpxSv9lnqM3+4AR3JeWwTaj9J118Efsr4qmSbgK9gE3HE3bL7zXG
OJHE5AqGZidx/Oyw/+TVLq3cHEi+6WfgJcwNzFeRAa7fAv+BKSJJ4T9dhOBYvmfs
YN/BfIhU8j4bQppVFtsduprdxooBx9bHWO/lFzCLl/cZOZ7RPOCya7iXcgEgWuA2
SAo96bcDeL3h5I/qM7fBLcm4Yvca219u8RoD7HqQNcmEI53CKS5qIW1cy0wkNbUy
Pqgovee2GpW7WkgqdG92E770/m2tcxdQQywVf5IeLHiSfJ0VP9dGFOoQCsnXZgvg
4GGstXzTJ2OEKMQ2QK1938Tne0S1WIG5o2zLEzOpHqw11Z9TsRg94CRm0/f/tfNt
ym35/N3qNdjERzozTQckbz4ZKCyLKJU3AIxGOH1U1caIjSNBbWY+nGAu62SzY9fb
IVdmKBkqL+c0MT4AW4yRUjFQ/EZYQNkWrh9USPAlgtWdIfjP4ERJ+60RJcRSgYvz
cJJw8DfDKYTNI6sgu0W++rhv89J4eAFdBKDmBazO5gLnFYBacgrFXW9HvwkxCcSZ
WJUlcuEalDpZrtPKGYO5arQp/vWWqXsVBzZeUphi6UbUjmCw+1M4emJh9Zk41jU3
BeTKcjh/hr0tihUvXhZKAJ85HmSkVLjPqZfY/DNiDecr9q+ZdvQ=
=i6V/
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 15:48:03 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 15:48:03 GMT) (full text, mbox, link).


Message #324 received at 844431@bugs.debian.org (full text, mbox, >> ... > > > > What is the point of getting "something" into policy, when it is known > > to not match existing practice and that what is being added to policy > > will be ignored by everyone? > > > >> The sentence I amended said "most environment variables" so our intent is clear. > >> ... > > > > This is not about "intent", this is about giving an exact definition > > of reproducibility for Debian. > > > > The definition should then match what is recorded in .buildinfo > > and what the reproducible builds infrastructure is testing. > > > > The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal? > > - a set of environment variable values; and > + a set of reserved environment variable values; and > > then later: > > + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > &In-Reply-To=<2f31d8a5-be35-1ebb-5304-8af8e9fdf422@debian.org>&References=<87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost> <6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org> <20170816150608.5waktm44l2pamdmt@localhost> <2f31d8a5-be35-1ebb-5304-8af8e9fdf422@debian.org>">reply):

From: Ximin Luo <infinity0@debian.org>
To: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 15:43:00 +0000
Adrian Bunk:
> On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote:
>> [..]
>>
>> Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time.
>> ...
> 
> What is the point of getting "something" into policy, when it is known 
> to not match existing practice and that what is being added to policy 
> will be ignored by everyone?
> 
>> The sentence I amended said "most environment variables" so our intent is clear.
>> ...
> 
> This is not about "intent", this is about giving an exact definition
> of reproducibility for Debian.
> 
> The definition should then match what is recorded in .buildinfo
> and what the reproducible builds infrastructure is testing.
> 

The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal?

- a set of environment variable values; and
+ a set of reserved environment variable values; and

then later:

+ A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:12:03 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:12:03 GMT) (full text, mbox, link).


Message #329 received at 844431@bugs.debian.org (full text, mbox, > >> ... > > > > > > What is the point of getting "something" into policy, when it is known > > > to not match existing practice and that what is being added to policy > > > will be ignored by everyone? > > > > > >> The sentence I amended said "most environment variables" so our intent is clear. > > >> ... > > > > > > This is not about "intent", this is about giving an exact definition > > > of reproducibility for Debian. > > > > > > The definition should then match what is recorded in .buildinfo > > > and what the reproducible builds infrastructure is testing. > > > > > > > The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal? > >... > > Will both dpkg-genbuildinfo and the reproducible builds infrastructure > implement this definition? > > Any definition is fine for me as long as it will match what is actually > being done.[1] > > > X > > cu > Adrian > > [1] not excluding future changes, but at the time the policy will be > published it should match reality > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > > > &subject=Re: Bug#844431: Revised patch: seeking seconds&References=<87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost> <6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org> <20170816150608.5waktm44l2pamdmt@localhost> <2f31d8a5-be35-1ebb-5304-8af8e9fdf422@debian.org> <20170816160908.opkstcrywsljo3qr@localhost>&In-Reply-To=<20170816160908.opkstcrywsljo3qr@localhost>">reply):

From: Adrian Bunk <bunk@debian.org>
To: Ximin Luo <infinity0@debian.org>
Cc: 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 19:09:08 +0300
On Wed, Aug 16, 2017 at 03:43:00PM +0000, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote:
> >> [..]
> >>
> >> Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time.
> >> ...
> > 
> > What is the point of getting "something" into policy, when it is known 
> > to not match existing practice and that what is being added to policy 
> > will be ignored by everyone?
> > 
> >> The sentence I amended said "most environment variables" so our intent is clear.
> >> ...
> > 
> > This is not about "intent", this is about giving an exact definition
> > of reproducibility for Debian.
> > 
> > The definition should then match what is recorded in .buildinfo
> > and what the reproducible builds infrastructure is testing.
> > 
> 
> The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal?
>...

Will both dpkg-genbuildinfo and the reproducible builds infrastructure 
implement this definition?

Any definition is fine for me as long as it will match what is actually 
being done.[1]

> X

cu
Adrian

[1] not excluding future changes, but at the time the policy will be 
    published it should match reality

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:33:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:33:03 GMT) (full text, mbox, link).


Message #334 received at 844431@bugs.debian.org (full text, mbox, > reproducible builds. > > > The definition does not match any past, present or future practice in > > Debian. > > > Including the people who want this change to policy, there seems to be > > noone intending to use this definition of reproducibility. > > > Adding this to policy would do more harm than good. > > Let me get the formal part of this out of the way first: > > As Policy Editor (a delegated position), based on my read of project > consensus including in-person verification of that consensus at DebConf > 17, I am formally declaring that I believe this change has consensus > despite your opposition. We will therefore include this change in the > next release of Policy. > > If you disagree, your choices of action are appealing to the Technical > Committee under section 6.1 of the Constitution (I'm fine with using that > section and letting the TC take a majority vote), or propose a GR under > section 4.1.3. > > Okay, now, why I'm taking that stance: > > This text is a formalization and simplification of existing practice that > we worked out in conjuction with the reproducible builds team and that > strikes a balance between attempting to enumerate all the causes of > nonreproducibility (which would be quite difficult to do) and providing > some clear guidance to maintainers about what types of output variance > they *don't* have to worry about (since obviously packages can't be > reproducible under all circumstances and in all environments). The > intention is to set a minimum bar that packages should be trying to meet, > and to lay the groundwork for future work. > > This is directly in the center of Policy's normal role of standardizing > and documenting best practice that has been developed elsewhere in the > project. The project is already comfortable with filing bugs against > packages for being non-reproducible under this criteria of > non-reproducibility, and we already have put significant work into > establishing a baseline and have a firm understanding of how close we're > currently coming to meeting that baseline. This meets the bar for > maturity of work that we look for in major Policy changes. As with many > other things in Debian, we hope to improve further later on, and to raise > the Policy bar over time as we develop better tools and better > understanding, but this bar is one that we can start recognizing with > normal-priority bugs right now. > > The bug severity was specifically chosen to not kick any packages out of > Debian and to not make reproducible builds mandatory, simply to recognize > them as bugs that we as a project want to see fixed. This feels like the > right balance to strike at this point. More work would be required to > make them RC. > > The definition is not decoupled from current practice. It is roughly &References=<87poc0zlv1.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <150257075653.20937.3462548876194624932@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87tw1ca4i2.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87fucwza84.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170816152603.gvyvthm6anechrhi@localhost> <87mv6zeaqo.fsf@hope.eyrie.org>&In-Reply-To=<87mv6zeaqo.fsf@hope.eyrie.org>">reply):

From: Russ Allbery <rra@debian.org>
To: Adrian Bunk <bunk@stusta.de>
Cc: Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 09:30:23 -0700
Adrian Bunk <bunk@stusta.de> writes:

> I hereby oppose the addition of this to policy.

> It is not true that this would be "Debian's precisification" of
> reproducible builds.

> The definition does not match any past, present or future practice in
> Debian.

> Including the people who want this change to policy, there seems to be 
> noone intending to use this definition of reproducibility.

> Adding this to policy would do more harm than good.

Let me get the formal part of this out of the way first:

As Policy Editor (a delegated position), based on my read of project
consensus including in-person verification of that consensus at DebConf
17, I am formally declaring that I believe this change has consensus
despite your opposition.  We will therefore include this change in the
next release of Policy.

If you disagree, your choices of action are appealing to the Technical
Committee under section 6.1 of the Constitution (I'm fine with using that
section and letting the TC take a majority vote), or propose a GR under
section 4.1.3.

Okay, now, why I'm taking that stance:

This text is a formalization and simplification of existing practice that
we worked out in conjuction with the reproducible builds team and that
strikes a balance between attempting to enumerate all the causes of
nonreproducibility (which would be quite difficult to do) and providing
some clear guidance to maintainers about what types of output variance
they *don't* have to worry about (since obviously packages can't be
reproducible under all circumstances and in all environments).  The
intention is to set a minimum bar that packages should be trying to meet,
and to lay the groundwork for future work.

This is directly in the center of Policy's normal role of standardizing
and documenting best practice that has been developed elsewhere in the
project.  The project is already comfortable with filing bugs against
packages for being non-reproducible under this criteria of
non-reproducibility, and we already have put significant work into
establishing a baseline and have a firm understanding of how close we're
currently coming to meeting that baseline.  This meets the bar for
maturity of work that we look for in major Policy changes.  As with many
other things in Debian, we hope to improve further later on, and to raise
the Policy bar over time as we develop better tools and better
understanding, but this bar is one that we can start recognizing with
normal-priority bugs right now.

The bug severity was specifically chosen to not kick any packages out of
Debian and to not make reproducible builds mandatory, simply to recognize
them as bugs that we as a project want to see fixed.  This feels like the
right balance to strike at this point.  More work would be required to
make them RC.

The definition is not decoupled from current practice.  It is roughly
equivalent to the information currently captured in *.buildinfo files
while being easily comprehensible to people who haven't studied
*.buildinfo files.  More precision will be possible in the future, but we
don't have to wait for that to set the simpler bar.

On the consensus side, there was a rare opportunity here to get a measure
of consensus from a large section of the project.  Holger specifically
asked for a show of hands and a show of objections (there were none) for
including this standard in Policy, and we had various discussions with
other people over the course of DebConf.  We have a much better read on
project consensus for this than we have for many other things in Debian.

Finally, Policy in no way constrains people from filing bugs or reporting
issues (via whatever means, such as tracker.debian.org) in packages about
things that are not spelled out in Policy.  This is a core principle of
Policy maintenance that we have held to for the more than a decade I've
been involed in Policy maintenance.  Policy is not an exhaustive list of
the possible bugs in packages, and never will be, and Policy will never
prevent people from filing bugs against packages at the severity that they
think is appropriate.  The definition of reproducibility is no exception
to this general rule.

Rather, the general project stance has been that Policy spells out the
things that are less open to debate, and bugs filed on the basis of things
that aren't in Policy are more at the maintainer's discretion (assuming
obvious common sense is applied).  And that's what I would expect for any
bugs filed about reproducible builds failing criteria more strict than
those stated in Policy (such as differing build paths) until such time as
project consensus builds that we want to hold all packages to that
stricter standard regardless of maintainer preference.

To be clear, the above discussion is intended as an explanation for this
decision, not a continuation of debate.  If you disagree with the above,
you should probably address those objections to the Technical Committee; I
feel like I have a pretty complete understanding of the issues here, and
it's highly unlikely that further elaborations or rephrasings of your
current arguments are going to change my mind.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:39:08 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:39:08 GMT) (full text, mbox, link).


Message #339 received at 844431@bugs.debian.org (full text, mbox, >>>> ... > >>> > >>> What is the point of getting "something" into policy, when it is known > >>> to not match existing practice and that what is being added to policy > >>> will be ignored by everyone? > >>> > >>>> The sentence I amended said "most environment variables" so our intent is clear. > >>>> ... > >>> > >>> This is not about "intent", this is about giving an exact definition > >>> of reproducibility for Debian. > >>> > >>> The definition should then match what is recorded in .buildinfo > >>> and what the reproducible builds infrastructure is testing. > >>> > >> > >> The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal? > >> ... > > > > Will both dpkg-genbuildinfo and the reproducible builds infrastructure > > implement this definition? > > > > Any definition is fine for me as long as it will match what is actually > > being done.[1] > > > > [1] not excluding future changes, but at the time the policy will be > > published it should match reality > > > > dpkg-genbuildinfo isn't about testing reproducibility, it's about recording the build environment: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Semantics > > "A buildinfo file is a record of what a particular builder did to build some binary output. > > It contains as much information about the build environment as is reasonable to distribute, and attempts to include all information needed to reproduce that build. > > It does NOT imply that everything contained within "should" be necessary to reproduce the build. [..]" > > AIUI, the tests.reproducible-builds.org infrastructure does already include what I suggested to be added. That is, it doesn't report "unreproducible" if varying those reserved variables, would change the binary hash. It could be a bit clearer in the UI on which suites vary the build-path however, that is an improvement to be made. For buster (where the build-path is not varied) then an "unreproducible" status would mean it's not meeting the definition (that includes my addition of these "reserved variables"). > > It is true that we might report "reproducible" even if the output varies based on the envvar UNIQUERANDOMENVVAR, because we don't explicitly vary that. But a lot of other QA-related tests in Debian would give "good" results even for "bad" packages that are bad in a very esoteric way. It's the intent that matters, and I think that's captured well in the policy, especially with my proposed newer wording, and also in the practical tests that we're already running. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > ">reply):

From: Ximin Luo <infinity0@debian.org>
To: Adrian Bunk <bunk@debian.org>
Cc: Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 16:34:00 +0000
Adrian Bunk:
> On Wed, Aug 16, 2017 at 03:43:00PM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote:
>>>> [..]
>>>>
>>>> Fair enough. I actually spotted that but thought it was better to get "something" into Policy rather than nitpick. I guess other people were thinking similar things. Well, lesson learnt, I will be more forceful next time.
>>>> ...
>>>
>>> What is the point of getting "something" into policy, when it is known 
>>> to not match existing practice and that what is being added to policy 
>>> will be ignored by everyone?
>>>
>>>> The sentence I amended said "most environment variables" so our intent is clear.
>>>> ...
>>>
>>> This is not about "intent", this is about giving an exact definition
>>> of reproducibility for Debian.
>>>
>>> The definition should then match what is recorded in .buildinfo
>>> and what the reproducible builds infrastructure is testing.
>>>
>>
>> The exact wording that was added, was a too-loose requirement. I'm now proposing to make the requirement more strict, in accordance with the tests that we're running. Do you have any comments on my proposal?
>> ...
> 
> Will both dpkg-genbuildinfo and the reproducible builds infrastructure 
> implement this definition?
> 
> Any definition is fine for me as long as it will match what is actually 
> being done.[1]
> 
> [1] not excluding future changes, but at the time the policy will be 
>     published it should match reality
> 

dpkg-genbuildinfo isn't about testing reproducibility, it's about recording the build environment: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Semantics

"A buildinfo file is a record of what a particular builder did to build some binary output.

It contains as much information about the build environment as is reasonable to distribute, and attempts to include all information needed to reproduce that build.

It does NOT imply that everything contained within "should" be necessary to reproduce the build. [..]"

AIUI, the tests.reproducible-builds.org infrastructure does already include what I suggested to be added. That is, it doesn't report "unreproducible" if varying those reserved variables, would change the binary hash. It could be a bit clearer in the UI on which suites vary the build-path however, that is an improvement to be made. For buster (where the build-path is not varied) then an "unreproducible" status would mean it's not meeting the definition (that includes my addition of these "reserved variables").

It is true that we might report "reproducible" even if the output varies based on the envvar UNIQUERANDOMENVVAR, because we don't explicitly vary that. But a lot of other QA-related tests in Debian would give "good" results even for "bad" packages that are bad in a very esoteric way. It's the intent that matters, and I think that's captured well in the policy, especially with my proposed newer wording, and also in the practical tests that we're already running.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:39:09 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:39:09 GMT) (full text, mbox, link).


Message #344 received at 844431@bugs.debian.org (full text, mbox, >> policy definition must not show up as non-reproducible in tracker/DDPO based > >> on results from the reproducible infrastructure") doesnt really makes sense: > >> if a package shows up as unreproducible somewhere, it's not reproducible > >> according to our definition! > > > > Again, reproducible means that it _can_ be reproduced. As long as a well-know > > process allows to reproduce the package, it is reproducible. > > > > What you define is a different concept that deserve a different name. > > > > Cheers, > > > > I think it is OK to call this "reproducible", it's a natural language word and these are always dependent on some context. Technically, everything is reproducible if you know the state of the machine when the original build was started. Some other projects give you a VM and tell you to build in the VM. That would be a "well-known process". But nobody really knows what's in the VM so it's not helpful for security. Having a strict definition of reproducibility, helps us be more convinced that the build process is really only dependent on the source code and build tools, and a very restricted set of other inputs. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > &subject=Re: Bug#844431: Revised patch: seeking seconds">reply):

From: Ximin Luo <infinity0@debian.org>
To: Bill Allombert <ballombe@debian.org>, Holger Levsen <holger@layer-acht.org>, 844431@bugs.debian.org
Cc: Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 16:34:00 +0000
Bill Allombert:
> On Tue, Aug 15, 2017 at 07:49:55PM +0000, 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:
>> if a package shows up as unreproducible somewhere, it's not reproducible
>> according to our definition!
> 
> Again, reproducible means that it _can_ be reproduced. As long as a well-know
> process allows to reproduce the package, it is reproducible.
> 
> What you define is a different concept that deserve a different name.
> 
> Cheers,
> 

I think it is OK to call this "reproducible", it's a natural language word and these are always dependent on some context. Technically, everything is reproducible if you know the state of the machine when the original build was started. Some other projects give you a VM and tell you to build in the VM. That would be a "well-known process". But nobody really knows what's in the VM so it's not helpful for security. Having a strict definition of reproducibility, helps us be more convinced that the build process is really only dependent on the source code and build tools, and a very restricted set of other inputs.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:39:11 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:39:11 GMT) (full text, mbox, link).


Message #349 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 09:36:04 -0700
Bill Allombert <ballombe@debian.org> writes:

> I am still concerned that there will be no reliable way for maintainers
> to check whether a package is reproducible according to policy before
> uploading it to the archive.

Ximin answered this, but I also wanted to note that while having such a
tool would be ideal, we don't have such tools for every aspect of Policy,
and I'm generally comfortable with that.  There are a lot of elements in
building a distribution where we can't proactively test exhaustively and
maintainers have to be reactive.  Obviously, full testing in advance is
best, but we can live with some reactive bug fixing.

There is an infrastructure that will test your package for reproducibility
after upload and let you know if that fails, which is better than some
other aspects of Policy.

Note that, for most developers, this is pretty much equivalent to the
current situation with FTBFS on, say, s390 architectures.  Or even issues
with running under whichever init system is not the one the maintainer
personally uses.  Maintainers generally do not proactively test such
things; they follow best practices, use standard tools, and then
reactively respond to bugs filed or by failures detected by other parts of
the infrastructure when those tools fail for some reason.  And generally
that's fine; lots of proactive testing for the maintainer would often be a
waste of their time.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 16:45:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 16:45:03 GMT) (full text, mbox, link).


Message #354 received at 844431@bugs.debian.org (full text, mbox, > thinking similar things. Well, lesson learnt, I will be more forceful > > next time. > > > The sentence I amended said "most environment variables" so our intent > > is clear. If we want to fix this now, I would suggest amending: > > > - a set of environment variable values; and > > + a set of reserved environment variable values; and > > > then later: > > > + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH. > > We intentionally didn't spell this out in this much detail because it felt > better to defer this (stricter) bar until we have documentation of the > *.buildinfo file, and also because we were worried about the list changing > (once it goes into Policy, it's more irritating to change). The current > standard in Policy is intentionally weaker than this in order to be > simpler. > > I still lean towards taking this approach, because I'm pretty worried > about the scope of: > > other variables explicitly used by buildsystems to affect build output > > That's not really an enumerable list. My recommendation, if you want to > allow some environment variables to vary without affecting > reproducibility, is to explicitly list the set of environment variables > that can vary, rather than trying to list the ones that have to remain > fixed. > > But, more fundamentally, I'm dubious that weakening the environment > variable set is a good use of anyone's time. Why not define reproducible > builds as setting a specific set of environment variables and no others? > We're long past the point where building packages in an isolated > environment with a fixed set of environment variables is a great hardship > or even particularly unusual. I think the effort would be better spent on > fixing (with enumerated exceptions) the set of environment variables set > by buildds, sbuild, pbuilder, and other infrastructure that builds > packages than in making packages tolerate random environment variables > being set during the build. It's really hard to track down all the > environment variable settings that might affect Autoconf, the build tools, > document formatters, and so forth. > > -- > Russ Allbery (rra@debian.org) > > &References=<87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org> <87a82zea4n.fsf@hope.eyrie.org>&In-Reply-To=<87a82zea4n.fsf@hope.eyrie.org>">reply):

From: Russ Allbery <rra@debian.org>
To: Ximin Luo <infinity0@debian.org>
Cc: Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 09:43:36 -0700
Ximin Luo <infinity0@debian.org> writes:

> Fair enough. I actually spotted that but thought it was better to get
> "something" into Policy rather than nitpick. I guess other people were
> thinking similar things. Well, lesson learnt, I will be more forceful
> next time.

> The sentence I amended said "most environment variables" so our intent
> is clear. If we want to fix this now, I would suggest amending:

> - a set of environment variable values; and
> + a set of reserved environment variable values; and

> then later:

> + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH.

We intentionally didn't spell this out in this much detail because it felt
better to defer this (stricter) bar until we have documentation of the
*.buildinfo file, and also because we were worried about the list changing
(once it goes into Policy, it's more irritating to change).  The current
standard in Policy is intentionally weaker than this in order to be
simpler.

I still lean towards taking this approach, because I'm pretty worried
about the scope of:

    other variables explicitly used by buildsystems to affect build output

That's not really an enumerable list.  My recommendation, if you want to
allow some environment variables to vary without affecting
reproducibility, is to explicitly list the set of environment variables
that can vary, rather than trying to list the ones that have to remain
fixed.

But, more fundamentally, I'm dubious that weakening the environment
variable set is a good use of anyone's time.  Why not define reproducible
builds as setting a specific set of environment variables and no others?
We're long past the point where building packages in an isolated
environment with a fixed set of environment variables is a great hardship
or even particularly unusual.  I think the effort would be better spent on
fixing (with enumerated exceptions) the set of environment variables set
by buildds, sbuild, pbuilder, and other infrastructure that builds
packages than in making packages tolerate random environment variables
being set during the build.  It's really hard to track down all the
environment variable settings that might affect Autoconf, the build tools,
document formatters, and so forth.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 17:51:05 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 17:51:05 GMT) (full text, mbox, link).


Message #359 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <ballombe@debian.org>, 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 19:46:58 +0200
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 running under whichever init system is not the one the maintainer
> personally uses.

Debian provides porter box for that purpose. This means if your package
FTBFS on s390 you can login to a s390 porter box, use sbuild to set up a
build environment, fix the problem and then check the package now build
correctly.

Now compare with reproducible build. You get some error report you
cannot reproduce, do some change following the help provided and
hope for the best. Then some day later you get the same error
report.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 17:57:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 17:57:02 GMT) (full text, mbox, link).


Message #364 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 10:54:56 -0700
Bill Allombert <ballombe@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 running under whichever init system is not the one the
>> maintainer personally uses.

> Debian provides porter box for that purpose. This means if your package
> FTBFS on s390 you can login to a s390 porter box, use sbuild to set up a
> build environment, fix the problem and then check the package now build
> correctly.

> Now compare with reproducible build. You get some error report you
> cannot reproduce, do some change following the help provided and hope
> for the best. Then some day later you get the same error report.

This hasn't been my experience with reproducible build bug reports.  Once
there's a bug report of unreproducibility under some specific situation,
I've always been able to reproduce it by doing multiple builds with that
specific variation and seeing how the output changes.

I agree that this may not always be the case, but it's also not always the
case that one can reproduce an s390 buildd failure on a porter box.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 18:21:04 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 18:21:04 GMT) (full text, mbox, link).


Message #369 received at 844431@bugs.debian.org (full text, mbox, >> thinking similar things. Well, lesson learnt, I will be more forceful > >> next time. > > > >> The sentence I amended said "most environment variables" so our intent > >> is clear. If we want to fix this now, I would suggest amending: > > > >> - a set of environment variable values; and > >> + a set of reserved environment variable values; and > > > >> then later: > > > >> + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH. > > > > We intentionally didn't spell this out in this much detail because it felt > > better to defer this (stricter) bar until we have documentation of the > > *.buildinfo file, and also because we were worried about the list changing > > (once it goes into Policy, it's more irritating to change). The current > > standard in Policy is intentionally weaker than this in order to be > > simpler. > > > > I still lean towards taking this approach, because I'm pretty worried > > about the scope of: > > > > other variables explicitly used by buildsystems to affect build output > > > > That's not really an enumerable list. My recommendation, if you want to > > allow some environment variables to vary without affecting > > reproducibility, is to explicitly list the set of environment variables > > that can vary, rather than trying to list the ones that have to remain > > fixed. > > > > Intuitively it feels weird to say "if you vary USER, the output must remain fixed", but also "if you vary RANDOMUNIQUESPECIALSNOWFLAKEVARIABLE then the output is allowed to change". > > Certain environment variables have become convention to affect a build, like CFLAGS, and even debuild(1) doesn't clear them - but clears the other envvars. That is what I was going on. > > > But, more fundamentally, I'm dubious that weakening the environment > > variable set is a good use of anyone's time. Why not define reproducible > > builds as setting a specific set of environment variables and no others? > > We're long past the point where building packages in an isolated > > environment with a fixed set of environment variables is a great hardship > > or even particularly unusual. I think the effort would be better spent on > > fixing (with enumerated exceptions) the set of environment variables set > > by buildds, sbuild, pbuilder, and other infrastructure that builds > > packages than in making packages tolerate random environment variables > > being set during the build. It's really hard to track down all the > > environment variable settings that might affect Autoconf, the build tools, > > document formatters, and so forth. > > > > My proposal was the opposite, to *strengthen* the definition that was already accepted - I *don't* think we should track down all those variables and make packages immune to them, that is why I added "other variables explicitly used by buildsystems to affect build output" etc. OTOH, some other variables are used by non-build tools, such as LC_*, USER, etc. Since they affect non-build programs, they possibly may be set in a developer's normal environment, so just running "debian/rules build" will pick these up. Then, the build should stay the same despite these other variables. > > If a build tool needs to be run in a specific locale, it should either use a locale-independent sorting program, or set LC_ALL explicitly itself regardless of what the parent environment says. > > This doesn't contradict us from using a fixed or mostly-clean environment in sbuild, pbuilder, debuild, etc. &subject=Re: Bug#844431: Revised patch: seeking seconds&In-Reply-To=&References=<87poc0zlv1.fsf@iris.silentflame.com> <20170815175401.awfox72lfpt5k5p7@localhost> <87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <87inho7gan.fsf@hope.eyrie.org> <20170815210137.r6mwcrrhfndjvbnt@localhost> <20170816112108.2vs35dijuhsce5eo@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <6385a1a3-c071-59ab-f619-14b419b30a3a@debian.org> <87a82zea4n.fsf@hope.eyrie.org> ">reply):

From: Ximin Luo <infinity0@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Adrian Bunk <bunk@debian.org>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 18:17:00 +0000
Russ Allbery:
> Ximin Luo <infinity0@debian.org> writes:
> 
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar things. Well, lesson learnt, I will be more forceful
>> next time.
> 
>> The sentence I amended said "most environment variables" so our intent
>> is clear. If we want to fix this now, I would suggest amending:
> 
>> - a set of environment variable values; and
>> + a set of reserved environment variable values; and
> 
>> then later:
> 
>> + A "reserved" environment variable is defined as DEB_*, DPKG_, SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by dpkg-buildflags and other variables explicitly used by buildsystems to affect build output, excluding any variables used by non-build programs to affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, PATH and likely any variables ending with *PATH.
> 
> We intentionally didn't spell this out in this much detail because it felt
> better to defer this (stricter) bar until we have documentation of the
> *.buildinfo file, and also because we were worried about the list changing
> (once it goes into Policy, it's more irritating to change).  The current
> standard in Policy is intentionally weaker than this in order to be
> simpler.
> 
> I still lean towards taking this approach, because I'm pretty worried
> about the scope of:
> 
>     other variables explicitly used by buildsystems to affect build output
> 
> That's not really an enumerable list.  My recommendation, if you want to
> allow some environment variables to vary without affecting
> reproducibility, is to explicitly list the set of environment variables
> that can vary, rather than trying to list the ones that have to remain
> fixed.
> 

Intuitively it feels weird to say "if you vary USER, the output must remain fixed", but also "if you vary RANDOMUNIQUESPECIALSNOWFLAKEVARIABLE then the output is allowed to change".

Certain environment variables have become convention to affect a build, like CFLAGS, and even debuild(1) doesn't clear them - but clears the other envvars. That is what I was going on.

> But, more fundamentally, I'm dubious that weakening the environment
> variable set is a good use of anyone's time.  Why not define reproducible
> builds as setting a specific set of environment variables and no others?
> We're long past the point where building packages in an isolated
> environment with a fixed set of environment variables is a great hardship
> or even particularly unusual.  I think the effort would be better spent on
> fixing (with enumerated exceptions) the set of environment variables set
> by buildds, sbuild, pbuilder, and other infrastructure that builds
> packages than in making packages tolerate random environment variables
> being set during the build.  It's really hard to track down all the
> environment variable settings that might affect Autoconf, the build tools,
> document formatters, and so forth.
> 

My proposal was the opposite, to *strengthen* the definition that was already accepted - I *don't* think we should track down all those variables and make packages immune to them, that is why I added "other variables explicitly used by buildsystems to affect build output" etc. OTOH, some other variables are used by non-build tools, such as LC_*, USER, etc. Since they affect non-build programs, they possibly may be set in a developer's normal environment, so just running "debian/rules build" will pick these up. Then, the build should stay the same despite these other variables.

If a build tool needs to be run in a specific locale, it should either use a locale-independent sorting program, or set LC_ALL explicitly itself regardless of what the parent environment says.

This doesn't contradict us from using a fixed or mostly-clean environment in sbuild, pbuilder, debuild, etc.

Now that I think about it however, it's probably not reasonable to expect that the output remains the same when PATH is changed. On tests.r-b.org we vary it by appending a dummy value [1] but if the user adds their own stuff to the beginning then the output may well change. There is probably no point in trying to prevent that in all packages. In a sense, it does very much affect what build tools are run, even though non-build programs also use it. However, my gut feeling still says that it's not right for the locale (LC_*) to affect a build process. I will try to think of a more precise way to express this difference.

X

[1] https://tests.reproducible-builds.org/debian/index_variations.html

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 18:27:02 GMT) (full text, mbox, link).


Acknowledgement sent to Adrian Bunk <bunk@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 18:27:02 GMT) (full text, mbox, link).


Message #374 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>
To: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 21:24:55 +0300
On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
>...
> This text is a formalization and simplification of existing practice that
> we worked out in conjuction with the reproducible builds team and that
> strikes a balance between attempting to enumerate all the causes of
> nonreproducibility (which would be quite difficult to do) and providing
> some clear guidance to maintainers about what types of output variance
> they *don't* have to worry about (since obviously packages can't be
> reproducible under all circumstances and in all environments).  The
> intention is to set a minimum bar that packages should be trying to meet,
>...

The definition of reproducibility in policy does not match any past, 
present or future practice in Debian.

And no current or currently planned reproducible testing does test
or is intended to test whether packages meet this minimum bar.

> This is directly in the center of Policy's normal role of standardizing
> and documenting best practice that has been developed elsewhere in the
> project.
>...

If it would actually standardize what is considered reproducible
in Debian everything would be fine.

> The definition is not decoupled from current practice.  It is roughly
> equivalent to the information currently captured in *.buildinfo files
> while being easily comprehensible to people who haven't studied
> *.buildinfo files.
>...

2 of the 5 items in policy require changes to .buildinfo, and for a 
third I cannot easily comprehend whether it would require changes to 
.buildinfo since it is unclear what it is supposed to mean:

- a set of environment variable values;

.buildinfo currently records only some environment variables.
If all or different ones are allowed to vary that is a change.
I am actually surprised that the latest set of suggested permitted
variations does not seem to be based on the existing list currently
used for .buildinfo

- a version of a source package unpacked at a given path;

The path is currently not in .buildinfo

- a build architecture;

What is the intended purpose of this, especially what is this supposed 
to output for i386 builds on amd64 kernel?
.buildinfo currently follows dpkg-architecture, and outputs i386.
i386/amd64 kernels is a build variation in the reproducible builds
infrastructure that does result in packages being built differently,
which makes it unclear whether this difference was supposed to be
addressed here.

> Finally, Policy in no way constrains people from filing bugs or reporting
> issues (via whatever means, such as tracker.debian.org) in packages about
> things that are not spelled out in Policy.
>...

https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

This statement in tracker is automatically generated based on results 
from the reproducible builds infrastructure.

Is it acceptable to claim in tracker that a package is not reproducible, 
when that package might actually be reproducible based on the definition 
of reproducibility spelled out in Policy? [1]

cu
Adrian

[1] as explained earlier, it is not obvious whether or not this
    specific package is reproducible according to Policy

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 18:36:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 18:36:03 GMT) (full text, mbox, link).


Message #379 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Adrian Bunk <bunk@debian.org>
Cc: 844431@bugs.debian.org, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 11:33:32 -0700
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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 18:45:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 18:45:03 GMT) (full text, mbox, link).


Message #384 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org
Cc: Adrian Bunk <bunk@stusta.de>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 20:40:35 +0200
On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
> As Policy Editor (a delegated position), based on my read of project
> consensus including in-person verification of that consensus at DebConf
> 17, I am formally declaring that I believe this change has consensus
> despite your opposition.  We will therefore include this change in the
> next release of Policy.

This is one of the reasons I do not attend DebConf anymore. We are an
online organization. Consultation should happen online. Metting are nice
but they should not be used to vet consensus and ignore absentees.

So I object to Adrian being overriden on that ground.

Now it seems to me this policy proposal is a way to acknowledge the
great work of the reproducible build project. As such it is probably
fine and they amply deserve praise and acknowledgement.

But as a technical document, it is lacking practical recommendation for
maintainers how to make sure their package build reproducibly and create
confusion on the goal by using the term 'reproducible build' when 
'robust build' is meant (which is a worthwile goal by itself, but a
different project nevertheless). 

So I am concerned we are putting the cart before the horse.

Cheers,
Another Policy Editor (a delegated position).
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 19:18:03 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 19:18:03 GMT) (full text, mbox, link).


Message #389 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org, Adrian Bunk <bunk@stusta.de>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 12:14:53 -0700
Bill Allombert <ballombe@debian.org> writes:

> This is one of the reasons I do not attend DebConf anymore. We are an
> online organization. Consultation should happen online. Metting are nice
> but they should not be used to vet consensus and ignore absentees.

> So I object to Adrian being overriden on that ground.

That's only a part of what went into this, but I will strongly defend
using the opportunity of in-person meetings to judge consensus.  It's very
difficult to judge consensus over email because only the strong opinions
are visible.  There are frequently situations where there's a large
sentiment in one direction or another that isn't expressed in long threads
full of lots of back and forth between a small handful of people who may
or may not have representative opinions.

We can't always do it, and we obviously have to be sensitive to the fact
that not everyone is in the room, but we're also going for consensus, not
unanimity.  When we have the opportunity to get direction from a large
gathering of developers, we should make use of it.

But I'm taking this position for a large number of reasons, of which
consensus at DebConf is only one.

> But as a technical document, it is lacking practical recommendation for
> maintainers how to make sure their package build reproducibly and create
> confusion on the goal by using the term 'reproducible build' when
> 'robust build' is meant (which is a worthwile goal by itself, but a
> different project nevertheless).

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
project (and which has gotten us to 94% reproducible already), please make
them.  I am not at all trying to rule out constructive suggestions to make
the language better, either now or in subsequent revisions of Policy.  I
think what we've got is pretty good, and I am comfortable with putting it
into Policy now, but concrete wording proposals with justification would
be welcome.  Like everything else in Policy, we can always improve how we
describe our project-wide baseline.

It's not normally Policy's role to offer detailed advice on how to meet a
particular requirement.  For example, Policy mentions debhelper in a few
footnotes but doesn't document how to use it to create compliant packages
in general.  That's not its purpose; usually that sort of documentation
can be better-maintained by other teams, such as the reproducible builds
team.

The definition in the current proposal is intentionally weaker (in the
sense that fewer packages would fail it) than what current reproducible
build testing is doing in a few places (such as with environment
variables) because it takes a conservative stance to set a baseline and it
errs on the side of a clear and simple problem statement.  It's possible
that we'll want to make it more complex in the future, but I think with
environment variables we should first have a discussion (Ximin and I
started that; I probably should move it off this thread) because I'm not
sure that's the best approach.  In the meantime, this achieves the goal of
declaring a baseline that Debian packages should be reproducible under
controlled and simple-to-state circumstances, which is something for which
I'm quite sure we have general project consensus.

If you believe it is premature to specify this in Policy entirely, I
strongly disagree, and am not persuadable on that point.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 19:33:03 GMT) (full text, mbox, link).


Acknowledgement sent to Don Armstrong <don@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 19:33:03 GMT) (full text, mbox, link).


Message #394 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Don Armstrong <don@debian.org>
To: 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 12:19:47 -0700
On Wed, 16 Aug 2017, Bill Allombert wrote:
> But as a technical document, it is lacking practical recommendation
> for maintainers how to make sure their package build reproducibly

The practical recommendations for maintainers are encoded separately, as
they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
for example.

> and create confusion on the goal by using the term 'reproducible
> build' when 'robust build' is meant (which is a worthwile goal by
> itself, but a different project nevertheless).

I'm not convinced that this change will reduce confusion, as the
reproducible build project has been using this language in Debian for
many years now.

But I could be wrong. Please propose an alternative patch to policy
which addresses your concerns if you feel strongly about it.

-- 
Don Armstrong                      https://www.donarmstrong.com

Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
    http://www.asofterworld.com/index.php?id=481



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 21:45:03 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 21:45:03 GMT) (full text, mbox, link).


Message #399 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: Bill Allombert <ballombe@debian.org>, 844431@bugs.debian.org, Adrian Bunk <bunk@stusta.de>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 23:42:32 +0200
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
> project (and which has gotten us to 94% reproducible already), please make
> them.

This percentage was reached mostly by fixing software tools (compiler, 
doc generators, packaging tools) to be deterministic, rather than by
fixing individual packages. This is a topic that is wholy absent from
policy.

For example policy could mandate that programs that set timestamps honour
SOURCE_DATE_EPOCH.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 21:57:02 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 21:57:02 GMT) (full text, mbox, link).


Message #404 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Don Armstrong <don@debian.org>, 844431@bugs.debian.org
Cc: reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 23:52:04 +0200
On Wed, Aug 16, 2017 at 12:19:47PM -0700, Don Armstrong wrote:
> On Wed, 16 Aug 2017, Bill Allombert wrote:
> > But as a technical document, it is lacking practical recommendation
> > for maintainers how to make sure their package build reproducibly
> 
> The practical recommendations for maintainers are encoded separately, as
> they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
> for example.

> > and create confusion on the goal by using the term 'reproducible
> > build' when 'robust build' is meant (which is a worthwile goal by
> > itself, but a different project nevertheless).
> 
> I'm not convinced that this change will reduce confusion, as the
> reproducible build project has been using this language in Debian for
> many years now.

It is apparent that the reproducible build project has broadened their
focus following the progress they made, which is logical.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Wed, 16 Aug 2017 22:09:02 GMT) (full text, mbox, link).


Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Wed, 16 Aug 2017 22:09:03 GMT) (full text, mbox, link).


Message #409 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: 844431@bugs.debian.org, Adrian Bunk <bunk@stusta.de>, Sean Whitton <spwhitton@spwhitton.name>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Wed, 16 Aug 2017 15:05:32 -0700
Bill Allombert <ballombe@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 project (and which has gotten us to 94% reproducible already),
>> please make them.

> This percentage was reached mostly by fixing software tools (compiler,
> doc generators, packaging tools) to be deterministic, rather than by
> fixing individual packages. This is a topic that is wholy absent from
> policy.

Indeed.  There are many things that go into making Debian work that are
wholly absent from Policy.  Hopefully, over time, we can slowly reduce
that, but there will always be new initiatives that aren't documented.

> For example policy could mandate that programs that set timestamps
> honour SOURCE_DATE_EPOCH.

Please propose language.  (Ideally in a separate bug, since this one is
already quite large and it's easier to address specific issues in specific
bugs.)

I'm not opposed to adding more advice and requirements that make sense,
but there are lots of things in Policy that aren't as fully described as
they possibly could be if people did more work.  I'm not willing to block
this on having the perfect language, but if you want to contribute, you're
absolutely welcome to do so.

Most packages do not have to care about SOURCE_DATE_EPOCH because it's set
by dpkg-buildpackage and consumed by the tools that are most frequently
relevant, but I'd be very happy to see that documented in Policy for the
packages that do care.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Thu, 17 Aug 2017 00:42:09 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Thu, 17 Aug 2017 00:42:09 GMT) (full text, mbox, link).


Message #414 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>
To: Bill Allombert <ballombe@debian.org>, Russ Allbery <rra@debian.org>
Cc: 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Wed, 16 Aug 2017 17:40:23 -0700
Hi Bill,

> Now compare with reproducible build. You get some error report you
> cannot reproduce, do some change following the help provided and
> hope for the best. Then some day later you get the same error
> report.

I'd dearly love to know when/where this occurred if you can provide a
reference.

This is not our, and certainly not my own, intention when filing
reproducibility-related bugs, which always include a well-intentioned
patch.


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Thu, 17 Aug 2017 18:51:03 GMT) (full text, mbox, link).


Acknowledgement sent to Edroman <edroman@protonmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Thu, 17 Aug 2017 18:51:03 GMT) (full text, mbox, link).


Message #419 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Edroman <edroman@protonmail.com>
To: "844431@bugs.debian.org" <844431@bugs.debian.org>
Subject: Packages should be reproducible
Date: Thu, 17 Aug 2017 14:38:38 -0400
[Message part 1 (text/plain, inline)]
Regarding to reproducible, I would suggest Debian should consider integrating Nix[0] into Debian; as Nix's website mentions

Nix builds packages in isolation from each other. This ensures that they are reproducible and don’t have undeclared dependencies, so if a package works on one machine, it will also work on another.

[0]. https://nixos.org/nix/
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Thu, 17 Aug 2017 20:06:05 GMT) (full text, mbox, link).


Acknowledgement sent to Georg Faerber <georg@lokaler.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Thu, 17 Aug 2017 20:06:05 GMT) (full text, mbox, link).


Message #424 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Georg Faerber <georg@lokaler.de>
To: Edroman <edroman@protonmail.com>, 844431@bugs.debian.org
Subject: Re: Bug#844431: Packages should be reproducible
Date: Thu, 17 Aug 2017 21:53:23 +0200
[Message part 1 (text/plain, inline)]
On 17-08-17 14:38:38, Edroman wrote:
> Regarding to reproducible, I would suggest Debian should consider
> integrating Nix[0] into Debian; as Nix's website mentions
> 
> Nix builds packages in isolation from each other. This ensures that
> they are reproducible and don’t have undeclared dependencies, so if a
> package works on one machine, it will also work on another.

I doubt that building packages in isolation from each other makes
them reproducible, especially in the context which is discussed in this
bug.

Cheers,
Georg
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Fri, 18 Aug 2017 04:15:03 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Fri, 18 Aug 2017 04:15:03 GMT) (full text, mbox, link).


Message #429 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>
To: 844431@bugs.debian.org
Subject: Re: debian-policy: Packages should be reproducible
Date: Thu, 17 Aug 2017 21:12:12 -0700
Hi Edroman,

> Regarding to reproducible, I would suggest Debian should consider
> integrating Nix into Debian

Curiously, I had a brief foray into packaging the Nix tools for Debian:

  https://github.com/lamby/pkg-nix

> Nix builds packages in isolation from each other. This ensures that
> they are reproducible

(As Georg writes, we are using different usages of reproducible.)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Fri, 18 Aug 2017 11:45:03 GMT) (full text, mbox, link).


Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Fri, 18 Aug 2017 11:45:03 GMT) (full text, mbox, link).


Message #434 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>
To: 844431@bugs.debian.org
Subject: Re: Bug#844431: debian-policy: Packages should be reproducible
Date: Fri, 18 Aug 2017 11:41:44 +0000
[Message part 1 (text/plain, inline)]
On Thu, Aug 17, 2017 at 09:12:12PM -0700, Chris Lamb wrote:
> > Nix builds packages in isolation from each other. This ensures that
> > they are reproducible
> (As Georg writes, we are using different usages of reproducible.)

…though NixOS is also working on creating bit by bit reproducibly packages…


-- 
cheers,
	Holger
[signature.asc (application/pgp-signature, inline)]

Removed tag(s) pending. Request was from Sean Whitton <spwhitton@spwhitton.name> to control@bugs.debian.org. (Sun, 20 Aug 2017 18:12:26 GMT) (full text, mbox, link).


Removed tag(s) patch. Request was from Sean Whitton <spwhitton@spwhitton.name> to control@bugs.debian.org. (Sun, 20 Aug 2017 18:12:28 GMT) (full text, mbox, link).


Added tag(s) pending. Request was from Sean Whitton <spwhitton@spwhitton.name> to control@bugs.debian.org. (Sun, 20 Aug 2017 18:12:28 GMT) (full text, mbox, link).


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Sun, 20 Aug 2017 19:27:05 GMT) (full text, mbox, link).


Acknowledgement sent to Bill Allombert <ballombe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Sun, 20 Aug 2017 19:27:05 GMT) (full text, mbox, link).


Message #445 received at 844431@bugs.debian.org (full text, mbox, reply):

From: Bill Allombert <ballombe@debian.org>
To: Chris Lamb <lamby@debian.org>
Cc: Bill Allombert <ballombe@debian.org>, Russ Allbery <rra@debian.org>, 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sun, 20 Aug 2017 21:22:26 +0200
On Wed, Aug 16, 2017 at 05:40:23PM -0700, Chris Lamb wrote:
> Hi Bill,
> 
> > Now compare with reproducible build. You get some error report you
> > cannot reproduce, do some change following the help provided and
> > hope for the best. Then some day later you get the same error
> > report.
> 
> I'd dearly love to know when/where this occurred if you can provide a
> reference.

This happens for errors listed on the reproducible-build.org website.
I do not speak about bug report here.

> This is not our, and certainly not my own, intention when filing
> reproducibility-related bugs, which always include a well-intentioned
> patch.

I know from experience you and the reproducible-build team report
excellent bug report with good patches. That is not the issue but you do
not need policy to continue doing that.

However, are not maintainers expected to make their packages
policy-compliant without waiting for bug report ?
Are not maintainers supposed to be proactive and try to fix
issues that they became aware without waiting for someone to fill a bug ?
Are not users allowed to fill bugs when packages does not seem to comply
with documented expectation ?

As I said, if this policy is only meant to be a vehicule for the
reproducible-build team, then it is fine by me. However if it means
for general audience, then it is premature.
It would be best to focus first on requiring all generators to be
deterministic. One this step is reached (we are already close thanks to
the reproducible-build team work), it will much easier for maintainers
to deal wih reproducibility issues because they will not need
work-around.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Mon, 21 Aug 2017 00:36:03 GMT) (full text, mbox, link).


Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Mon, 21 Aug 2017 00:36:03 GMT) (full text, mbox, link).


Message #450 received at 844431@bugs.debian.org (full text, mbox, phrasings to mean some active, human-driven notification and interaction > such as a bug report or private mail, rather than something cold and > automated from a not — yet! — perfect CI framework. > > Thank you for clarifying, but please do also bear with us whilst we > improve the reliability of the jenkins.debian.org results. > > > Best wishes, > > -- > ,''`. > : :' : Chris Lamb > `. `'` lamby@debian.org / chris-lamb.co.uk > `- > > &References=<87r2wc7jkd.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815190930.wcfpxwxtadv6guer@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87inho7gan.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170815213311.GC7385@yellowpig> <87fucreah7.fsf@hope.eyrie.org> <20170816174658.GC31273@yellowpig> <1502930423.4041480.1075889768.462F7DA0@webmail.messagingengine.com> <20170820192226.GA9543@yellowpig> <1503275725.2696918.1079470496.0B124748@webmail.messagingengine.com>&In-Reply-To=<1503275725.2696918.1079470496.0B124748@webmail.messagingengine.com>">reply):

From: Chris Lamb <lamby@debian.org>
To: Bill Allombert <ballombe@debian.org>
Cc: Russ Allbery <rra@debian.org>, 844431@bugs.debian.org, Adrian Bunk <bunk@debian.org>, reproducible-builds@lists.alioth.debian.org
Subject: Re: Bug#844431: Revised patch: seeking seconds
Date: Sun, 20 Aug 2017 17:35:25 -0700
Bill,

> > > Now compare with reproducible build. You get some error report you
> > > cannot reproduce, do some change following the help provided and
> > > hope for the best. Then some day later you get the same error
> > > report.
> > 
> > I'd dearly love to know when/where this occurred if you can provide a
> > reference.
> 
> This happens for errors listed on the reproducible-build.org website.
> I do not speak about bug report here.

Oh, I see. I was interpreting your "same error report" and similar
phrasings to mean some active, human-driven notification and interaction
such as a bug report or private mail, rather than something cold and
automated from a not — yet! — perfect CI framework.

Thank you for clarifying, but please do also bear with us whilst we
improve the reliability of the jenkins.debian.org results.


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>:
Bug#844431; Package debian-policy. (Mon, 21 Aug 2017 14:27:08 GMT) (full text, mbox, link).


Acknowledgement sent to Ximin Luo <infinity0@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, Sean Whitton <spwhitton@spwhitton.name>. (Mon, 21 Aug 2017 14:27:08 GMT) (full text, mbox, link).


Message #455 received at 844431@bugs.debian.org (full text, mbox, > Debian is primarily an online organisation as Bill says, these are its roots, this is how it became so big, and this is where the vast majority of productive work is done. I think discrediting all of that simply because "some people are loud on mailing lists" is really short-sighted and distorted. These cases are few, and not representative. I myself have contributed to a few of these cases, but again it's not representative of the vast majority of work that I do. I don't feel it's right for people to be judging online discussion methods, by focusing on a few negative cases and ignoring all the positive aspects. > > Personally, and I'm sure many people are similar, I prefer to have long technical discussions like this in writing via email, and not face-to-face. I'm a very slow thinker, I don't make very good decisions in the fast-paced context of a normal physical conversation. If I sometimes seem like I do, it's usually only because I've thought about the problem beforehand and have my main points decided. > > Physical discussions encourage non-technical interactions - if you can pick the right words and presentation, you can make a crowd empathise with you for largely non-technical reasons. I don't think this is a good thing, we should recognise that this happens and not allow it to take over Debian's decision making processes. Online technical discussions are safer against these sorts of effects. People with long technical points to make, don't feel put off by the presence of a large non-technical crowd - and here I include "technical people" that have not properly thought about the topic or have no stake in the discussion. I truly think these latter opinions should be given less weight than a properly reasoned and well-thought-out opinion. > > These sorts of points, which are vital to a healthy discussion, are easier to make in writing. You have an adequate amount of time to think, and you don't get interrupted by people who get bored by your thinking time and move the conversation on elsewhere before you have a chance to properly respond. Indeed in this thread there were lots of good points brought up criticising the wording of this policy, that nobody thought about during physical discussions at DebConf (which I didn't participate in for these reasons). > > TL;DR: Debian is primarily an online organisation and that is its strength; physical meetings are overrated for making long-term technical decisions. > > X > > -- > GPG: ed25519/56034877E1F87C35 > GPG: rsa4096/1318EFAC5FBBDBCE > https://github.com/infinity0/pubkeys.git > > &subject=Re: Bug#844431: Revised patch: Oppose&References=<1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <150257075653.20937.3462548876194624932@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87tw1ca4i2.fsf@hope.eyrie.org> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87fucwza84.fsf@iris.silentflame.com> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <20170816152603.gvyvthm6anechrhi@localhost> <1479230864.4039229.788636857.1194DC82@webmail.messagingengine.com> <87mv6zeaqo.fsf@hope.eyrie.org> <20170816184035.GD31273@yellowpig> <87h8x7cok2.fsf@hope.eyrie.org> &In-Reply-To=">reply):

From: Ximin Luo <infinity0@debian.org>
To: Russ Allbery <rra@debian.org>, Bill Allombert <ballombe@debian.org>
Cc: reproducible-builds@lists.alioth.debian.org, Sean Whitton <spwhitton@spwhitton.name>, 844431@bugs.debian.org, Adrian Bunk <bunk@stusta.de>
Subject: Re: Bug#844431: Revised patch: Oppose
Date: Mon, 21 Aug 2017 14:22:00 +0000
Russ Allbery:
> Bill Allombert <ballombe@debian.org> writes:
> 
>> This is one of the reasons I do not attend DebConf anymore. We are an
>> online organization. Consultation should happen online. Metting are nice
>> but they should not be used to vet consensus and ignore absentees.
> 
>> So I object to Adrian being overriden on that ground.
> 
> That's only a part of what went into this, but I will strongly defend
> using the opportunity of in-person meetings to judge consensus.  It's very
> difficult to judge consensus over email because only the strong opinions
> are visible.  There are frequently situations where there's a large
> sentiment in one direction or another that isn't expressed in long threads
> full of lots of back and forth between a small handful of people who may
> or may not have representative opinions.
> 
> We can't always do it, and we obviously have to be sensitive to the fact
> that not everyone is in the room, but we're also going for consensus, not
> unanimity.  When we have the opportunity to get direction from a large
> gathering of developers, we should make use of it.
> 
> [..]

This was off-topic but now the thread is over I'd like to add some things here:

I don't think using the opportunity of in-person meetings to judge consensus is such a great thing. This has been a common theme recently cropping up in FOSS environments, pushed by certain groups and justified by the observations that "only strong opinions are visible [in email threads]". Much of the time, these groups overlap greatly with people that are used to doing things in a physical setting, including making decisions by judging crowd consensus.

Debian is primarily an online organisation as Bill says, these are its roots, this is how it became so big, and this is where the vast majority of productive work is done. I think discrediting all of that simply because "some people are loud on mailing lists" is really short-sighted and distorted. These cases are few, and not representative. I myself have contributed to a few of these cases, but again it's not representative of the vast majority of work that I do. I don't feel it's right for people to be judging online discussion methods, by focusing on a few negative cases and ignoring all the positive aspects.

Personally, and I'm sure many people are similar, I prefer to have long technical discussions like this in writing via email, and not face-to-face. I'm a very slow thinker, I don't make very good decisions in the fast-paced context of a normal physical conversation. If I sometimes seem like I do, it's usually only because I've thought about the problem beforehand and have my main points decided. 

Physical discussions encourage non-technical interactions - if you can pick the right words and presentation, you can make a crowd empathise with you for largely non-technical reasons. I don't think this is a good thing, we should recognise that this happens and not allow it to take over Debian's decision making processes. Online technical discussions are safer against these sorts of effects. People with long technical points to make, don't feel put off by the presence of a large non-technical crowd - and here I include "technical people" that have not properly thought about the topic or have no stake in the discussion. I truly think these latter opinions should be given less weight than a properly reasoned and well-thought-out opinion.

These sorts of points, which are vital to a healthy discussion, are easier to make in writing. You have an adequate amount of time to think, and you don't get interrupted by people who get bored by your thinking time and move the conversation on elsewhere before you have a chance to properly respond. Indeed in this thread there were lots of good points brought up criticising the wording of this policy, that nobody thought about during physical discussions at DebConf (which I didn't participate in for these reasons).

TL;DR: Debian is primarily an online organisation and that is its strength; physical meetings are overrated for making long-term technical decisions.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Reply sent to Sean Whitton <spwhitton@spwhitton.name>:
You have taken responsibility. (Mon, 21 Aug 2017 21:54:14 GMT) (full text, mbox, link).


Notification sent to Chris Lamb <lamby@debian.org>:
Bug acknowledged by developer. (Mon, 21 Aug 2017 21:54:14 GMT) (full text, mbox, link).


Message #460 received at 844431-close@bugs.debian.org (full text, mbox, reply):

From: Sean Whitton <spwhitton@spwhitton.name>
To: 844431-close@bugs.debian.org
Subject: Bug#844431: fixed in debian-policy 4.1.0.0
Date: Mon, 21 Aug 2017 21:50:23 +0000
Source: debian-policy
Source-Version: 4.1.0.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 844431@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sean Whitton <spwhitton@spwhitton.name> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 21 Aug 2017 14:17:42 -0700
Source: debian-policy
Binary: debian-policy
Architecture: all source
Version: 4.1.0.0
Distribution: unstable
Urgency: medium
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Sean Whitton <spwhitton@spwhitton.name>
Closes: 587279 630174 648271 732445 844431
Description: 
 debian-policy - Debian Policy Manual and related documents
Changes:
 debian-policy (4.1.0.0) unstable; urgency=medium
 .
   [ Sean Whitton ]
   * Policy: Packages should build reproducibly
     Wording: Sean Whitton <spwhitton@spwhitton.name>
     Seconded: Holger Levsen <holger@layer-acht.org>
     Seconded: Ondrej Novy <novy@ondrej.org>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Ximin Luo <infinity0@debian.org>
     Seconded: gregor herrmann <gregoa@debian.org>
     Closes: #844431
   * Policy: Restrictions on the use of /lib64/ and /usr/lib64/
     Wording: Bill Allombert <ballombe@debian.org>
     Seconded: Niels Thykier <niels@thykier.net>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #630174
   * Policy: Clarify how `x-terminal-emulator -e` must behave
     Wording: Jonathan Nieder <jrnieder@gmail.com>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #648271
   * Fix a singular/plural error in 9.6.
     Thanks to Didier Raboud for pointing out the problem.
   * Improve release process documentation in README.md.
   * Policy changes process:
     - Deprecate usage of the 'issue' usertag
       It is usually very clear whether an issue is a policy matter, so bugs
       can be simply closed, or moved to the 'discussion' phase.
       In the rare case that it's not clear whether the bug is a policy matter,
       it can remain unclassified, or be tagged 'moreinfo' (see below).
     - Add policy-specific usage for the 'moreinfo' tag.
   * tools/policy-bug-report:
     - Enhance to fetch bugs that have a given usertag or combination of
       usertags
     - Improve the lists of bugs generated, for posting to Planet Debian.
   * Add convention to upgrading checklist for indicating that a policy
     requirement is covered by Lintian.
 .
   [ Russ Allbery ]
   * Policy: Recommend including the upstream signing key
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
     Seconded: Jonathan Nieder <jrnieder@gmail.com>
     Seconded: Didier 'OdyX' Raboud <odyx@debian.org>
     Closes: #732445
   * Policy: Clearly allow non-default alternative non-free dependencies
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Simon McVittie <smcv@debian.org>
     Seconded: Sean Whitton <spwhitton@spwhitton.name>
     Closes: #587279
 .
   [ Russ Allbery & Sean Whitton ]
   * Convert the source of the Debian Policy Manual to reStructuredText,
     built using the Sphinx toolchain.
     Many thanks to Hideki Yamane <henrich@debian.or.jp> for the conversion
     scripts, and pushing the project forward.
     Thanks to David Bremner <bremner@debian.org> for help proofreading the
     output.
     - Drop PostScript output.
Checksums-Sha1: 
 e9e92524c0c9ce6586ad08d387d24c2abb9730b9 1998 debian-policy_4.1.0.0.dsc
 2b81d2018fce5b3c395b09270fdb4a205d37e9e1 672760 debian-policy_4.1.0.0.tar.xz
 35b7f8f467838240aaeaa132c5fd7e31e6f1e88d 2730658 debian-policy_4.1.0.0_all.deb
 70f0f71ab1ac930cc3d2d3cb42375fea3447eb7f 12026 debian-policy_4.1.0.0_amd64.buildinfo
Checksums-Sha256: 
 c42c56d2086bf8ad1a89d63c3eb376e4d78e989a4bd4042211cb3817b4d9eb04 1998 debian-policy_4.1.0.0.dsc
 009cd048b463db0b47473f3a9034bf92f82757586c5f2cc6562cdbecb3b0f560 672760 debian-policy_4.1.0.0.tar.xz
 98897470c64c5b6d49162b58e7b6157d20010fc171d2557a59b056615a70874b 2730658 debian-policy_4.1.0.0_all.deb
 4ddfd744b18561983e539cd77c2a6dec22f8233e43e26110ef4abf4229bff90b 12026 debian-policy_4.1.0.0_amd64.buildinfo
Files: 
 731a7e62695e3cb0d7f8dd459d9e4839 1998 doc optional debian-policy_4.1.0.0.dsc
 00bfec04a4eb5b4f339f9707f52bc41f 672760 doc optional debian-policy_4.1.0.0.tar.xz
 b5cbceb940d520260627e8a3d5870c90 2730658 doc optional debian-policy_4.1.0.0_all.deb
 56efdd4e810d37af066dc4988ae1204e 12026 doc optional debian-policy_4.1.0.0_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAlmbT/kACgkQaVt65L8G
YkD6ig//YNffFfyGPLMAstK9ntS8BVm7Cv1mdug6e6nzJ6yRzWCcVrB93haYwvUF
pV8GJhcab/90VEHVQsC6aZlFPbBfMMuM+9ZwREjbADogBhkKalFv8xkgqYO/DOgy
nl3zL2zf2sGsiOl7wVG59JsOFrEnqgKWu9KyHfk2m0gLuiDvTsgxEpSobGmLPetG
oglFiONIjpdqqbbl2QKQNkLMijYAqbf3yt63NV4o2MnIh01giNzD7rYl45cipqSw
zkrkTfUzN5fQdIif0+AjrAgwJ7Gk05kB4vSlc4lJpBhLoNnPCfbkT9BETtloJoe1
26OR1/KfNl7DVCltlF+mRTUf1boJFnhokocp1ukjB0avWKWiqzpgkTbcl4osd90b
Nn8zylZNk/gggxo2j+sQc08cNCc/hY02XPx/o12opZAZXukTtsOhr5/2l9MGIcID
pc82L/RA3KhXgpyrnWuMsagU6G+VjPSeb22M1JlYq6XuK4DmVid6PsmfUsy7i0/2
PXHBUvX5HiKF7kUCauScvEqvMWcDbWMfeIRnkjg0ddhXIjwc6WB/hJiH74dzs0Lb
tkE5urwdWGqlsQBo9dD/5N3Br5JdWeWb+5WsFrTNWTAcwdh5dhOCVSRk4igtmjDc
H7JkYKoLAEFHX+MzNH4t0dZ74eYy1o4t+D8QiHMLFD8TXCWJHhg=
=M6vp
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 24 Sep 2017 07:27:01 GMT) (full text, mbox, link).


Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Jan 31 00:48:02 2025; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.