Debian Bug report logs - #873937
dpkg: should include information about the used kernel in .buildinfo files

Toggle useless messages

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

From: Holger Levsen <holger@layer-acht.org>

To: submit@bugs.debian.org

Subject: dpkg: should include information about the used kernel in .buildinfo files

Date: Fri, 1 Sep 2017 11:25:11 +0000

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

Source: dpkg
Version: 1.8.24
Severity: wishlist
User: reproducible-builds@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org

Hi Guillem,

during discussing #844431 it became clear, that some information about the
running kernel should be included in .buildinfo files, as this can affect the
build.

For a start, including the output of "uname -s -r -v -m -i -o" (so basically
uname -a without the hostname) would be better than the current status quo,
though it would probably be even nicer to also include a hash of
/proc/config.gz or maybe even the whole thing.

Filing a bug now so that we can discuss the best implementation.

Thanks for maintaining dpkg!


-- 
cheers,
	Holger

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

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

From: Guillem Jover <guillem@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 873937@bugs.debian.org

Subject: Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

Date: Fri, 1 Sep 2017 16:51:55 +0200

Hi!

On Fri, 2017-09-01 at 11:25:11 +0000, Holger Levsen wrote:
> Source: dpkg
> Version: 1.8.24
> Severity: wishlist
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-bugs@lists.alioth.debian.org

> during discussing #844431 it became clear, that some information about the
> running kernel should be included in .buildinfo files, as this can affect the
> build.

It is actually not very clear to me. The examples provided there seem
bogus:

* Any build that relies on the currently running kernel for the
  resulting object is broken, and needs to be fixed. The host kernel
  might/should/will have nothing to do with the build one.
* Builds that embed build kernel information should be fixed to not
  do that, as that information should be irrelevant for the generated
  object.
* Builds breaking on kernel changing the version schema should only
  affect things such as kernel modules or similar, anything else is
  also broken. Any kernel version checks, if at all, should always
  be done at run-time.
