Debian Bug report logs - #138409
dpkg-dev: please add support for .buildinfo files

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg (PTS, buildd, popcon).

Reported by: Randolph Chung <tausq@debian.org>

Date: Fri, 15 Mar 2002 07:18:01 UTC

Severity: wishlist

Tags: patch

Fixed in version dpkg/1.18.11

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

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

Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org:
Bug#138409; Package debian-policy. (full text, mbox, link).

Acknowledgement sent to Randolph Chung <tausq@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Package: debian-policy
Severity: wishlist

Proposal:
This is a proposal to add information about a package's build environment
to the "changes" file that accompanies the upload of each package. The 
build environment information contains the versions of packages used to
build the given package. The inclusion of this information is mandatory.
(for packages that declare a sufficiently high standards version, of course)

Rationale:
In working with the various ports for the Debian woody release (directly 
with ia64 and hppa, and indirectly via interactions with other porters 
on mips, etc) we have observed that it is often times useful to have a
record of the build environment of Debian packages. This is partially
taken care of by the build-dependency mechanism currently in place; the
present proposal is to take this one step further to include exact versions
of dependent packages used to build a certain source package.

Implementation:
This proposal should stand on its own without depending on a specific
implementation, but here is one idea for a possible implementation:

A new packaging helper tool will be created, hereby refered to as
dpkg-buildinfo.

dpkg-buildinfo will read debian/control and for each package listed as a 
build-dependency, add a line to bldinfo file of the form:
 <package> <version>
For example:
 debhelper 3.4.11

In addition to the explicit build-dependencies listed in debian/control,
dpkg-buildinfo also writes version info for all dependents of the 
build-essential package.

The resulting bldinfo file is appended to the .changes file created by the
packaging process under a "Build-Info" section.

Notes:
1. .changes files are not distributed in the archive, but are usually 
available on ftp-master. I was also informed by Ryan Murray that there are
plans to have more reliable archiving of changes files.
2. Ideally one might want to recursively list all the dependents of build-
dependencies too, but that is probably too expensive to compute.
3. My thanks to Ryan Murray, Anthony Towns and Lamont Jones for their 
comments and suggestions on refining this proposal.

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org:
Bug#138409; Package debian-policy. (full text, mbox, link).

Acknowledgement sent to Julian Gilbey <J.D.Gilbey@qmul.ac.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. (full text, mbox, link).

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

On Thu, Mar 14, 2002 at 11:08:42PM -0800, Randolph Chung wrote:
> 2. Ideally one might want to recursively list all the dependents of build-
> dependencies too, but that is probably too expensive to compute.

On my Pentium 166MHz, the following command took about 10s (real) to
run, with devscripts (>= 2.6.90) installed:

polya:~ $ perl -I/usr/share/devscripts -MDevscripts::PackageDeps -e
'$pkgs=new Devscripts::PackageDeps("/var/lib/dpkg/status"); print
join("\n",$pkgs->full_dependencies("build-essential")),"\n"'
perl-modules
cpp
libstdc++2.10-glibc2.2
[...]
binutils
libstdc++2.10-dev
make
polya:~ $

It could be easily modified to give the required output.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

     Julian Gilbey, Dept of Maths,             Debian GNU/Linux Developer
      Queen Mary, Univ. of London         see http://people.debian.org/~jdg/
   http://www.maths.qmul.ac.uk/~jdg/           or http://www.debian.org/
        Visit http://www.thehungersite.com/ to help feed the hungry

Acknowledgement sent to Randolph Chung <tausq@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. (full text, mbox, link).

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

> > 2. Ideally one might want to recursively list all the dependents of build-
> > dependencies too, but that is probably too expensive to compute.
> On my Pentium 166MHz, the following command took about 10s (real) to
> run, with devscripts (>= 2.6.90) installed:

Thanks, that was good to know.

one problem is that some packages have build-dependency chains that
when resolved completely are very deep, and sometimes contains dependency 
cycles. One could argue that these are bugs, but they seem difficult to fix
in some cases.

As reference, here is an old build-dependency graph for bash:
http://people.debian.org/~tausq/bash-build-deps.png (559k)

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

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

On Fri, Mar 15, 2002 at 07:14:44AM -0800, Randolph Chung wrote:
> > > 2. Ideally one might want to recursively list all the dependents of build-
> > > dependencies too, but that is probably too expensive to compute.
> > On my Pentium 166MHz, the following command took about 10s (real) to
> > run, with devscripts (>= 2.6.90) installed:
> 
> Thanks, that was good to know.
> 
> one problem is that some packages have build-dependency chains that
> when resolved completely are very deep, and sometimes contains dependency 
> cycles. One could argue that these are bugs, but they seem difficult to fix
> in some cases.
> 
> As reference, here is an old build-dependency graph for bash:
> http://people.debian.org/~tausq/bash-build-deps.png (559k)

The current bash only takes about 7-8 seconds.  Dependency cycles are
not a problem with my code: once a package is recorded as being a
dependency, it's dependencies are added to a "to-be-processed" list,
and then it is skipped if it is seen again.  The "to-be-processed list
is ... well, processed.  So my guess it that its time complexity is
approximately linear in the size of the status file and the total
number of dependencies.  Replacing status with available so I can test
some packages with more dependencies, I have not noticed a significant
difference between bash (5 dependencies including itself) and gcompris
(40 dependencies).  If you can find a bigger one easily, I'll test
that too!

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

     Julian Gilbey, Dept of Maths,             Debian GNU/Linux Developer
      Queen Mary, Univ. of London         see http://people.debian.org/~jdg/
   http://www.maths.qmul.ac.uk/~jdg/           or http://www.debian.org/
        Visit http://www.thehungersite.com/ to help feed the hungry

Acknowledgement sent to Manoj Srivastava <srivasta@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. (full text, mbox, link).

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

>>"Randolph" == Randolph Chung <tausq@debian.org> writes:


 Randolph> Proposal: This is a proposal to add information about a
 Randolph> package's build environment to the "changes" file that
 Randolph> accompanies the upload of each package. The build
 Randolph> environment information contains the versions of packages
 Randolph> used to build the given package. The inclusion of this
 Randolph> information is mandatory.  (for packages that declare a
 Randolph> sufficiently high standards version, of course)

	You can't introduce a new mandatory requirement, making all
 packages instantly buggy. You need a transition plan. And the bit
 about standards version is a red herring, really: packages are
 supposed to be current with policy (which is why policy froze) -- it
 is just that stable releases have packages that conform to policy as
 it existed then. Packages in Sid need to be current (can't claim
 ancient policy versions in unstable and not fix bugs, for example)


 Randolph> A new packaging helper tool will be created, hereby refered to as
 Randolph> dpkg-buildinfo.

	Why is this functionality not to be added to dpkg --build? Why
 require all packages to be touched when you can automagically get the
 desired result by changing the packaging tools? Or perhaps it should
 be in dpkg-gencontrol? (I don't see why this _has_ to go into the
 changes file, and not a new file designed for this to facilitate pre
 install checks). Indeed, having it available for preinstall checks in
 an automated fashion may be extremely useful once tools are developed
 to ensure build environment consistency. 


	Second, a formal policy proposal is way immature at this
 point. Take this over to -devel, discuss the implementation details,
 talk to dpkg maintainers, and come up with a working prototype of a
 dpkg-gencontrol/dpkg --build (in which case you do not need either a
 transition plan, or even a policy change)

	Indeed, mandating policy is a far worse way technically than a
 transparent change of the build tool chain.

	manoj
-- 
 It is impossible to enjoy idling thoroughly unless one has plenty of
 work to do. Jerome Klapka Jerome
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Acknowledgement sent to Junichi Uekawa <dancer@netfort.gr.jp>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>, debian-policy@packages.qa.debian.org. (full text, mbox, link).

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

Randolph Chung <tausq@debian.org> cum veritate scripsit:

> one problem is that some packages have build-dependency chains that
> when resolved completely are very deep, and sometimes contains dependency 
> cycles. One could argue that these are bugs, but they seem difficult to fix
> in some cases.


Would it be too bad to include whole " dpkg -l " output ?
It sometimes may help, especially when libraries start  
diverting other libraries etc.


regards,
	junichi

-- 
dancer@debian.org : Junichi Uekawa   http://www.netfort.gr.jp/~dancer
GPG Fingerprint : 17D6 120E 4455 1832 9423  7447 3059 BF92 CD37 56F4

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

> And the bit
>  about standards version is a red herring, really: packages are
>  supposed to be current with policy (which is why policy froze) -- it
>  is just that stable releases have packages that conform to policy as
>  it existed then. Packages in Sid need to be current (can't claim
>  ancient policy versions in unstable and not fix bugs, for example)

sure eventually all packages will move to the new scheme, and everything
will be happy. i'm not suggesting anything more or less. 

>  Randolph> A new packaging helper tool will be created, hereby refered to as
>  Randolph> dpkg-buildinfo.
> 
> 	Why is this functionality not to be added to dpkg --build? Why

i don't care if it's a separate tool or part of dpkg --build or part of
dpkg-gencontrol. Having policy dictate a specific implementation
methodology is a Bad Idea. This is like saying all internet RFCs need to
have attached implementations.

>  require all packages to be touched when you can automagically get the
>  desired result by changing the packaging tools? Or perhaps it should
>  be in dpkg-gencontrol? (I don't see why this _has_ to go into the
>  changes file, and not a new file designed for this to facilitate pre
>  install checks). Indeed, having it available for preinstall checks in
>  an automated fashion may be extremely useful once tools are developed
>  to ensure build environment consistency. 

What do you mean by preinstall checks?

The rationale for not including it in the deb (which was how I had it in
my original draft) is that this is not information that is particularly
useful to the general *user* of Debian. changes files have a one-to-one
relationship to a build process, which debs do not have. 

> 	Second, a formal policy proposal is way immature at this
>  point. Take this over to -devel, discuss the implementation details,
>  talk to dpkg maintainers, and come up with a working prototype of a
>  dpkg-gencontrol/dpkg --build (in which case you do not need either a
>  transition plan, or even a policy change)

Julian already gave a simple way of doing this.

> 	Indeed, mandating policy is a far worse way technically than a
>  transparent change of the build tool chain.

I will pursue this further with dpkg developers, but I think that is
orthogonal with having it in policy. Why do we put syntax of control
files in the policy, for example, if it is simply a dpkg implementation
detail?

randolph
-- 
Debian Developer <tausq@debian.org>
http://www.TauSq.org/

Severity set to `wishlist'. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. (full text, mbox, link).

Bug reassigned from package `debian-policy' to `dpkg'. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org:
Bug#138409; Package dpkg. (full text, mbox, link).

Acknowledgement sent to James Troup <james@nocrew.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org. (full text, mbox, link).

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

Julian Gilbey <J.D.Gilbey@qmul.ac.uk> writes:

> If you can find a bigger one easily, I'll test that too!

Evolution or any of the big gnome packages (e.g. gnumeric).

-- 
James

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org:
Bug#138409; Package dpkg. (full text, mbox, link).

Acknowledgement sent to Julian Gilbey <J.D.Gilbey@qmul.ac.uk>:
Extra info received and forwarded to list. Copy sent to Dpkg Development <debian-dpkg@lists.debian.org>, dpkg@packages.qa.debian.org. (full text, mbox, link).

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

On Fri, Mar 15, 2002 at 05:15:37PM +0000, James Troup wrote:
> Julian Gilbey <J.D.Gilbey@qmul.ac.uk> writes:
> 
> > If you can find a bigger one easily, I'll test that too!
> 
> Evolution or any of the big gnome packages (e.g. gnumeric).

evolution: 92 dependencies, an extra 1-2 seconds.
gnumeric:  69 dependencies, an extra second.

Hardly worth worrying about ;-)

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

     Julian Gilbey, Dept of Maths,             Debian GNU/Linux Developer
      Queen Mary, Univ. of London         see http://people.debian.org/~jdg/
   http://www.maths.qmul.ac.uk/~jdg/           or http://www.debian.org/
        Visit http://www.thehungersite.com/ to help feed the hungry

Bug reassigned from package `dpkg' to `dpkg-dev'. Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Tue, 05 Jan 2016 13:45:03 GMT) (full text, mbox, link).

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 05 Jan 2016 13:45:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Control: retitle -1 dpkg-dev: please add support for .buildinfo files
Control: tag -1 + patch

Hi!

The attached patch will enable dpkg-buildpackage to create .buildinfo
files as specified on the Debian wiki [1]. They have two main purposes:

 * recording information about the system environment used during a
   particular build—versions of the build dependencies installed, system
   architecture, etc. for easier forensics/debugging;
 * describe how to recreate (partially or in full) the original
   environment when trying to reproduce a particular build.

Since Guillem's preliminary review in February 2015 [2], the
specification has slightly elvolved to be a bit more relaxed and the
code have been improved.

One of the main change is that `.buildinfo` should now be named with an
arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
but can be set to an arbitrary value by the `--buildinfo-identifier`
command line flag.

To address privacy concerns, the Build-Path field is now only included
when either the build path starts by `/build/` or
`--always-include-path` has been specified on the command line of
`dpkg-genbuildinfo`.

.buildinfo files are now accepted (although discarded) by the Debian
archive [3]. This change should thus not affect Debian developpers in
their daily work.

 [1]: https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification
 [2]: https://lists.debian.org/debian-dpkg/2015/02/msg00000.html
 [3]: dak commit: https://lists.debian.org/debian-dak/2015/12/msg00079.html
      example ACCEPTED upload: https://tracker.debian.org/news/737293

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

[0001-Add-support-for-.buildinfo-files.patch (text/x-diff, attachment)]

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

Changed Bug title to 'dpkg-dev: please add support for .buildinfo files' from '[PROPOSAL] Add build environment data to <package>.changes files' Request was from Jérémy Bobbio <lunar@debian.org> to 138409-submit@bugs.debian.org. (Tue, 05 Jan 2016 13:45:04 GMT) (full text, mbox, link).

Added tag(s) patch. Request was from Jérémy Bobbio <lunar@debian.org> to 138409-submit@bugs.debian.org. (Tue, 05 Jan 2016 13:45:04 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Wed, 27 Jan 2016 08:03:12 GMT) (full text, mbox, link).

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 27 Jan 2016 08:03:12 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Jérémy Bobbio:
> The attached patch will enable dpkg-buildpackage to create .buildinfo
> files as specified on the Debian wiki [1]. They have two main purposes:
> 
>  * recording information about the system environment used during a
>    particular build—versions of the build dependencies installed, system
>    architecture, etc. for easier forensics/debugging;
>  * describe how to recreate (partially or in full) the original
>    environment when trying to reproduce a particular build.

I think the proposed patch is missing a field to record some environment
variables that can affect the build process. Right now, I'm thinking of
DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
dpkg-buildflags). Maybe others? Build profiles?