* Builds breaking due to disabled functionality in the current running
  kernel should be considered broken. In case of the test suite
  failing, that should be fixed to skip those tests gracefully. In
  case of the build system breaking, that should be reworked to not
  use that functionality (which I'd assume is unportable?).

> For a start, including the output of "uname -s -r -v -m -i -o" (so basically
> uname -a without the hostname) would be better than the current status quo,
> though it would probably be even nicer to also include a hash of
> /proc/config.gz or maybe even the whole thing.

In addition to the above, I'm actually somewhat uncomfortable with this
request, as it looks like a massive privacy leak. Compared to package
lists and versions, which are actually requested by the package being
built and might not have anything to do with the main system this
build was being run on (say a chroot for example), or might get deleted
immediately after the build. The kernel tends to be a system-wide
resource, that even if upgraded does not mean it will be running (until
a reboot).

It's also somewhat common to have custom built kernels, with specific
sets of additional patches, or specific modules/subsystems enabled. The
version also pretty much encodes whether the running kernel is potentially
vulnerable (until the next reboot) which would be a nice way to gather
that information from the .buildinfo files for possible targeted attacks.

So, the information proposed seems to be either redudant, because it's
already part of the Build-Architecture field (-s, -m, -o); a major
privacy leak (-r, -v); or not very helpful for reproducibility, as it
would require the exact hardware to be able to reproduce the objects
(-i).

(Besides POSIX only specifies -m, -n, -r, -s and -v, so using anything
else would be non-portable and a non-starter.)

Given all the above, I'm inclined to just close the report? :)

Thanks,
Guillem

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

From: Holger Levsen <holger@layer-acht.org>

To: 873937@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

Date: Sat, 2 Sep 2017 15:53:53 +0000

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

Hi Guillem,

On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
> > during discussing #844431 it became clear, that some information about the
> > running kernel should be included in .buildinfo files, as this can affect the
> > build.
> 
> It is actually not very clear to me. The examples provided there seem
> bogus:
> 
> * Any build that relies on the currently running kernel for the
>   resulting object is broken, and needs to be fixed. The host kernel
>   might/should/will have nothing to do with the build one.
> * Builds that embed build kernel information should be fixed to not
>   do that, as that information should be irrelevant for the generated
>   object.
> * Builds breaking on kernel changing the version schema should only
>   affect things such as kernel modules or similar, anything else is
>   also broken. Any kernel version checks, if at all, should always
>   be done at run-time.
> * Builds breaking due to disabled functionality in the current running
>   kernel should be considered broken. In case of the test suite
>   failing, that should be fixed to skip those tests gracefully. In
>   case of the build system breaking, that should be reworked to not
>   use that functionality (which I'd assume is unportable?).

good points. (just having information on the kernel *can* be helpful, even
though it *should* not matter, but when it (wrongly) does, it is helpful…)
 
> > For a start, including the output of "uname -s -r -v -m -i -o" (so basically
> > uname -a without the hostname) would be better than the current status quo,
> > though it would probably be even nicer to also include a hash of
> > /proc/config.gz or maybe even the whole thing.
> 
> In addition to the above, I'm actually somewhat uncomfortable with this
> request, as it looks like a massive privacy leak. Compared to package
> lists and versions, which are actually requested by the package being
> built and might not have anything to do with the main system this
> build was being run on (say a chroot for example), or might get deleted
> immediately after the build. The kernel tends to be a system-wide
> resource, that even if upgraded does not mean it will be running (until
> a reboot).

on reflection I agree that the privacy implications are too bad.

[more insightful stuff I cannot disagree with removed.]
 
> Given all the above, I'm inclined to just close the report? :)

Probably, maybe, just please keep it open for another week or two for now, so 
others can chime in…

Thanks!


-- 
cheers,
	Holger

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

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

From: Daniel Kahn Gillmor <dkg@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 873937@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

Date: Wed, 06 Sep 2017 18:00:16 -0400

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

Over on 873937@bugs.debian.org, Holger Levsen wrote:
> on reflection I agree that the privacy implications are too bad.
>
> On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
> [more insightful stuff I cannot disagree with removed.]
>  
>> Given all the above, I'm inclined to just close the report? :)
>
> Probably, maybe, just please keep it open for another week or two for now, so 
> others can chime in…

After reading Guillem's reasoning, i also agree that the report can be
closed.  Thanks for the thoughtful discussion, y'all.

         --dkg

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

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

From: Vagrant Cascadian <vagrant@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 873937@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

Date: Wed, 06 Sep 2017 19:18:33 -0700

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

On 2017-09-02, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
>> > during discussing #844431 it became clear, that some information about the
>> > running kernel should be included in .buildinfo files, as this can affect the
>> > build.
>> 
>> It is actually not very clear to me. The examples provided there seem
>> bogus:
>> 
>> * Any build that relies on the currently running kernel for the
>>   resulting object is broken, and needs to be fixed. The host kernel
>>   might/should/will have nothing to do with the build one.

Agreed.


>> * Builds that embed build kernel information should be fixed to not
>>   do that, as that information should be irrelevant for the generated
>>   object.

Agreed... *but* it can be hard to know that's the reason if you don't
know that the kernel versions differ.

While the .buildinfo file primary purpose is to be able to reproduce a
build, it has a useful secondary role of documenting part of what might
be different about the build environments.


>> > For a start, including the output of "uname -s -r -v -m -i -o" (so basically
>> > uname -a without the hostname) would be better than the current status quo,
>> > though it would probably be even nicer to also include a hash of
>> > /proc/config.gz or maybe even the whole thing.
>> 
>> In addition to the above, I'm actually somewhat uncomfortable with this
>> request, as it looks like a massive privacy leak. Compared to package
>> lists and versions, which are actually requested by the package being
>> built and might not have anything to do with the main system this
>> build was being run on (say a chroot for example), or might get deleted
>> immediately after the build. The kernel tends to be a system-wide
>> resource, that even if upgraded does not mean it will be running (until
>> a reboot).
>
> on reflection I agree that the privacy implications are too bad.

The including the build path also has privacy implications, but it can
be disabled from inclusion in .buildinfo, no?  What about including the
kernel if something like DEB_BUILD_OPTS="buildinfo=+kernel" ?


live well,
  vagrant

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

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

From: Guillem Jover <guillem@debian.org>

To: Vagrant Cascadian <vagrant@debian.org>, 873937@bugs.debian.org

Cc: Holger Levsen <holger@layer-acht.org>, reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#873937: dpkg: should include information about the used kernel in .buildinfo files

Date: Sun, 10 Sep 2017 16:35:31 +0200

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

Hi!

On Wed, 2017-09-06 at 19:18:33 -0700, Vagrant Cascadian wrote:
> On 2017-09-02, Holger Levsen wrote:
> > On Fri, Sep 01, 2017 at 04:51:55PM +0200, Guillem Jover wrote:
> > > In addition to the above, I'm actually somewhat uncomfortable with this
> > > request, as it looks like a massive privacy leak. Compared to package
> > > lists and versions, which are actually requested by the package being
> > > built and might not have anything to do with the main system this
> > > build was being run on (say a chroot for example), or might get deleted
> > > immediately after the build. The kernel tends to be a system-wide
> > > resource, that even if upgraded does not mean it will be running (until
> > > a reboot).
> >
> > on reflection I agree that the privacy implications are too bad.
> 
> The including the build path also has privacy implications, but it can
> be disabled from inclusion in .buildinfo, no?  What about including the
> kernel if something like DEB_BUILD_OPTS="buildinfo=+kernel" ?

Ah good point, yeah, I have no problem with adding this as an option
that is disabled by default. Attached a tentative patch doing that.

Thanks,
Guillem

[0001-dpkg-genbuildinfo-Add-a-new-Build-Kernel-Version-fie.patch (text/x-diff, attachment)]

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

From: Guillem Jover <guillem@debian.org>

To: 873937-submitter@bugs.debian.org

Subject: Bug#873937 in package dpkg marked as pending

Date: Tue, 17 Oct 2017 01:13:09 +0000

Control: tag 873937 pending

Hi!

Bug #873937 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=d920305

---
commit d920305d9deb52fa7c1fb8b0f01bfc31cf517e41
Author: Guillem Jover <guillem@debian.org>
Date:   Sun Sep 10 16:18:15 2017 +0200

    dpkg-genbuildinfo: Add support for new Build-Kernel-Version field
    
    Packages intended to be built in a generic way must never rely on the
    currently running kernel on the build system (an exception could be an
    optimization rebuild using the current system as the reference baseline).
    
    But to be able to detect when a package might not be reproducible due to
    varying kernel information it is still useful to be able to record this
    information. Although that information can be very sensitive.
    
    When the builder has explicitly enabled the Build-Kernel-Version field
    with the new dpkg-genbuildinfo --always-include-kernel option, it will
    get included in the generated .buildinfo file.
    
    Closes: #873937

diff --git a/debian/changelog b/debian/changelog
index 3628281..53a13c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -27,6 +27,9 @@ dpkg (1.19.0) UNRELEASED; urgency=medium
     deb822 format.
   * Remove long obsolete dselect floppy method.
   * Remove traces of non-US support from dselect methods.
+  * Add support for a new Build-Kernel-Version field in .buildinfo files,
+    that can be emitted with a new dpkg-genbuildinfo --always-include-kernel
+    option. Closes: #873937
   * Perl modules:
     - Switch from Dpkg::Util to List::Util, now that the module in the
       new required Perl contains the needed functions.

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

From: Guillem Jover <guillem@debian.org>

To: 873937-close@bugs.debian.org

Subject: Bug#873937: fixed in dpkg 1.19.0

Date: Tue, 17 Oct 2017 01:33:48 +0000

Source: dpkg
Source-Version: 1.19.0

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 873937@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: Tue, 17 Oct 2017 01:51:16 +0200
Source: dpkg
Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.19.0
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: 291320 555743 846405 856396 856547 857852 858579 862924 864509 864882 867133 867327 868356 868800 869236 870221 872309 873937 877521 877688 877929
Changes:
 dpkg (1.19.0) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Remove an unused variable in dpkg-shlibdeps.
     Thanks to Niels Thykier <niels@thykier.net>.
   * Parse start-stop-daemon usernames and groupnames starting with digits in
     -u and -c correctly. Reported by Bodo Eggert <7eggert@online.de>.
   * Cache the result of «dpkg-query --control-path» calls in dpkg-shlibdeps.
     Based on a patch by Niels Thykier <niels@thykier.net>. Closes: #846405
   * Always use the binary version for the .buildinfo filename in
     dpkg-genbuildinfo. Reported by Raphaël Hertzog <hertzog@debian.org>.
     Closes: #869236
   * Fix integer overflow in deb(5) format version parser.
     Closes: #868356
   * Re-enable upstream tar signatures when building source format 1.0.
   * Make dpkg-deb --build sanity check the config maintainer script file type
     and permissions.
   * Add support to dpkg-deb for rootless builds, by setting the owner and
     group for the control.tar entries to root:root, and making it possible to
     do the same for the data.tar entries via the new --root-owner-group option.
     Based on a patch by Niels Thykier <niels@thykier.net>. Closes: #291320
   * Make dpkg-buildpackage error out if --as-root is passed without
     --rules-target.
   * Add support for rootless builds in dpkg-buildpackage by honoring the
     Rules-Requires-Root (R³) field.
   * Add new dpkg-buildflags --query command, which is like --status but in
     deb822 format.
   * Remove long obsolete dselect floppy method.
   * Remove traces of non-US support from dselect methods.
   * Add support for a new Build-Kernel-Version field in .buildinfo files,
     that can be emitted with a new dpkg-genbuildinfo --always-include-kernel
     option. Closes: #873937
   * Make dpkg-genchanges honor substvars in .changes Description field.
     Closes: #856547
   * Add support for source package Description and substvars. This new
     field in the debian/control source stanza will be copied into the .dsc
     file, and will also be used to initialize the new source:Synopsis and
     source:Extended-Description substvars that will be available when
     generating the DEBIAN/control and .changes files. Closes: #555743
   * Add new “future” feature area in dpkg-buildflags:
     - Add new «lfs» feature, to be used instead of the getconf(1) interface
       which cannot support cross-building.
   * Add new buildtools.mk make fragment to support build tools variable
     setup, for both TOOL and TOOL_FOR_BUILD variables. Not included by
     default from default.mk.
   * Make --uniform-compression the new default dpkg-deb behavior. Add support
     for negating the option via --no-uniform-compression.
   * Clarify subprocess error message by shuffling words around.
   * Print the package name on maintainter script errors. Closes: #877521
   * Fix capitalization of Debian in dpkg-deb output messages.
   * Add a policikit file for running update-alternatives via pkexec.
     Propose by Boyuan Yang <073plan@gmail.com>.
   * Perl modules:
     - Switch from Dpkg::Util to List::Util, now that the module in the
       new required Perl contains the needed functions.
     - Add a new "unique_tuple_key" option to Dpkg::Index set_options() to
       set better default "get_key_func" options, which will become the default
       behavior in 1.20.x. Prompted by Johannes Schauer <josch@debian.org>.
     - Mark ppc64 and powerpc as having gcc builtin PIE in Dpkg::Vendor::Debian.
     - Make the Dpkg::Substvars warnings output deterministic.
       Thanks to Chris Lamb <lamby@debian.org>. Closes: #870221
     - Remove unused POSIX module imports.
     - Use Errno module instead of the slow to import POSIX.
     - Remove unused Dpkg::Path from Dpkg::Vendor::Ubuntu.
     - Only load POSIX from Dpkg::Compression::FileHandle if we are going to
       use signal definitions, reducing the load time of many other modules.
     - Only load Dpkg::BuildOptions and Dpkg::Arch from Dpkg::Vendor-specific
       modules if we are going to use them, reducing the load time of many
       other modules.
     - Only load Term::ANSIColor from Dpkg::ErrorHandling if we are going to
       use colors, reducing the load time of many other modules.
     - Move color setup into report_pretty in Dpkg::ErrorHandling.
     - Move printforhelp initialization into usageerr() in Dpkg::ErrorHandling.
     - Avoid many function arguments in Dpkg::Shlibs::SymbolFile parse().
     - Avoid many function arguments in Dselect::Ftp do_connect().
     - Add new Dpkg::Interface::Storable option to disable compression support,
       so that we can load Dpkg::Compression::FileHandle only when enabled.
     - Disable decompression support for Dpkg::Vendor origin files.
     - Move file_lock() function into a new Dpkg::Lock module, to reduce the
       module load chain for several Dpkg modules.
     - Add support for new DPKG_NLS environment variable in Dpkg::Gettext,
       that when set to 0 will disable NLS (i18n) support in the Dpkg modules,
       and reduce the load chain.
     - Disable compression when using the default file in
       Dpkg::Changelog::Parse.
     - Mark all missing CTRL_INDEX_SRC and CTRL_INDEX_PKG fields as allowed
       in Dpkg::Control::FieldsCore.
     - Complete field order for CTRL_PKG_DEB and CTRL_FILE_STATUS types in
       Dpkg::Control::FieldsCore.
     - Switch to use lowercase field names for all internal field name
       handling in Dpkg::Control::FieldsCore, giving a significant speed up.
     - Remove dependency on Dpkg::Checksums from Dpkg::Control::FieldsCore.
     - Do not execute code when importing Dpkg::Control::FieldsCore.
     - Use substr instead of a regex to match the first line characters in
       when parsing control files in Dpkg::Control::HashCore.
     - Merge build flag methods into a single _add_build_flags private method
       in Dpkg::Vendor::Debian.
     - Do not use an intermediate variable in Dpkg::Control::HashCore::Tie
       STORE method.
     - Expect deb822 stanza delimiters more often than OpenPGP Armor Headers
       in Dpkg::Control::HashCore parse method.
     - Optimize trailing space matching on Dpkg::Control::HashCore parse
       method, by trimming it just once at the beginning of the iteration.
     - Optimize trailing space trimming on Dpkg::Control::HashCore parse
       method, by requiring that at least one whitespace is present.
     - Optimize first character matching in Dpkg::Control::HashCore parse
       method, by storing the first character in a variable.
     - Optimize field/value parsing in Dpkg::Control::HashCore parse method,
       by switching from a capturing regex to split() plus a checking regex.
     - Auto-convert binary signatures to OpenPGP ASCII Armor in
       Dpkg::Source::Package when building source packages.
     - Switch Dpkg::Source::Package::V3 modules to use find_command() instead
       of ad-hoc code.
     - Call source format prerequisites Dpkg::Source::Package method if
       present. Addresses: #877688
     - Unify Dpkg::ErrorHandling subprocess errors with the ones from libdpkg.
     - Do not emit a perl warning if gcc or dpkg is not found from Dpkg::Arch,
       the code already handles the commands not being present.
     - Do not unnecessarily require setting the host_arch in Dpkg::Deps.
       Closes: #856396
     - Do not normalize args past a passthrough stop word in Dpkg::Getopt.
       Some commands pass some arguments through to another command, and
       those must not be normalized as that might break their invocation.
       Reported by Helmut Grohne <helmut@subdivi.de>.
   * Documentation:
     - Document currently accepted syntax for changelogs in deb-changelog(5).
       Closes: #858579
     - Mark source:Version substvar in bold in deb-substvars(5).
     - Clarify behavior for dpkg-maintscript-helper. Closes: #857852
     - Use <command-string> instead of <command> for -c argument value in
       dpkg-architecture(1). Reported by Johannes Schauer <josch@debian.org>.
     - Itemize the CTRL_* constants in the Dpkg::Index POD.
     - Update buildinfo information in dpkg-buildpackage man page to match
       the current implementation.
     - Add all source files to POTFILES.in files.
     - Move deb-version man page to section 7.
     - Remove reference to obsolete dpkg-cross(1).
     - Sort control field export markers by tool order in deb-src-control(5).
     - Document Package-Type and Enhances fields in deb-control(5).
     - Write the actual glyphs used to delimit dependency restrictions in
       deb-src-control(5).
     - Move Package-Type description just after the Package field in
       deb-src-control(5).
     - Move udeb-specific fields to the end of the list of fields in
       deb-src-control(5), and mention these are really udeb-specific.
     - Document that dependency fields in binary stanza can have restrictions
       in deb-src-control(5).
     - Clarify that the Testsuite field is comma-separarted.
     - Fix update-alternatives man page section in alternatives/README file
       reference. Closes: #872309
     - Use correct name for archname validator value in dpkg(1) man page.
       Reported by Niels Thykier <niels@thykier.net.
     - Add new deb-src-rules(5) man page.
     - Document that trailing commas are valid in debian/control dependency
       fields, which get stripped when generating output files.
       Prompted by Mattia Rizzolo <mattia@debian.org>.
     - Clarify that sanitize options should not be used for production builds.
     - Remove recommendation to use Pre-Depends for trigger directives from
       deb-triggers(5). Closes: #864882
     - Add new rootless build experimental draft specification.
       Initial proposal by Niels Thykier <niels@thykier.net>, wording fixes
       and spec clarifications by Guillem Jover <guillem@debian.org>.
     - Fix several function signature documentation.
   * Code internals:
     - Switch perl code to use -> operator for function variables.
     - Switch perl code from split() with /\s+/ to ' '.
   * Build system:
     - Require Perl 5.20.2, the version in Debian oldstable (jessie).
     - Use new gcc-7 -Wrestrict and -Wshift-negative-value warnings if
       available.
     - Do not override the default DEPENDENCIES for libdpkg, extend it instead.
     - Install perl man pages in section 3perl.
   * Packaging:
     - Remove preinst maintainer scripts for dselect and dpkg-dev, for an
       ancient /usr/share/doc symlink to directory switch. Closes: #867327
     - Remove now unused libio-string-perl Build-Depends, and versioned
       dpkg-dev as we do not use build profiles any more.
     - Set Rules-Requires-Root field to no.
     - Do not set redundant source compression to xz.
     - Bump Standards-Version to 4.1.0 (no changes needed).
     - Switch to debhelper compatibility level 10.
     - Split alternatives logrotate into its own configuration file to help
       downstreams and derivatives.
     - Remove ancient code recompressing the alternatives database backups
       from xz to gzip in the dpkg daily cron job.
     - Remove Replaces and Breaks for ancient transitions.
     - Remove workaround for ancient gcc lacking stackprotectorstrong support.
     - Remove maintainer script code to handle downgrades to pre-triggers and
       pre-multiarch dpkg versions.
     - Remove alternative logs when purging dpkg (!?).
     - Add support for DPKG_ROOT in dpkg maintainer scripts.
     - Add git and bzr to libdpkg-perl Suggests. Closes: #877688
   * Test suite:
     - Enable perlcritic Documentation::RequirePodSections and
       Miscellanea::ProhibitTies.
     - Disable perlcritic ValuesAndExpressions::ProhibitEscapedCharacter.
     - Add a new all_perl_modules function to Test::Dpkg.
     - Add a new module-version unit test to check that module $VERSION
       matches the newest entry in the CHANGES section.
     - Use Module::Metadata instead of grepping for $VERSION in pod-coverage.
     - Avoid many function arguments in Dpkg_Changelog.t check_options().
     - Add a new unit test for Dpkg::Control::FieldsCore.
     - Switch from IO::String to native open() scalar support.
     - Use UTC0 when setting TZ.
 .
   [ Updated programs translations ]
   * German (Sven Joachim).
   * Italian (Pietro Battiston). Closes: #864509
   * Portuguese (Miguel Figueiredo). Closes: #868800
   * Simplified Chinese (Zhou Mo, Boyuan Yang). Closes: #867133, #877929
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated man pages translations ]
   * Dutch (Frans Spiesschaert). Closes: #862924
   * German (Helge Kreutzmann).
Checksums-Sha1:
 d1062ea0f1e559037f4f83d73a73256bdc790e51 1969 dpkg_1.19.0.dsc
 b48c64c1203dd2f8582c3ceaedd1be2ff26f03ac 4557880 dpkg_1.19.0.tar.xz
 295163cf4170d72c6a3c1106e71648e134720d16 7210 dpkg_1.19.0_amd64.buildinfo
Checksums-Sha256:
 e4d98966ea4d38ef5e1f84a2ffda0e49391fc6a34d4def22c249a726ab6ec662 1969 dpkg_1.19.0.dsc
 3e08b8b7889fdaf7c9ee4e794950a07e1734a3b460694ca9e2aed1ff3653df44 4557880 dpkg_1.19.0.tar.xz
 2232ae18fddd526844b46316311d9ca76104639282d5cb06f912c2a784e82aeb 7210 dpkg_1.19.0_amd64.buildinfo
Files:
 3703cfde8fae1a3788371b35d7c61593 1969 admin required dpkg_1.19.0.dsc
 5ba6ed74d3554605910df8e60ab36e1a 4557880 admin required dpkg_1.19.0.tar.xz
 bf3802b85045097e3fe25ee9fe922d09 7210 admin required dpkg_1.19.0_amd64.buildinfo

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

iQIzBAEBCgAdFiEETz509DYFDBD1aWV0uXK/PqSuV6MFAlnlVO0ACgkQuXK/PqSu
V6MLSQ/9Efd8U2nJLsU+OmSQNhban8lm7MyO4Bty9a+PEvbfMiN/lNOb3LY09Pvg
9wjpgueQWFS3V7QDEtMM1SaHPqC4W/ImJ93uLLck9L+o0Gq+ix2LP+tm2GW96wO3
O9rwMyP1WkoWGoLlb6CGO8VkiQyf8FBCoi4fqEJ7FVvKo2l4gmfVm5NWzbO2fd9A
AAugAdV1XAOVIBJy6c3N/IFf8mlZpB/s0+Vyb6KGuRVGPXTSqVS7ME7bK5C6VaDH
U7L7Yb8h8d21xapZO0Xwv9Yc4Wa/hSXTwFIpFoAdrDy3rB1nx6WLzUQp1dQ28KCg
3jp2J59FO3bFWhsaEasdFNvcDXrTOqs8GmwZQyf1PsKTWZE9Hg6EjnRCXHMlkjMp
czoeLts5KNKhjon678tiZQ8RpLpMmHTq8t0tQBf0eYphVpV5Km2Ky+Ki2o2CgnU6
lBBQZfxvEQLO9L/tkq22noR5d4llySqApo2SFEsnuXn92Cbb78PEz5V2vnfth1rY
ft0al8IJWQqwohJmYsmMxEJ9tl33WURJOaC8WaD80XsG8XpI/mAiUuMrehdrp23u
r4Rp+lkvOccYLw1PrEpbhS9NRfBAssYWYH4SQmcilQUk3p3xEnYARYT+6yawWVR9
WFghmOwqnMFW16JszAvjOTuXpvqYeW11cP9KkAq5tSC7CeZo8cw=
=XynH
-----END PGP SIGNATURE-----

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

From: Holger Levsen <holger@layer-acht.org>

To: 873937@bugs.debian.org

Subject: Re: Bug#873937: in package dpkg marked as pending

Date: Tue, 17 Oct 2017 10:05:53 +0000

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

On Tue, Oct 17, 2017 at 01:13:09AM +0000, Guillem Jover wrote:
> Bug #873937 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=d920305

thank you very much for this (and all your other dpkg work!), Guillem!


-- 
cheers,
	Holger

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

Send a report that this bug log contains spam.