Initially I was against recording such information, but now that we
understand the purpose of .buildinfo files better and not mandate that
they be reproducible themselves, it doesn't matter if one contains
`DEB_BUILD_OPTIONS=parallel=4` and the other
`DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
trying to recreate a given package to filter this out.

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Thu, 28 Jan 2016 17:33:07 GMT) (full text, mbox, link).

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 28 Jan 2016 17:33:07 GMT) (full text, mbox, link).

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

Hi!

On Tue, 2016-01-05 at 14:32:51 +0100, Jérémy Bobbio wrote:
> Control: retitle -1 dpkg-dev: please add support for .buildinfo files
> Control: tag -1 + patch

> The attached patch will enable dpkg-buildpackage to create .buildinfo
> files as specified on the Debian wiki [1]. They have two main purposes:
> 
>  * recording information about the system environment used during a
>    particular build—versions of the build dependencies installed, system
>    architecture, etc. for easier forensics/debugging;
>  * describe how to recreate (partially or in full) the original
>    environment when trying to reproduce a particular build.
> 
> Since Guillem's preliminary review in February 2015 [2], the
> specification has slightly elvolved to be a bit more relaxed and the
> code have been improved.

Cool, thanks!

> One of the main change is that `.buildinfo` should now be named with an
> arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> but can be set to an arbitrary value by the `--buildinfo-identifier`
> command line flag.

Hmmm, leaking the hostname seems slightly privacy-concerning? If the
information therein is not relevant I'd rather use something like an
UUID (although that would require increasing the pseudo-build-essential
set), or just hashing the hostname-timestamp with something like md5
or sha1 or similar.

> To address privacy concerns, the Build-Path field is now only included
> when either the build path starts by `/build/` or
> `--always-include-path` has been specified on the command line of
> `dpkg-genbuildinfo`.

Thanks!

> .buildinfo files are now accepted (although discarded) by the Debian
> archive [3]. This change should thus not affect Debian developpers in
> their daily work.

Ah perfect, thanks for pushing for this. I'm planning on including
most of the patches that look fine for 1.18.5 or .6 ideally.

I've some pending changes I'll be committing to master or a separate
branch, that I'd like to be tested on the reproducible setup (ideally
against the already generated and pre-existing reproducible binaries),
if that's possible, I'll ask about that when those land, I just need
to finish up fewm more unit tests.

Here's a quick review:

> From 7b6d953f834b1e8800d3f8af4570d57d86e5c592 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= <lunar@debian.org>
> Date: Fri, 6 Nov 2015 12:17:39 +0000
> Subject: [PATCH] Add support for .buildinfo files

> diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1
> index 13770ba..54cee7b 100644
> --- a/man/dpkg-buildpackage.1
> +++ b/man/dpkg-buildpackage.1
> @@ -317,6 +322,12 @@ The source package version (without the epoch).
>  The upstream version.
>  .RE
>  .TP
> +.BI \-\-buildinfo-identifier= identifier
> +By default, \fBdpkg\-buildpackage\fP put the system hostname and the

“puts”, but perhaps better “uses foo and bar to create the quux
filename”.

> +current time in the name of the \fB.buildinfo\fP file. An arbitrary
> +identifier can be specified as a replacement (since dpkg 1.18.5).

I'd probably describe first what the option actually does, so that the
version when it got intruduced makes sense to what it refers to. And
then how does that diverges from the default.

And please, place new sentences on a new line. (I should probably
update the "coding-style" about that.)

> It must
> +contain only alphanumeric characters and hyphens.
> +.TP
>  .BI \-p sign-command
>  When \fBdpkg\-buildpackage\fP needs to execute GPG to sign a source
>  control (\fB.dsc\fP) file or a \fB.changes\fP file it will run

> diff --git a/man/dpkg-genbuildinfo.1 b/man/dpkg-genbuildinfo.1
> new file mode 100644
> index 0000000..77f2a76
> --- /dev/null
> +++ b/man/dpkg-genbuildinfo.1
> @@ -0,0 +1,98 @@

> +.BI \-\-always\-include\-path
> +By default, the \fBBuild-Path\fR field will only be written if the current
> +directory starts with \fB/build/\fR. Specify this option to always write
> +a \fBBuild-Path\fR field when generating the \fB.buildinfo\fR.

Missing escaped dash in field names.

> diff --git a/scripts/Dpkg/Control/Types.pm b/scripts/Dpkg/Control/Types.pm
> index 09e12d1..ad6e11b 100644
> --- a/scripts/Dpkg/Control/Types.pm
> +++ b/scripts/Dpkg/Control/Types.pm
> @@ -51,16 +52,17 @@ between Dpkg::Control and Dpkg::Control::Fields.
>  
>  use constant {
>      CTRL_UNKNOWN => 0,
> -    CTRL_INFO_SRC => 1,      # First control block in debian/control
> -    CTRL_INFO_PKG => 2,      # Subsequent control blocks in debian/control
> -    CTRL_INDEX_SRC => 4,     # Entry in repository's Packages files
> -    CTRL_INDEX_PKG => 8,     # Entry in repository's Sources files
> -    CTRL_PKG_SRC => 16,      # .dsc file of source package
> -    CTRL_PKG_DEB => 32,      # DEBIAN/control in binary packages
> -    CTRL_FILE_CHANGES => 64, # .changes file
> -    CTRL_FILE_VENDOR => 128, # File in $Dpkg::CONFDIR/origins
> -    CTRL_FILE_STATUS => 256, # $Dpkg::ADMINDIR/status
> -    CTRL_CHANGELOG => 512,   # Output of dpkg-parsechangelog
> +    CTRL_INFO_SRC => 1,         # First control block in debian/control
> +    CTRL_INFO_PKG => 2,         # Subsequent control blocks in debian/control
> +    CTRL_INDEX_SRC => 4,        # Entry in repository's Packages files
> +    CTRL_INDEX_PKG => 8,        # Entry in repository's Sources files
> +    CTRL_PKG_SRC => 16,         # .dsc file of source package
> +    CTRL_PKG_DEB => 32,         # DEBIAN/control in binary packages
> +    CTRL_FILE_BUILDINFO => 64,  # .buildinfo file
> +    CTRL_FILE_CHANGES => 128,   # .changes file
> +    CTRL_FILE_VENDOR => 256,    # File in $Dpkg::CONFDIR/origins
> +    CTRL_FILE_STATUS => 512,    # $Dpkg::ADMINDIR/status
> +    CTRL_CHANGELOG => 1024,     # Output of dpkg-parsechangelog

Just add the new type at the end, and use the next bit. Add the
comment above the line, like the current code looks like in master. :)

>  };
>  
>  =head1 CHANGES
> diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
> index 17ada97..ef62297 100755
> --- a/scripts/dpkg-buildpackage.pl
> +++ b/scripts/dpkg-buildpackage.pl
> @@ -412,6 +428,15 @@ if (defined $parallel) {
>      $build_opts->export();
>  }
>  
> +if (defined $buildinfo_identifier) {
> +    error(g_('buildinfo identifiers must not be empty and only contain alphanumeric characters and hyphens'))
> +        unless $buildinfo_identifier =~ /\A[A-Za-z0-9-]+\z/;

Can we just simply use the package name rules instead? It also avoids
potential problems with case and similar. (There's a
pkg_name_is_illegal function in Dpkg::Package already.)

> +} else {
> +    my $hostname = hostname;
> +    my $timestamp = strftime('%Y%m%dT%H%M%SZ', gmtime());
> +    $buildinfo_identifier = "$hostname-$timestamp";

See my comment at the top.

> +}
> +
>  set_build_profiles(@build_profiles) if @build_profiles;
>  
>  my $cwd = cwd();
> @@ -569,6 +594,25 @@ if ($include & BUILD_BINARY) {
>      withecho(@debian_rules, $buildtarget);
>      run_hook('binary', 1);
>      withecho(@rootcommand, @debian_rules, $binarytarget);
> +
> +    if (-e "../$pv.dsc") {
> +        run_hook('buildinfo', 1);
> +
> +        push @buildinfo_opts, "--admindir=$admindir" if $admindir;
> +
> +        my $buildinfo = "${pv}_${buildinfo_identifier}.buildinfo";
> +        withecho("dpkg-genbuildinfo @buildinfo_opts >../$buildinfo");
> +
> +        my $control = Dpkg::Control::Info->new('debian/control');
> +        my $sec = $control->get_source->{'Section'} // '-';
> +        my $pri = $control->get_source->{'Priority'} // '-';
> +        warning(_g('missing Section for source files')) if $sec eq '-';
> +        warning(_g('missing Priority for source files')) if $pri eq '-';
> +        withecho('dpkg-distaddfile', $buildinfo, $sec, $pri);
> +
> +    } else {
> +        warning(_g('no .dsc file, skipping .buildinfo generation'));
> +    }
>  }

ISTR mentioning this before, but I don't see why generating the
buildinfo file is tied to existing a source package at all? The source
should be included if we are including a source in the upload, that's
it.

> diff --git a/scripts/dpkg-genbuildinfo.pl b/scripts/dpkg-genbuildinfo.pl
> new file mode 100755
> index 0000000..5c5122b
> --- /dev/null
> +++ b/scripts/dpkg-genbuildinfo.pl
> @@ -0,0 +1,322 @@
> +#!/usr/bin/perl

> +sub append_deps {
> +    my $env_pkgs = shift;
> +    my $deps;
> +
> +    foreach my $dep_str (@_) {
> +        next unless $dep_str;
> +        $deps = deps_parse($dep_str, reduce_restrictions => 1, build_dep => 1);
> +        # add packages as unseen if they were not there before
> +        deps_iterate $deps, sub { ${$env_pkgs}{$_[0]->{package}} //= 0; 1 };

For non-built-ins functions please use parenthesis.

> +    }
> +}


> +while (@ARGV) {
> +    $_=shift(@ARGV);

Spaces around assignment.

> +    if (m/^-B$/) {
> +	set_build_type(BUILD_ARCH_DEP, $_);
> +    } elsif (m/^-A$/) {
> +	set_build_type(BUILD_ARCH_INDEP, $_);
> +    } elsif (m/^-c(.*)$/) {
> +	$controlfile = $1;
> +    } elsif (m/^-l(.*)$/) {
> +	$changelogfile = $1;
> +    } elsif (m/^-f(.*)$/) {
> +	$fileslistfile = $1;
> +    } elsif (m/^-F([0-9a-z]+)$/) {
> +        $changelogformat = $1;
> +    } elsif (m/^-u(.*)$/) {
> +	$uploadfilesdir = $1;
> +    } elsif (m/^--admindir=(.*)$/) {
> +	$admindir = $1;
> +    } elsif (m/^--always-include-path$/) {
> +	$always_include_path = 1;
> +    } elsif (m/^-(?:\?|-help)$/) {
> +	usage();
> +	exit(0);
> +    } elsif (m/^--version$/) {
> +	version();
> +	exit(0);
> +    } else {
> +        usageerr(_g("unknown option \`%s'"), $_);
> +    }
> +}

For new perl code let's not use hard tabs (I'll update the
coding-style if this is not there yet).

(For vim that would be: set expandtab; set sts=4.)

> +$fields->{'Source'} = $spackage;
> +if ($changelog->{'Binary-Only'}) {
> +    $fields->{'Source'} .= ' (' . $sourceversion . ')';
> +    $fields->{'Changes'} = $changelog->{'Changes'} . "\n\n"
> +                         . ' -- ' . $changelog->{'Maintainer'}
> +                         . '  ' . $changelog->{'Date'};
> +}

Hmmm, it bothers me slightly that the Changes field here diverges in
form from the one in the .changes file.

I think I'd prefer to have the Date as its own field, maybe always
included. And also the Maintainer field. Any reason to not include
them all the time or on their own?

> +$fields->{'Binary'} = join(' ', map { $_->{'Package'} } $control->get_packages());
> +# Avoid overly long line by splitting over multiple lines
> +if (length($fields->{'Binary'}) > 980) {
> +    $fields->{'Binary'} =~ s/(.{0,980}) /$1\n/g;
> +}
> +$fields->{'Architecture'} = join ' ', sort @archvalues;
> +$fields->{'Version'} = $binaryversion;
> +
> +my $cwd = cwd();
> +# Only include build path if explicitely required or in the common location
> +if ($always_include_path or $cwd =~ /\A\/build\//) {
> +    $fields->{'Build-Path'} = $cwd;
> +}

Hmm, I think the «/build» policy should be Debian-specific thing. Let's
move that into a vendor hook. For example it could be named perhaps
'builtin-system-build-path' or something along those lines that
returns the path if defined or undef otherwise.

> +$checksums->export_to_control($fields);
> +
> +my @status = parse_status("$admindir/status");
> +my $facts = shift @status;
> +my %depends=%{shift @status};
> +my @essential_pkgs=@{shift @status};

Spaces surrounding assignment operator. And I'd probably unpack them
in a single assignment, like:

  my ($facts, $depends, $essential_pkgs) = parse...;

and then use references.

> +my $deps;
> +my %env_pkgs;
> +
> +# parse essential list
> +
> +append_deps(\%env_pkgs, @essential_pkgs, 'build-essential',
> +                        $control->get_source->{'Build-Depends'});

Please do not hardcode build-essential here (as that's a Debianism),
use the vendor hook to get any custom builtin build dependencies.

> +if ($include & BUILD_ARCH_DEP) {
> +    append_deps(\%env_pkgs, $control->get_source->{'Build-Depends-Arch'});
> +}
> +
> +if ($include & BUILD_ARCH_INDEP) {
> +    append_deps(\%env_pkgs, $control->get_source->{'Build-Depends-Indep'});
> +}
> +
> +while (my ($pkg, $seen) = each(%env_pkgs)) {
> +    next if $seen;
> +    $env_pkgs{$pkg} = 1; # mark as seen
> +    next unless defined $facts->{pkg}->{$pkg}->[0];
> +    append_deps(\%env_pkgs, @{$depends{$pkg}});
> +    keys %env_pkgs; # reset iterator
> +}

Resetting every time we append new deps is a bit suboptimal. Instead
I'd use both a hash to track if the packages have been seen, and an
array to add packages to it.

> +my $environment = Dpkg::Deps::AND->new();
> +foreach my $pkg (sort keys %env_pkgs) {
> +    foreach my $installed_pkg (@{$facts->{pkg}->{$pkg}}) {
> +        my $version = $installed_pkg->{version};
> +        my $architecture = $installed_pkg->{architecture};
> +        my $pkg_name = $pkg;

> +        if (defined $architecture &&
> +            $architecture ne 'all' && $architecture ne $build_arch) {
> +            $pkg_name = "$pkg_name:$architecture";
> +        }

To me the $pkg_name handling here seems a bit confusing, I'd probably
just move the first assignment to an else block, and use $pkg in the
arch-qualified case which seems clearer.

Also this will include all Multi-Arch instances for a given package
regardless of them being used or not, I don't think that's desirable.

> +        my $dep = Dpkg::Deps::Simple->new("$pkg_name (= $version)");
> +        $environment->add($dep);
> +    }
> +}
> +$environment = "\n" . $environment->output();
> +$environment =~ s/, /,\n/g;
> +$fields->{'Build-Environment'} = $environment;
> +
> +$fields->output(\*STDOUT);

Thanks,
Guillem

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

Hi!

On Wed, 2016-01-27 at 08:58:47 +0100, Jérémy Bobbio wrote:
> Jérémy Bobbio:
> > The attached patch will enable dpkg-buildpackage to create .buildinfo
> > files as specified on the Debian wiki [1]. They have two main purposes:
> > 
> >  * recording information about the system environment used during a
> >    particular build—versions of the build dependencies installed, system
> >    architecture, etc. for easier forensics/debugging;
> >  * describe how to recreate (partially or in full) the original
> >    environment when trying to reproduce a particular build.
> 
> I think the proposed patch is missing a field to record some environment
> variables that can affect the build process. Right now, I'm thinking of
> DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
> dpkg-buildflags). Maybe others? Build profiles?
>
> Initially I was against recording such information, but now that we
> understand the purpose of .buildinfo files better and not mandate that
> they be reproducible themselves, it doesn't matter if one contains
> `DEB_BUILD_OPTIONS=parallel=4` and the other
> `DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
> trying to recreate a given package to filter this out.

Hmm right, makes sense, but I see this also to be a bit problematic.
There are many variables that do affect the build which we'd need to
record. Including all of the them seems like another privacy
concerning issue. Whitelisting, we might end up missing some but it's
privacy-safe; blacklisting we might end-up including sensitive ones,
but not miss any build-related ones, which is privacy-unsafe.

Some things that come to mind that do affect the build in a significant
way: CC, LD_LIBRARY_PATH, DEB*, DPKG_*, PATH, MAKEFLAGS.

The traditional build flags (i.e. CFLAGS, LDFLAGS, etc) might also affect
the build depending on the rules file.

Build profiles are already recorded in the binary packages, but having
that in the .buildinfo file seems right as it makes it easier to
reproduce the build environment. Ideally, parallel=N should not have
any visible effect but I guess it currently might. Most of the other
DEB_BUILD_OPTIONS do have a visible effect on the artifacts generated.

Thanks,
Guillem

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 28 Jan 2016 18:03:08 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Hi Guillem,

just quickly commenting on two sub topics…

On Donnerstag, 28. Januar 2016, Guillem Jover wrote:
> > One of the main change is that `.buildinfo` should now be named with an
> > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> > but can be set to an arbitrary value by the `--buildinfo-identifier`
> > command line flag.
> Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> information therein is not relevant I'd rather use something like an
> UUID (although that would require increasing the pseudo-build-essential
> set), or just hashing the hostname-timestamp with something like md5
> or sha1 or similar.

yeah, "something / anything" is fine. dak / the archive software can rename it 
anyway, as it likes. (I'd be in favor of naming the first accepted buildinfo 
file of the archive just "00000000" so that it's predictable…

> I've some pending changes I'll be committing to master or a separate
> branch, that I'd like to be tested on the reproducible setup (ideally
> against the already generated and pre-existing reproducible binaries),
> if that's possible, I'll ask about that when those land, I just need
> to finish up fewm more unit tests.

That's possible, though not (yet nor in near future) against pre-existing 
binaries. (We lack the code for that.)

What we can do easily, is build and upload dpkg to our repo and use it to 
build the whole Debian archive on amd64, which roughly takes 8 days for both 
sid+stretch, and thus roughly 4 days for one suite, if we disable building the 
other. (Which we can definitly do, especially if we don't disable building of 
new versions in that other suite…)

cheers,
	Holger

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

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

[Message part 1 (text/plain, inline)]

+many thanks for your thorough review! :-)

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

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 28 Jan 2016 18:39:03 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> I've some pending changes I'll be committing to master or a separate
> branch, that I'd like to be tested on the reproducible setup (ideally
> against the already generated and pre-existing reproducible binaries),
> if that's possible, I'll ask about that when those land, I just need
> to finish up fewm more unit tests.
> 
> Here's a quick review: […]

Thanks for the review! Just so I can organize my work, are your pending
changes related to the .buildinfo?

I can spend the next days improving the patch with your remarks, but I'd
rather not duplicate your work. :)

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

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

Hi!

On Thu, 2016-01-28 at 19:36:25 +0100, Jérémy Bobbio wrote:
> Guillem Jover:
> > I've some pending changes I'll be committing to master or a separate
> > branch, that I'd like to be tested on the reproducible setup (ideally
> > against the already generated and pre-existing reproducible binaries),
> > if that's possible, I'll ask about that when those land, I just need
> > to finish up fewm more unit tests.
> > 
> > Here's a quick review: […]
> 
> Thanks for the review! Just so I can organize my work, are your pending
> changes related to the .buildinfo?

Nope, they are for the sorted file lists, and ar member stuff.

> I can spend the next days improving the patch with your remarks, but I'd
> rather not duplicate your work. :)

Sure, go ahead. :)

Thanks,
Guillem

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

Hi!

zOn Thu, 2016-01-28 at 19:01:59 +0100, Holger Levsen wrote:
> On Donnerstag, 28. Januar 2016, Guillem Jover wrote:
> > Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> > information therein is not relevant I'd rather use something like an
> > UUID (although that would require increasing the pseudo-build-essential
> > set), or just hashing the hostname-timestamp with something like md5
> > or sha1 or similar.
> 
> yeah, "something / anything" is fine. dak / the archive software can rename it 
> anyway, as it likes.

Ah ok, perfect then.

> (I'd be in favor of naming the first accepted buildinfo 
> file of the archive just "00000000" so that it's predictable…

I'm not sure how we'd use a sequential number in a distributed manner
starting with 0s though? :9

> > I've some pending changes I'll be committing to master or a separate
> > branch, that I'd like to be tested on the reproducible setup (ideally
> > against the already generated and pre-existing reproducible binaries),
> > if that's possible, I'll ask about that when those land, I just need
> > to finish up fewm more unit tests.
> 
> That's possible, though not (yet nor in near future) against pre-existing 
> binaries. (We lack the code for that.)
> 
> What we can do easily, is build and upload dpkg to our repo and use it to 
> build the whole Debian archive on amd64, which roughly takes 8 days for both 
> sid+stretch, and thus roughly 4 days for one suite, if we disable building the 
> other. (Which we can definitly do, especially if we don't disable building of 
> new versions in that other suite…)

Oh ok, that's a bit unfortunate, it would be nice to be able to catch
any possible regressions in the generated binaries, and it would also
show how to use reproducible builds to see that nothing has actually
changed, even after implementation changes in the toolchain.

On Thu, 2016-01-28 at 19:02:53 +0100, Holger Levsen wrote:
> +many thanks for your thorough review! :-)

No problem!

Regards,
Guillem

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Fri, 29 Jan 2016 01:09: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 Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 29 Jan 2016 01:09:03 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Hi,

On Freitag, 29. Januar 2016, Guillem Jover wrote:
> > (I'd be in favor of naming the first accepted buildinfo
> > file of the archive just "00000000" so that it's predictable…
> I'm not sure how we'd use a sequential number in a distributed manner
> starting with 0s though? :9

we can't :) but dak could do it. (in the Debian use case.)


cheers,
	Holger

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

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 29 Jan 2016 15:09:06 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> > One of the main change is that `.buildinfo` should now be named with an
> > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> > but can be set to an arbitrary value by the `--buildinfo-identifier`
> > command line flag.
> 
> Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> information therein is not relevant I'd rather use something like an
> UUID (although that would require increasing the pseudo-build-essential
> set), or just hashing the hostname-timestamp with something like md5
> or sha1 or similar.

My hunch is that having a timestamp visible in the file name might help
recognizing files quickly after a bunch of builds, especially to
identify the last one. So I'd rather keep it.

If privacy is the goal, hashing just the hostname would not be help
much, as any precomputed table would work.

How about $TIMESTAMP-$EIGHT_FIRST_CHARS_OF_BUILDINFO_MD5?

(I'm picking md5 because it's already used in dpkg-gensymbols.)

> Can we just simply use the package name rules instead? It also avoids
> potential problems with case and similar. (There's a
> pkg_name_is_illegal function in Dpkg::Package already.)

Sounds reasonable. I've updated the wiki page and prepared a patch for
dak.

> > +    } else {
> > +        warning(_g('no .dsc file, skipping .buildinfo generation'));
> > +    }
> >  }
>
> ISTR mentioning this before, but I don't see why generating the
> buildinfo file is tied to existing a source package at all? The source
> should be included if we are including a source in the upload, that's
> it.

The whole puprose of the reproducible builds effort is to provide a
verifiable path from sources to binaries. Signed .buildinfo files are
certifications that the listed binary packages have been built using the
described source and environment.

Only listing the source in .buildinfo when a source is included in the
upload would prevent us to have multiple builders certify the same
binaries. That would cut us from providing multiple certifications and
would undermine the purpose of reproducible builds.

So I could remove the limitation, but the resulting .buildinfo file
would not be very useful for reproducible builds.

> > +$fields->{'Source'} = $spackage;
> > +if ($changelog->{'Binary-Only'}) {
> > +    $fields->{'Source'} .= ' (' . $sourceversion . ')';
> > +    $fields->{'Changes'} = $changelog->{'Changes'} . "\n\n"
> > +                         . ' -- ' . $changelog->{'Maintainer'}
> > +                         . '  ' . $changelog->{'Date'};
> > +}
> 
> Hmmm, it bothers me slightly that the Changes field here diverges in
> form from the one in the .changes file.

I can understand. It's been designed that way because it's actually only
there for binNMUs where the source is the same as the original and we
need a way to reconstruct the right changelog file.

Because sbuild might actually change its strings in the future, it felt
like plain copy/pasting was the safest. So recreating the changelog in
case of binNMU is about outputing the value of the Changes field in the
.buildinfo, a blank line, and the changelog from the original source.

> I think I'd prefer to have the Date as its own field, maybe always
> included. And also the Maintainer field. Any reason to not include
> them all the time or on their own?

I think they would be confusing. If we would to include the “Maintainer”
I guess we should call it “Changed-By” like in .changes. “Date”
as such would be a confusing name because I would tend to think of it
as the date of the build, and not as the date of the latest changelog
of a binNMU… So maybe “Changed-On” or “Change-Date”.

But this feels just more complicated than just the current
implementation, even if the format differs slightly. Maybe we can rename
that field instead to “Extra-Changelog-Entry” or something else so it's
clear they have different format?

> > +my $environment = Dpkg::Deps::AND->new();
> > +foreach my $pkg (sort keys %env_pkgs) {
> > +    foreach my $installed_pkg (@{$facts->{pkg}->{$pkg}}) {
> > +        my $version = $installed_pkg->{version};
> > +        my $architecture = $installed_pkg->{architecture};
> > +        my $pkg_name = $pkg;
> 
> > +        if (defined $architecture &&
> > +            $architecture ne 'all' && $architecture ne $build_arch) {
> > +            $pkg_name = "$pkg_name:$architecture";
> > +        }
> […]
> Also this will include all Multi-Arch instances for a given package
> regardless of them being used or not, I don't think that's desirable.

Can we know for sure which one have been used?


I'm already working on other changes you suggested.

Thanks,
-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 29 Jan 2016 15:27:08 GMT) (full text, mbox, link).

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

Hi!

On Thu, 2016-01-28 at 19:36:25 +0100, Jérémy Bobbio wrote:
> Guillem Jover:
> > I've some pending changes I'll be committing to master or a separate
> > branch, that I'd like to be tested on the reproducible setup (ideally
> > against the already generated and pre-existing reproducible binaries),
> > if that's possible, I'll ask about that when those land, I just need
> > to finish up fewm more unit tests.
> > 
> > Here's a quick review: […]

> I can spend the next days improving the patch with your remarks, but I'd
> rather not duplicate your work. :)

BTW make sure «DPKG_DEVEL_MODE=1 make check» passes (in case you were
not doing so before :), which should help to trap some problems with
the perl code.

Thanks,
Guillem

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 29 Jan 2016 16:27:05 GMT) (full text, mbox, link).

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

Hi!

On Fri, 2016-01-29 at 16:07:54 +0100, Jérémy Bobbio wrote:
> Guillem Jover:
> > > One of the main change is that `.buildinfo` should now be named with an
> > > arbitrary identifier. By default this defaults to $HOSTNAME-$TIMESTAMP
> > > but can be set to an arbitrary value by the `--buildinfo-identifier`
> > > command line flag.
> > 
> > Hmmm, leaking the hostname seems slightly privacy-concerning? If the
> > information therein is not relevant I'd rather use something like an
> > UUID (although that would require increasing the pseudo-build-essential
> > set), or just hashing the hostname-timestamp with something like md5
> > or sha1 or similar.
> 
> My hunch is that having a timestamp visible in the file name might help
> recognizing files quickly after a bunch of builds, especially to
> identify the last one. So I'd rather keep it.

I see no problem at all with that, and seems like a good idea. I only
take slight issue with the hostname really.

> If privacy is the goal, hashing just the hostname would not be help
> much, as any precomputed table would work.
> 
> How about $TIMESTAMP-$EIGHT_FIRST_CHARS_OF_BUILDINFO_MD5?
> 
> (I'm picking md5 because it's already used in dpkg-gensymbols.)

Yeah md5 is not security sensitive here, so it's good enough. Using
$timestamp-$selfmd5 seems good. And as long as we specify that this
format could change in the future I think we leave room to maneuver.

> > Can we just simply use the package name rules instead? It also avoids
> > potential problems with case and similar. (There's a
> > pkg_name_is_illegal function in Dpkg::Package already.)
> 
> Sounds reasonable. I've updated the wiki page and prepared a patch for
> dak.

Thanks!

> > > +    } else {
> > > +        warning(_g('no .dsc file, skipping .buildinfo generation'));
> > > +    }
> > >  }
> >
> > ISTR mentioning this before, but I don't see why generating the
> > buildinfo file is tied to existing a source package at all? The source
> > should be included if we are including a source in the upload, that's
> > it.
> 
> The whole puprose of the reproducible builds effort is to provide a
> verifiable path from sources to binaries. Signed .buildinfo files are
> certifications that the listed binary packages have been built using the
> described source and environment.
> 
> Only listing the source in .buildinfo when a source is included in the
> upload would prevent us to have multiple builders certify the same
> binaries. That would cut us from providing multiple certifications and
> would undermine the purpose of reproducible builds.
> 
> So I could remove the limitation, but the resulting .buildinfo file
> would not be very useful for reproducible builds.

I understand why you need the chain, but don't forget that this quite old
bug report was about including build information in uploads, which seems
to me is a superset of the needs of the reproducibility project! So I've
to take into account the general case here too. :)

Also I kind of fail to see a problem here. With the current implementation
when there is no source, the .buildinfo file is not generated at all. It
seems to me switching to generating it even when there is no source is no
worse (it's actually better!) than not including a .buildinfo at all.

> > > +$fields->{'Source'} = $spackage;
> > > +if ($changelog->{'Binary-Only'}) {
> > > +    $fields->{'Source'} .= ' (' . $sourceversion . ')';
> > > +    $fields->{'Changes'} = $changelog->{'Changes'} . "\n\n"
> > > +                         . ' -- ' . $changelog->{'Maintainer'}
> > > +                         . '  ' . $changelog->{'Date'};
> > > +}
> > 
> > Hmmm, it bothers me slightly that the Changes field here diverges in
> > form from the one in the .changes file.
> 
> I can understand. It's been designed that way because it's actually only
> there for binNMUs where the source is the same as the original and we
> need a way to reconstruct the right changelog file.
> 
> Because sbuild might actually change its strings in the future, it felt
> like plain copy/pasting was the safest. So recreating the changelog in
> case of binNMU is about outputing the value of the Changes field in the
> .buildinfo, a blank line, and the changelog from the original source.

Sure.

> > I think I'd prefer to have the Date as its own field, maybe always
> > included. And also the Maintainer field. Any reason to not include
> > them all the time or on their own?
> 
> I think they would be confusing. If we would to include the “Maintainer”
> I guess we should call it “Changed-By” like in .changes. “Date”
> as such would be a confusing name because I would tend to think of it
> as the date of the build, and not as the date of the latest changelog
> of a binNMU… So maybe “Changed-On” or “Change-Date”.
> 
> But this feels just more complicated than just the current
> implementation, even if the format differs slightly. Maybe we can rename
> that field instead to “Extra-Changelog-Entry” or something else so it's
> clear they have different format?

Actually yes, naming it just Changes is pretty misleading, as I'd
expect to see it even on non-binNMU builds. Naming it instead
something like Binary-Only-Changes (to somewhat match the Binary-Only
field) would be better IMO (or can you come up with a better name?). With
that I'd be fine with having it contain the entire changelog entry for the
binNMU.

> > > +my $environment = Dpkg::Deps::AND->new();
> > > +foreach my $pkg (sort keys %env_pkgs) {
> > > +    foreach my $installed_pkg (@{$facts->{pkg}->{$pkg}}) {
> > > +        my $version = $installed_pkg->{version};
> > > +        my $architecture = $installed_pkg->{architecture};
> > > +        my $pkg_name = $pkg;
> > 
> > > +        if (defined $architecture &&
> > > +            $architecture ne 'all' && $architecture ne $build_arch) {
> > > +            $pkg_name = "$pkg_name:$architecture";
> > > +        }
> > […]
> > Also this will include all Multi-Arch instances for a given package
> > regardless of them being used or not, I don't think that's desirable.
> 
> Can we know for sure which one have been used?

In principle yes, the ones that would be needed to satisfy the
build dependencies, which is partially what dpkg-checkbuilddeps is
doing.

> I'm already working on other changes you suggested.

Ah perfect.

Oh and had completely forgotten, could you please also add a new
deb-buildinfo(5) man page describing the format of the file? I really
want all file formats supported by dpkg to be documented here for
external parties to refer to.

Thanks,
Guillem

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Sat, 30 Jan 2016 14:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 30 Jan 2016 14:21:05 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> Lunar:
> > I think the proposed patch is missing a field to record some environment
> > variables that can affect the build process. Right now, I'm thinking of
> > DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
> > dpkg-buildflags). Maybe others? Build profiles?
> >
> > Initially I was against recording such information, but now that we
> > understand the purpose of .buildinfo files better and not mandate that
> > they be reproducible themselves, it doesn't matter if one contains
> > `DEB_BUILD_OPTIONS=parallel=4` and the other
> > `DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
> > trying to recreate a given package to filter this out.
> 
> Hmm right, makes sense, but I see this also to be a bit problematic.
> There are many variables that do affect the build which we'd need to
> record. Including all of the them seems like another privacy
> concerning issue. Whitelisting, we might end up missing some but it's
> privacy-safe; blacklisting we might end-up including sensitive ones,
> but not miss any build-related ones, which is privacy-unsafe.
> 
> Some things that come to mind that do affect the build in a significant
> way: CC, LD_LIBRARY_PATH, DEB*, DPKG_*, PATH, MAKEFLAGS.
> 
> The traditional build flags (i.e. CFLAGS, LDFLAGS, etc) might also affect
> the build depending on the rules file.

I was thinking of a whitelist approach and to start with use cases we
can already think of, adding more variables to record if we identify
them as missing in the future.

How about naming the field “Environment-Variables”?

I will also add another vendor hook for the list of variables.

> Build profiles are already recorded in the binary packages, but having
> that in the .buildinfo file seems right as it makes it easier to
> reproduce the build environment.

Should it be a new field or would recording the DEB_BUILD_PROFILES
variable be enough?

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Sun, 31 Jan 2016 09:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 31 Jan 2016 09:06:04 GMT) (full text, mbox, link).

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

On Sat, 2016-01-30 at 15:18:30 +0100, Jérémy Bobbio wrote:
> Guillem Jover:
> > Lunar:
> > > I think the proposed patch is missing a field to record some environment
> > > variables that can affect the build process. Right now, I'm thinking of
> > > DEB_BUILD_OPTIONS and DEB_flag_{SET,STRIP,APPEND,PREPEND} (from
> > > dpkg-buildflags). Maybe others? Build profiles?
> > >
> > > Initially I was against recording such information, but now that we
> > > understand the purpose of .buildinfo files better and not mandate that
> > > they be reproducible themselves, it doesn't matter if one contains
> > > `DEB_BUILD_OPTIONS=parallel=4` and the other
> > > `DEB_BUILD_OPTIONS=parallel=16`. It is the responsibility of users
> > > trying to recreate a given package to filter this out.
> > 
> > Hmm right, makes sense, but I see this also to be a bit problematic.
> > There are many variables that do affect the build which we'd need to
> > record. Including all of the them seems like another privacy
> > concerning issue. Whitelisting, we might end up missing some but it's
> > privacy-safe; blacklisting we might end-up including sensitive ones,
> > but not miss any build-related ones, which is privacy-unsafe.
> > 
> > Some things that come to mind that do affect the build in a significant
> > way: CC, LD_LIBRARY_PATH, DEB*, DPKG_*, PATH, MAKEFLAGS.
> > 
> > The traditional build flags (i.e. CFLAGS, LDFLAGS, etc) might also affect
> > the build depending on the rules file.
> 
> I was thinking of a whitelist approach and to start with use cases we
> can already think of, adding more variables to record if we identify
> them as missing in the future.

That works for me, and it's no worse than our current support for
build flags, where we have a whitelist too. So with new build flags
we need to explicitly add support for them too. Althought here we'd
like to catch build variables even if dpkg-buildflags does not support
them (say CXX).

> How about naming the field “Environment-Variables”?

Hmm, or Environment, or Build-Environment, which reminds me that I've
found the usage of Build-Environment (as the list of transitively
required packages) slightly confusing, precisely because the first
thing that comes to mind with environment is the variable space.

Perhaps we should consider renaming that one? Say Build-Packages (but
that might be confusing), Build-Depends-Used, or something else? We
also already have a Built-Using field too (although for source
packages not binary ones, with a name I've also found slightly
confusing as being too generic).

> I will also add another vendor hook for the list of variables.

I don't think this is necessary in this case, all current variables
seem pretty dpkg-generic to me. Or do you see any that is
Debian-specific?

> > Build profiles are already recorded in the binary packages, but having
> > that in the .buildinfo file seems right as it makes it easier to
> > reproduce the build environment.
> 
> Should it be a new field or would recording the DEB_BUILD_PROFILES
> variable be enough?

These can be passed also through the -P option to dpkg-buildpackage and
dpkg-checkbuilddeps, but this is not currently possible for all scripts
that use build profiles, and that's why dpkg-buildpackage sets the
DEB_BUILD_PROFILES variable from the command-line option value, so I
think just recording the environment is enough for now. We can always
also record them in a Build-Profiles field if need be.

Thanks,
Guillem

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 31 Jan 2016 13:45:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> > How about naming the field “Environment-Variables”?
> 
> Hmm, or Environment, or Build-Environment, which reminds me that I've
> found the usage of Build-Environment (as the list of transitively
> required packages) slightly confusing, precisely because the first
> thing that comes to mind with environment is the variable space.
> 
> Perhaps we should consider renaming that one? Say Build-Packages (but
> that might be confusing), Build-Depends-Used, or something else? We
> also already have a Built-Using field too (although for source
> packages not binary ones, with a name I've also found slightly
> confusing as being too generic).

Ok. What about “Environment” for the variables, and
“Installed-Build-Depends” for the list of packages?

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 31 Jan 2016 16:45:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> Oh and had completely forgotten, could you please also add a new
> deb-buildinfo(5) man page describing the format of the file? I really
> want all file formats supported by dpkg to be documented here for
> external parties to refer to.

I think the manpage is the only remaining task that I had on my lists
after your comments. I'd rather make sure we all agree on the fields
before getting to it.

An updated patch is attached.

A breakdown of the change since the last submitted patch is available
for easier review:
https://anonscm.debian.org/cgit/reproducible/dpkg.git/log/?h=pu/buildinfo

931b291 dpkg-genbuildinfo: add missing escapes to manpage
7fb4335 dpkg-buildpackage: Use a more privacy-preserving default buildinfo identifier
ecda68c dpkg-buildpackage: Use the same restrictions for buildinfo identifiers as package names
df785bb dpkg-genbuildinfo: Use g_() instead of deprecated _g()
e6efefb dpkg-buildpackage: reword description of --buildinfo-identifier in manpage
c9d96ef dpkg-genbuildinfo: Use vendor hook instead of hardcoding build-essential
414eda9 dpkg-genbuildinfo: implement allowed Build-Paths as a vendor hook
bf6b372 dpkg-genbuildinfo: Improve handling of parse_status return values
73cf850 dpkg-genbuildinfo: Rename Changes in Binary-Only-Changes
83d85ce dpkg-buildpackage: always create a .buildinfo file
b02b2bf dpkg-genbuildinfo: Use parenthesis for non-built-ins functions
fa122f5 dpkg-genbuildinfo: replace tabs with spaces
53aecbb dpkg-genbuildinfo: Improve computation of dependencies
fcedf2e dpkg-genbuildinfo: Add support for build profiles
413bf9e dpkg-genbuildinfo: Rewrite Build-Environment generator
8040903 dpkg-genbuildinfo: Rename Build-Environment to Installed-Build-Depends
9be50d7 dpkg-genbuildinfo: Record some environment variables

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

[dpkg_buildinfo_v2.patch (text/x-diff, attachment)]

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Tue, 02 Feb 2016 15:39:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Hi!

We were discussions the restrictions on buildinfo identifiers:

    fweb_1.62-12+b2_brahms-20120530T114812Z.buildinfo
                    ^^^^^^^^^^^^^^^^^^^^^^^
                          this part

The proposal was “the string should consist only of alphanumeric
characters and hyphens”. Guillem made the following comment while
reviewing the patches for dpkg:

Guillem Jover:
> Can we just simply use the package name rules instead? It also avoids
> potential problems with case and similar. (There's a
> pkg_name_is_illegal function in Dpkg::Package already.)

After reaching out to Ansgar with a patch for dak to implement the
above, he replied:

Ansgar Burchardt:
> The allowed sets for package names and the suffix of buildinfo
> filenames won't be the same even with that change.  However currently
> the suffix of buildinfo filenames matches what is allowed for .changes
> files.
> 
> I'm not sure why allowing capital letters used in the suffix of
> buildinfo files should be an issue? After all we allow capital letters
> for both version numbers (part of the filename) and in names of changes
> files.
> 
> (In the other direction not everything allowed as a package name can be
> used as the suffix of .changes and .buildinfo files either.)

Guillem, any further comments? Do you have any strong opposition to the
initial proposal?

-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Thu, 04 Feb 2016 00:42:04 GMT) (full text, mbox, link).

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

Hi!

On Tue, 2016-02-02 at 16:34:40 +0100, Jérémy Bobbio wrote:
> We were discussions the restrictions on buildinfo identifiers:
> 
>     fweb_1.62-12+b2_brahms-20120530T114812Z.buildinfo
>                     ^^^^^^^^^^^^^^^^^^^^^^^
>                           this part
> 
> The proposal was “the string should consist only of alphanumeric
> characters and hyphens”. Guillem made the following comment while
> reviewing the patches for dpkg:
> 
> Guillem Jover:
> > Can we just simply use the package name rules instead? It also avoids
> > potential problems with case and similar. (There's a
> > pkg_name_is_illegal function in Dpkg::Package already.)
> 
> After reaching out to Ansgar with a patch for dak to implement the
> above, he replied:
> 
> Ansgar Burchardt:
> > The allowed sets for package names and the suffix of buildinfo
> > filenames won't be the same even with that change.  However currently
> > the suffix of buildinfo filenames matches what is allowed for .changes
> > files.

Ah ok matching what is allowed in «.changes» with what is allowed in
«.buildinfo» makes sense. But…

> > I'm not sure why allowing capital letters used in the suffix of
> > buildinfo files should be an issue? After all we allow capital letters
> > for both version numbers (part of the filename) and in names of changes
> > files.

…are uppercase letters allowed for the third (arch) component in
.changes files? No architecture should be uppercase anyway.

I'd just like to avoid allowing things that then becomes very
difficult to ban after the fact.

> > (In the other direction not everything allowed as a package name can be
> > used as the suffix of .changes and .buildinfo files either.)

True, which would introduce more undesired things.

> Guillem, any further comments? Do you have any strong opposition to the
> initial proposal?

Actually after consideration, I don't think I have, more so if it
makes representing dates in an incorrect way (the ‘Z’).

Thanks,
Guillem

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

Hi!

On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> Guillem Jover:
> > > How about naming the field “Environment-Variables”?
> > 
> > Hmm, or Environment, or Build-Environment, which reminds me that I've
> > found the usage of Build-Environment (as the list of transitively
> > required packages) slightly confusing, precisely because the first
> > thing that comes to mind with environment is the variable space.
> > 
> > Perhaps we should consider renaming that one? Say Build-Packages (but
> > that might be confusing), Build-Depends-Used, or something else? We
> > also already have a Built-Using field too (although for source
> > packages not binary ones, with a name I've also found slightly
> > confusing as being too generic).
> 
> Ok. What about “Environment” for the variables,

I'm not sure if it'd be better to be explicit about this being a build
thing, and not just a random environment. Are you worried about confusion
with the previous usage of the field with the same name?

> and “Installed-Build-Depends” for the list of packages?

I asked for more suggestions on #debian-dpkg, and Johannes Schauer
suggested Transitive-Build-Depends, which is something I had in mind
too (that or «Recursive-»), but kind of softly discarded in trying to
have a consistently namespaced «Build-» field name. :) Some of the
reasons Johannes put forward are that this name is better because it
clearly describes what's the exact purpose of the field, and gives
no room for misinterpretation. And if we had to change the algorithm
we could just use a new name. All of which I concur with.

(BTW I also realized that I don't think we are including «Essential:yes»
packages in that set, and we should.)

Thanks,
Guillem

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

On Thu, 2016-02-04 at 09:44:13 +0100, Guillem Jover wrote:
> (BTW I also realized that I don't think we are including «Essential:yes»
> packages in that set, and we should.)

Actually, disregard this, they are already included! Sorry for the
noise.

Thanks,
Guillem

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

[Message part 1 (text/plain, inline)]

Hi,

On Donnerstag, 4. Februar 2016, Guillem Jover wrote:
> I asked for more suggestions on #debian-dpkg, and Johannes Schauer
> suggested Transitive-Build-Depends, which is something I had in mind
> too (that or «Recursive-»), but kind of softly discarded in trying to
> have a consistently namespaced «Build-» field name. :) Some of the
> reasons Johannes put forward are that this name is better because it
> clearly describes what's the exact purpose of the field, and gives
> no room for misinterpretation. And if we had to change the algorithm
> we could just use a new name. All of which I concur with.

I don't think "Transitive-Build-Depends" is a good name here, first, because  
I think 97% of the people will have no idea what it means. And second, because 
I think it's wrong, as the field would only list the installed build depends, 
but not all transitive ones. (Or maybe my second point is moot, but then I 
fall under the 97% too, which would strengthen my first point ;)

Build-packages-installed: ?

cheers,
	Holger

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

Acknowledgement sent to Johannes Schauer <josch@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 04 Feb 2016 09:39:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Hi,

Quoting Guillem Jover (2016-02-04 09:44:13)
> On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> > and “Installed-Build-Depends” for the list of packages?
> 
> I asked for more suggestions on #debian-dpkg, and Johannes Schauer
> suggested Transitive-Build-Depends, which is something I had in mind
> too (that or «Recursive-»), but kind of softly discarded in trying to
> have a consistently namespaced «Build-» field name. :) Some of the
> reasons Johannes put forward are that this name is better because it
> clearly describes what's the exact purpose of the field, and gives
> no room for misinterpretation. And if we had to change the algorithm
> we could just use a new name. All of which I concur with.

maybe we can merge Lunar's original suggestion Installed-Build-Depends (a name
which is missing the transitive/recursive-ness) with the new suggestion and
make it:

Installed-Transitive-Build-Depends

This way it would not be confused with the *actual* transitive build depends
which would also include non-installed ones or even non-installable ones
because parts of the transitive build depends set might conflict with each
other.

One could also argue that the recorded build dependencies being the installed
as well as transitive ones is quite implicit and thus neither needs to be
mentioned as part of the field.

just my 2 cents

cheers, josch

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

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

[Message part 1 (text/plain, inline)]

Hi Josch,

On Donnerstag, 4. Februar 2016, Johannes Schauer wrote:
> maybe we can merge Lunar's original suggestion Installed-Build-Depends (a
> name which is missing the transitive/recursive-ness) with the new
> suggestion and make it:
> 
> Installed-Transitive-Build-Depends
> 
> This way it would not be confused with the *actual* transitive build
> depends

I'm sorry, but I think the opposite will be the case, this will cause *more* 
confusion: what are "installed transitive build depends" vs "actual transitive 
build depends"? 

I know that *you* have grasped the concept of transitive build depends very 
well, but I'm pretty sure that 97% of the DD population have no idea what 
transitive build depends are, especially compared to build-depends or 
alternative build-depends. And even 70% were too many.
 (AFAIK transitive build-depends are all possible build depends, so if a 
package build depends on python2 || python3 both python versions will be part 
of the transitive build depends. (Is that even correct?)

Also see $(torsocks dict transitive) - what does this word even mean? ;-)

cheers,
	Holger

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

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 04 Feb 2016 11:27:04 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Guillem Jover:
> On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> > Guillem Jover:
> > > > How about naming the field “Environment-Variables”?
> > > 
> > > Hmm, or Environment, or Build-Environment, which reminds me that I've
> > > found the usage of Build-Environment (as the list of transitively
> > > required packages) slightly confusing, precisely because the first
> > > thing that comes to mind with environment is the variable space.
> > > 
> > > Perhaps we should consider renaming that one? Say Build-Packages (but
> > > that might be confusing), Build-Depends-Used, or something else? We
> > > also already have a Built-Using field too (although for source
> > > packages not binary ones, with a name I've also found slightly
> > > confusing as being too generic).
> > 
> > Ok. What about “Environment” for the variables,
> 
> I'm not sure if it'd be better to be explicit about this being a build
> thing, and not just a random environment. Are you worried about confusion
> with the previous usage of the field with the same name?

I'm indeed worry about confusion. The file is called '.buildinfo', so I
think it's fine to imply that these were environment variables defined
during the time the .buildinfo was generated.


      .
     / \         We have entered
    / ! \    bike shedding territory
    ~~~~~


-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

Acknowledgement sent to Jérémy Bobbio <lunar@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 04 Feb 2016 11:27:07 GMT) (full text, mbox, link).

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

[Message part 1 (text/plain, inline)]

Holger Levsen:
> I know that *you* have grasped the concept of transitive build depends very 
> well, but I'm pretty sure that 97% of the DD population have no idea what 
> transitive build depends are, especially compared to build-depends or 
> alternative build-depends. And even 70% were too many.

Sorry Holger but we are introducing new concepts. So sure, 97% of the DD
population have no idea what we are talking about, but that's fine.

We have to educate them about .buildinfo file and what the various
fields mean. We have to aim at field names that are as unambigious as
possible to avoid laying traps on users.

For the particular case of “Installed-Transitive-Build-Depends”,
it's easy enough to explain “these are the name and version of all
packages which made building these binary packages possible”. Math
geeks can get a more formal definition.

“Built-Using” is already taken with a very precise meaning (and is there
for license-compliance reasons), but that would be the simpliest way to
sum up the short statement above. Given these are .buildinfo files, I
would be bold and suggest just “Using”.


I need to state that I care more about not drowning ourselves in bike
shedding than finding the perfect name.


-- 
Lunar                                .''`. 
lunar@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-

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

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

[Message part 1 (text/plain, inline)]

no thanks for totally dismissing what I said…

and making funny signs about the crap I said. very funny.

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

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

[Message part 1 (text/plain, inline)]

Lunar, 

also:

< josch> personally i'd be happy with Lunar's suggestion: Installed-Build-
Depends
< josch> i think the natural understanding of that term implies the 
transitivity as well as that it's not the closure that is meant
* h01ger likes Installed-Build-Depends too
< h01ger> | [12:14] < josch> i think the natural understanding of that term 
implies the transitivity as well as that it's not the closure that is meant
< h01ger> | agreed on that as well

and, yes, finding a proper name takes time, but is no bike shedding, instead 
it helps avoiding to understanding future confusions. If you don't like 
naming, don't participate, but don't dismiss other peoples work.


	Holger

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

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

[Message part 1 (text/plain, inline)]

Hi,

Quoting Jérémy Bobbio (2016-02-04 12:23:05)
> We have to educate them about .buildinfo file and what the various fields
> mean. We have to aim at field names that are as unambigious as possible to
> avoid laying traps on users.
> 
> For the particular case of “Installed-Transitive-Build-Depends”, it's easy
> enough to explain “these are the name and version of all packages which made
> building these binary packages possible”. Math geeks can get a more formal
> definition.

since we probably never want to record the explicitly non-transitive build
dependencies in the .buildinfo (because those are already recorded elsewhere),
adding "transitive" to the name is probably not necessary. On IRC I agreed with
Holger that using your original proposal and calling it Installed-Build-Depends
should be enough. I think even an uneducated reader would quickly figure out
that this field is not listing the direct but also the indirect (transitive)
depends.

Thanks and sorry for bikeshedding!

cheers, josch

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

Message sent on to Randolph Chung <tausq@debian.org>:
Bug#138409. (Thu, 03 Nov 2016 05:24:03 GMT) (full text, mbox, link).

Message #208 received at 138409-submitter@bugs.debian.org (full text, mbox, reply):

Control: tag 138409 pending

Hi!

Bug #138409 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

    https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=ee89753

---
commit ee8975322f93e41ccd5787ebb6cadaecc81cadf3
Author: Guillem Jover <guillem@debian.org>
Date:   Tue Nov 1 06:21:18 2016 +0100

    scripts: Add support for .buildinfo files
    
    The .buildinfo files are a new type of control files, similar to
    the .changes files, meant to describe the environment of a build
    and its artifacts. They are meant to be added to the Debian archive
    to allow independent parties to reproduce a build and verify the
    result.
    
    Specifications for .buildinfo are available at:
    <https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification>
    
    This patch adds support for .buildinfo files in Dpkg::Control,
    adds new .buildinfo fields to Dpkg::Control::Fields, a new
    builtin-system-build-paths Dpkg::Vendor hook, and adds a new script
    named dpkg-genbuildinfo, that will now be called by dpkg-buildpackage
    before generating the .changes file.
    
    [ntyni@debian.org: small changes. ]
    
    Closes: #138409
    Based-on-patch-by: Jérémy Bobbio <lunar@debian.org>
    Signed-off-by: Guillem Jover <guillem@debian.org>

diff --git a/debian/changelog b/debian/changelog
index 1143bd9..e924ff7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -62,6 +62,10 @@ dpkg (1.18.11) UNRELEASED; urgency=medium
     when printing to STDOUT (via -O).
   * Do not add architectures to .changes Architecture field for artifacts
     that are not a .deb or .udeb in dpkg-genchanges.
+  * Add support for .buildinfo files:
+    - Add new dpkg-genbuildinfo command.
+    - Hook it into the dpkg-buildpackage machinery.
+    Based on a patch by Jérémy Bobbio <lunar@debian.org>. Closes: #138409
   * Architecture support:
     - Add support for AIX operating system.
     - Add a version pseudo-field to the arch tables.
@@ -113,6 +117,9 @@ dpkg (1.18.11) UNRELEASED; urgency=medium
       instead of FileHandle.
     - Add new Dpkg::PROGTAR variable to store GNU tar command name.
     - Add new Dpkg::PROGMAKE variable to store GNU make command name.
+    - Add new CTRL_FILE_BUILDINFO type to Dpkg::Control.
+    - Add new .buildinfo fields to Dpkg::Control::Fields.
+    - Add new builtin-system-build-paths Dpkg::Vendor hook.
   * Packaging:
     - Add liblocale-gettext-perl to libdpkg-perl Recommends.
     - Wrap and document dependency relationships.

Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to 138409-submitter@bugs.debian.org. (Thu, 03 Nov 2016 05:24:03 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Thu, 03 Nov 2016 11:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 03 Nov 2016 11:03:03 GMT) (full text, mbox, link).

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

Guillem,

> Control: tag 138409 pending

Firstly, this is really great to see; thanks to you (and everyone else)
for your work on this.

This is just a quick message to query whether the applied patch fixes
the "duplicate Installed-Build-Depends" issue that I raised a week or
so ago?

If not, am very happy to file a bug so it gets captured. No point
uploading with known issues, after all.


Regards,

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Fri, 04 Nov 2016 02:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 04 Nov 2016 02:33:03 GMT) (full text, mbox, link).

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

Hi!

On Thu, 2016-11-03 at 11:01:28 +0000, Chris Lamb wrote:
> > Control: tag 138409 pending
> 
> Firstly, this is really great to see; thanks to you (and everyone else)
> for your work on this.

No problem, it took probably longer than it should have though. :/

> This is just a quick message to query whether the applied patch fixes
> the "duplicate Installed-Build-Depends" issue that I raised a week or
> so ago?

I should have fixed this in principle, but out of code staring, I
didn't try to reproduce it.

> If not, am very happy to file a bug so it gets captured. No point
> uploading with known issues, after all.

If you notice this is still a problem, please do file a bug!

Thanks,
Guillem

Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 04 Nov 2016 10:51:03 GMT) (full text, mbox, link).

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

Guillem Jover wrote:

> If you notice this is still a problem, please do file a bug!

Indeed I can still reproduce it:

 https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/redis_3.2.5-1_amd64.buildinfo
 https://gist.github.com/lamby/214906fbfa8814acc8b920b800977216/raw

Note that this is using dpkg-dev "1.18.10.0~reproducible1" (hey, these
.buildinfo files are rather useful…).


Regards,

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

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Sat, 05 Nov 2016 02:54:03 GMT) (full text, mbox, link).

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 05 Nov 2016 02:54:03 GMT) (full text, mbox, link).

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

Hi!

On Fri, 2016-11-04 at 10:47:07 +0000, Chris Lamb wrote:
> Guillem Jover wrote:
> > If you notice this is still a problem, please do file a bug!
> 
> Indeed I can still reproduce it:
> 
>  https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/redis_3.2.5-1_amd64.buildinfo
>  https://gist.github.com/lamby/214906fbfa8814acc8b920b800977216/raw
> 
> Note that this is using dpkg-dev "1.18.10.0~reproducible1" (hey, these
> .buildinfo files are rather useful…).

I tried building that package with the fix (from git master) enabled and
disabled and I see the buildinfo w/o and w/ the duped entry in the field.
So this confirms the fix works. :)

Thanks,
Guillem

Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Sun, 06 Nov 2016 03:36:03 GMT) (full text, mbox, link).

Notification sent to Randolph Chung <tausq@debian.org>:
Bug acknowledged by developer. (Sun, 06 Nov 2016 03:36:03 GMT) (full text, mbox, link).

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

Source: dpkg
Source-Version: 1.18.11

We believe that the bug you reported is fixed in the latest version of
dpkg, 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 138409@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg 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: Sun, 06 Nov 2016 03:09:02 +0100
Source: dpkg
Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.11
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description:
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 138409 787980 833964 834584 835149 838877 839905 840293 841117 842004 842187 842230 842845 843248
Changes:
 dpkg (1.18.11) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Make dpkg-maintscript-helper conffile commands more robust. Check that
     conffile pathname arguments are absolute paths and verify version number
     to be valid. Thanks to David Kalnischkies <david@kalnischkies.de>.
   * Add support to dpkg-scanpackages for scanning a single binary file.
     Thanks to Javier Serrano Polo <javier@jasp.net>. Closes: #833964
   * Obsolete dpkg-deb bzip2 and lzma compression methods by emitting errors.
   * Remove obsolete dpkg-deb --old and --new options.
   * Remove obsolete dpkg --print-installation-architecture option.
   * Fix dpkg error messages when parsing md5sum files to include the package
     name affected.
   * Do not emit epochs for unambiguous versions in deb-split package header.
     Regression introduced in dpkg 1.18.0.
   * Make the deb-split(5) generation in dpkg-split reproducible, by using the
     timestamp from SOURCE_DATE_EPOCH.
   * Generate reproducible file modes for the .deb control member contents.
     Closes: #787980
   * Switch from non-freeing malloc to m_malloc on statdb slurping.
   * Switch from non-freeing malloc to m_malloc for invoke hooks.
   * Always reset the package in-core database when shutting down the package
     database journal.
   * Do not crash if we pass a NULL cip argument to setaction() in libdpkg.
   * Shutdown the package database journal in dpkg --get-selections.
   * Fix (deactivated) dpkg --command-fd to initialize and reset the files
     database on each action.
   * Implement source stanza substvars prefixed with S: in dpkg-gencontrol.
     These auto-generated variables map each source stanza field into an
     output substvar prefixed with “S:”.
   * Make dpkg-source generate reproducible source packages when run
     standalone, by honoring SOURCE_DATE_EPOCH.
   * Fix several short-lived memory leaks in update-alternatives.
     Reported by Helmut Grohne <helmut@subdivi.de>.
   * Only set the error context message in libdpkg if it has been formatted
     correctly.
   * Return error in error_context_errmsg_format() only if the error message
     gets truncated. In case we have to use the emergency buffer because the
     previous vasprintf() call failed, we should only return an error code if
     the vsnprintf() call on the emergency buffer truncates the output.
   * Fix free() on uninitialized pointer in error_context_errmsg_format() in
     libdpkg. Regression introduced in dpkg 1.18.7. Closes: #842004
   * Move C++ support code into its own file.
   * Add replacement new and delete array operators to C++ support code.
   * Implement local abi::__cxa_pure_virtual. When using g++ if we provide our
     version of this function we can avoid the dependency on either libstdc++
     or libsup++.
   * Include missing <new> for new and delete operator declarations.
   * Do not log nor print duplicate dpkg removal action. We print
     “Removing <package> (<version>)” lines and log remove action twice
     when purging a package from frontends, because they usually first call
     --remove and then --purge sequentially. When purging a package which is
     already in config-files (i.e. it has been removed before), do not print
     nor log the remove action.
   * Remove default «.» from @INC before loading perl modules in perl code.
     Fixes CVE-2016-1238.
   * Give more information on --set-selections warnings. Closes: #842230
   * Add new DEB_*_ARCH_ABI and DEB_*_ARCH_LIBC variables to dpkg-architecture
     and architecture.mk Makefile fragment.
   * Do substvar instantiation just once in dpkg-gencontrol.
   * Fix dpkg-gencontrol to not update the files list file (debian/files)
     when printing to STDOUT (via -O).
   * Do not add architectures to .changes Architecture field for artifacts
     that are not a .deb or .udeb in dpkg-genchanges.
   * Add support for .buildinfo files:
     - Add new dpkg-genbuildinfo command.
     - Hook it into the dpkg-buildpackage machinery.
     Based on a patch by Jérémy Bobbio <lunar@debian.org>. Closes: #138409
   * Enable dpkg-buildpackage -Jauto by default. Closes: #842845
   * Fix dpkg to not fail when removing non-existent backup files on read-only
     filesystems. Closes: #838877
   * Handle PIE enabled by default in gcc. On achitectures where gcc enables
     them by default, stop setting -fPIE and -pie, and set -fno-PIE and
     -no-pie when disabling «pie» via gcc specs files, so that we do not
     emit them on situations where it would be inappropriate. Closes: #835149
     Based on a patch by Bálint Réczey <balint@balintreczey.hu>.
   * Architecture support:
     - Add support for AIX operating system.
     - Add a version pseudo-field to the arch tables.
     - Internally represent Debian architectures as quadruplets.
   * Portability:
     - Cast off_t variables to intmax_t when printing them with "%jd".
     - Add missing <string.h> include in libdpkg.
     - Cast strlen() return value to ssize_t to match write() return type.
     - Use underscore-prefixed system preprocessor symbols instead of namespace
       polluting ones (such as “linux”, “OPENBSD” or “hpux”).
     - Handle _POSIX_PRIORITY_SCHEDULING being defined to -1 or 0 in
       start-stop-daemon. This affects Mac OS X.
     - On FreeBSD return STATUS_UNKNOWN instead of false in start-stop-daemon
       do_procinit().
     - Port start-stop-daemon process handling to Mac OS X.
       Based on a patch by Mo McRoberts <mo@nevali.net>.
     - Port start-stop-daemon process handling to AIX.
     - Fix lookup by name on update-alternatives --config. The code was wrong
       and not working at least on Mac OS X, making the test suite to fail.
     - Only use gzip --rsyncable in Dpkg::Compression on Debian and hopefully
       derivatives, by using perl's $Config{cf_by} variable to key on. The
       Debian-specific --rsyncable option should have never been accepted for
       use in dpkg to begin with.
     - Use our own dpkg_ar_hdr struct instead of relying on the system
       ar_hdr struct, as the ar format is not standardized and does vary
       across systems, for example on AIX.
     - Add <sys/sysmacros.h> on AIX for major() and minor().
     - Add missing <errno.h> in libcompat.
     - Include libcompat getopt module when we need getopt_long.
     - Disable gettext support in libcompat getopt module. We do not carry
       translations for this module, and it makes it pull libintl for programs
       that might not use it otherwise.
   * Perl modules:
     - Obsolete Source-Version substvar in Dpkg::Substvars by emitting errors.
     - Rework keyring hooks in Dpkg::Vendor. Deprecate the keyrings hook, and
       add package-keyrings, archive-keyrings and archive-keyrings-historic
       hooks. Prompted by Johannes Schauer <josch@debian.org>.
     - Make the Dpkg::Substavars parse() method return the number of substvars
       parsed.
     - Add new set_field_substvars() method to Dpkg::Substvars.
     - Fix reproducible source package support in Dpkg::Source::Archive, by
       sorting the tar contents with --sort=name.
     - Prefix private Dpkg::Source::Package::* functions with _.
     - Defer filehandle closures in Dpkg::IPC::spawn() to avoid double-close.
       Closes: #839905, #840293
     - Always map the build type to the shortest string form in
       Dpkg::Build::Type::get_build_options_from_type().
     - Change Dpkg::Compression::FileHandle to inherit directly from IO::File
       instead of FileHandle.
     - Add new Dpkg::PROGTAR variable to store GNU tar command name.
     - Add new Dpkg::PROGMAKE variable to store GNU make command name.
     - Add new CTRL_FILE_BUILDINFO type to Dpkg::Control.
     - Add new .buildinfo fields to Dpkg::Control::Fields.
     - Add new builtin-system-build-paths Dpkg::Vendor hook.
     - Cope gracefully with changelogs missing a timestamp trailer.
       Based on a patch by Ian Jackson <ijackson@chiark.greenend.org.uk>.
       Regression introduced in dpkg 1.18.8. Closes: #843248
   * Packaging:
     - Add liblocale-gettext-perl to libdpkg-perl Recommends.
     - Wrap and document dependency relationships.
     - Remove obsolete dependency relationships, since Debian oldstable.
     - Remove update-alternatives, dpkg-divert and dpkg-statoverride
       compatibility symlinks, again.
     - Use perl:Depends via dh_perl instead of a hardcoded perl in Depends.
     - Add perl:Depends to dpkg-dev Depends.
     - Remove unused dh_strip from binary_indep target.
     - Remove ancient upgrade code from maintainer scripts (before 1.15.x).
     - Stop compressing the dpkg.deb package with gzip.
     - Move dpkg to be the first binary package stanza in debian/control, as
       debhelper assigns special meaning by considering it the main package.
     - Set MAKEFLAGS to -jN from parallel=N in DEB_BUILD_OPTIONS.
   * Documentation:
     - Update custom changelog parser API support status in README.api.
     - Fix typos in docs and man pages. Thanks to Jakub Wilk <jwilk@debian.org>
       Closes: #834584
     - Fix formatting in SOURCE_DATE_EPOCH description in dpkg-deb(5).
     - Improve dpkg-deb --build arguments documentation in dpkg-deb(1).
       Prompted by Johannes Schauer <josch@debian.org>.
     - Document the .changes filename that dpkg-buildpackage generates in
       dpkg-buildpackage(1). Prompted by Johannes Schauer <josch@debian.org>.
     - Add basic maintainer script man pages: deb-postinst(5), deb-postrm(5),
       deb-preinst(5) and deb-prerm(5).
     - Add new deb-src-files(5) man page.
       Prompted by Johannes Schauer <josch@debian.org>.
     - Add man page references to other binary control files in dpkg(1).
     - Add version when "new" substvars were introduced in deb-substvars(5).
     - Switch deb-triggers(5) types into a proper list.
     - Itemize --log format entries in dpkg(1).
     - Turn the update-alternatives(1) --query example item into a sub-section.
     - Turn the Multi-Arch values into a list in deb-control(5).
     - Improve user-defined field export marker documentation in
       deb-src-control(5); clarify that X can be followed by zero or more
       (instead of one or more) letters and turn the items into a proper list.
     - Generate the man pages at build time. This makes it possible to process
       them and update several variable strings such as system and package
       pathnames, the release date and the dpkg suite version. And makes it
       possible to use UTF-8 in the source and convert to the more conservative
       groff escape sequences on the output.
     - Switch from groff escape sequences to UTF-8 in man pages sources.
     - Disable hyphenation in man pages globally, because it performs very
       poorly on many technical terms.
     - Append the German man pages addendum at the end of the translation,
       instead of assuming that every page has the SEE ALSO section.
     - Explicitly mention that Dpkg::Checksums::add_from_file() is used to
       verify digests too. Prompted by Johannes Schauer <josch@debian.org>.
     - Document the behavior for consecutive calls to Dpkg perl module parse()
       methods. Prompted by Johannes Schauer <josch@debian.org>.
     - Document obsolete functions in Dpkg::Conf.
   * Test suite:
     - Make test main function a TEST_ENTRY macro. This avoids confusing
       coverage programs, as the file that actually contains the main function
       is the test itself.
     - Rename test suite commands to be prefixed with «c-» instead of «t-».
     - Add new dpkg-source functional tests.
     - Add new dpkg-buildpackage functional tests.
     - Add an initial functional test suite for dpkg-deb and dpkg-split.
     - Skip the involved tests if IO::String is missing.
     - Add new unit test for libdpkg error handling.
     - Delete MAKEFLAGS environment variable when testing make invocations.
     - Pass -q to grep command to suppress matched output in pod-coverage.t.
     - Ignore POD coverage for partially private modules.
   * Build system:
     - Add support for profiling perl modules.
     - Clean up compiler and linker automatic flag usage in configure.
     - Fix the __progname check to avoid the optimizer discarding the symbol.
     - Fix M4sh/Autoconf coding style. Add a new section to coding-style.txt
       describing M4sh/Autoconf.
     - Disable C++ exceptions for dselect.
     - Fix typo in SE Linux library detection code, only affecting static
       mode (not used in Debian). Regression introduced in dpkg 1.18.8.
     - Change --with-* option logic to default to check.
     - Disable -Wtautological-constant-out-of-range-compare (for clang).
     - Check the availability of -W<warning> variant instead of -Wno-<warning>.
       As at least gcc and clang do not warn on -Wno-* warning flags, only
       when some unrelated warning needs to be emitted.
     - Bump po4a version to 0.43 (we are using --porefs wrap option).
     - Add support for running the test suite in parallel.
     - Specify exec argument for TAP::Harness to gracefully handle non-perl
       executables with older versions of the module.
     - Require libselinux 2.0.99 for baseline API, remove static linking
       support, use pkg-config unconditionally, and perform refinement checks
       only if available.
     - Check for the required minimal perl version.
     - Use builddir instead of CURDIR in man Makefile.am.
     - Use cp with -R instead of -r (the former is more portable and not
       marked as deprecated by POSIX).
     - Print an actual newline instead of a literal \n in lcov output.
     - Do not honor DPKG_DATADIR on the installed Dpkg module.
     - Pass --as-needed to the linker for dselect to avoid libstdc++ dependency.
       Which makes of dselect the only front-end not pulling the C++ run-time.
 .
   [ Updated programs translations ]
   * Dutch (Frans Spiesschaert). Closes: #841117
   * German (Sven Joachim).
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated man pages translations ]
   * Dutch (Frans Spiesschaert). Closes: #842187
   * German (Helge Kreutzmann).
Checksums-Sha1:
 c0006dfb6ea551f7fee12cf5c861e34e1ac3c40f 2000 dpkg_1.18.11.dsc
 1e339b1b5a61d6fc0867c457ebda84bb11d6a8b6 4467908 dpkg_1.18.11.tar.xz
Checksums-Sha256:
 bed73d87abe1d49487b63697cbccd040a70876c31d31e3cb51530261ba37a6a3 2000 dpkg_1.18.11.dsc
 06df357a9bcc30f84c070fc8a50523ec7197a1ddec44300cf1072fabcaa4156b 4467908 dpkg_1.18.11.tar.xz
Files:
 b52c36de9ef0f54a52c5bc77f43e12e4 2000 admin required dpkg_1.18.11.dsc
 913b26386a4afdee1d54a490c73b09ee 4467908 admin required dpkg_1.18.11.tar.xz

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

iQIcBAEBCgAGBQJYHp8DAAoJELlyvz6krlejlnUQAKWb9h63EOQt6kezR+M+yieR
DwTsACQChxKBmJHLltmlIYiA642GoQp/mne7qbXP436RgHUFOULVCSEBaFBPc4sM
fzyKAMYOKKXc2hKiw/6Hh5HnwMbc2mEq5Gfi+jXm4vLurOV1tdHP4C6YliP2MWWw
6uyx3w5JjF4Dw5Cn1aQcTv3ibGNQajOEDVXfV4j+qmOyxLBXh9Zau5q2odpAuzDy
aXEJ7dSUywa4qJ3DmYVSoyuIMU94esUGDfvNPvuDXRZ0iIMPQoZXR3oavmNheduF
3J/g+WzKSArBnpIMGZ7c5sevl7suyNM0HSScK6cRC6Q79K47PLYD31LmoBpHrXDm
sXMslUX93i3bhUROFZcejptPQvpWHvP4MMfzMu5Ds9mGzbCD95bdAzsiHxAl3FM1
OEi6xy5OA3Mn+bY7RDLXXInw3a/GHLW+WfQK8qO5IlR21EiHp78d/DHagjV94K9s
OPqeyKTHTeUZm6DFx4issALsLkeisPYho8jV84KWS/qKUlbWuvbNHi0BxsUNySMx
R6rwZxl8X+DaBz5Ji8XGcf/WMtprEPCwqOCBcUsTozlzSm3/+h062pecI8ptF536
JcAKbQBn9kvRgI+MXXzLnHu03YKkX/ujfemjK9JC51cKE8NGC6+IU8y0YHFTlsG0
s7R6d3MMDxMzNsaErxed
=3fd2
-----END PGP SIGNATURE-----

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#138409; Package dpkg-dev. (Sun, 06 Nov 2016 08:06:02 GMT) (full text, mbox, link).

Acknowledgement sent to Chris Lamb <lamby@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 06 Nov 2016 08:06:02 GMT) (full text, mbox, link).

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

Hi Guillem,

> I tried building that package with the fix (from git master) enabled and
> disabled and I see the buildinfo w/o and w/ the duped entry in the field.
> So this confirms the fix works. :)

Excellent news. Thanks for checking so rigorously, at the very least this
will save a potential update later; problematic with the upcoming freeze(s).


Regards,

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

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 05 Dec 2016 07:46:41 GMT) (full text, mbox, link).

Bug unarchived. Request was from Don Armstrong <don@debian.org> to control@bugs.debian.org. (Wed, 07 Dec 2016 01:33:16 GMT) (full text, mbox, link).

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 27 Jan 2017 07:51:21 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: Wed May 17 13:43:05 2023; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #138409 dpkg-dev: please add support for .buildinfo files

Debian Bug report logs - #138409
dpkg-dev: please add support for .buildinfo files