Debian Bug report logs - #846564
dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Toggle useless messages

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

From: Andreas Beckmann <anbe@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Fri, 02 Dec 2016 09:58:44 +0100

Package: dpkg
Version: 1.18.15
Severity: serious

Hi,

I just tried to rebuild some packages from non-free. fonts-larabie
builds on amd64 but fails on i386 and armhf. This still worked a month
ago. (building on a amd64 machine in pbuilder chroots, armhf using qemu)

   debian/rules override_dh_builddeb
make[1]: Entering directory '/build/fonts-larabie-20011216'
dh_builddeb -- -Zxz -Sextreme -z9
dpkg-deb: building package 'fonts-larabie-straight' in '../fonts-larabie-straight_20011216-5_all.deb'.
dpkg-deb: building package 'fonts-larabie-deco' in '../fonts-larabie-deco_20011216-5_all.deb'.
dpkg-deb: building package 'fonts-larabie-uncommon' in '../fonts-larabie-uncommon_20011216-5_all.deb'.
dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-straight .. returned exit code 2
dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-deco .. returned exit code 2
dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-uncommon .. returned exit code 2
debian/rules:16: recipe for target 'override_dh_builddeb' failed
make[1]: *** [override_dh_builddeb] Error 1
make[1]: Leaving directory '/build/fonts-larabie-20011216'


Andreas

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

From: Guillem Jover <guillem@debian.org>

To: Andreas Beckmann <anbe@debian.org>, 846564@bugs.debian.org

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Fri, 2 Dec 2016 10:31:58 +0100

Hi!

On Fri, 2016-12-02 at 09:58:44 +0100, Andreas Beckmann wrote:
> Package: dpkg
> Version: 1.18.15
> Severity: serious

> I just tried to rebuild some packages from non-free. fonts-larabie
> builds on amd64 but fails on i386 and armhf. This still worked a month
> ago. (building on a amd64 machine in pbuilder chroots, armhf using qemu)
> 
>    debian/rules override_dh_builddeb
> make[1]: Entering directory '/build/fonts-larabie-20011216'
> dh_builddeb -- -Zxz -Sextreme -z9
> dpkg-deb: building package 'fonts-larabie-straight' in '../fonts-larabie-straight_20011216-5_all.deb'.
> dpkg-deb: building package 'fonts-larabie-deco' in '../fonts-larabie-deco_20011216-5_all.deb'.
> dpkg-deb: building package 'fonts-larabie-uncommon' in '../fonts-larabie-uncommon_20011216-5_all.deb'.
> dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
> dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
> dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
> dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-straight .. returned exit code 2
> dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
> dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-deco .. returned exit code 2
> dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory
> dpkg-deb: error: subprocess <compress> from tar -cf returned error exit status 2
> dh_builddeb: dpkg-deb -Zxz -Sextreme -z9 --build debian/fonts-larabie-uncommon .. returned exit code 2
> debian/rules:16: recipe for target 'override_dh_builddeb' failed
> make[1]: *** [override_dh_builddeb] Error 1
> make[1]: Leaving directory '/build/fonts-larabie-20011216'

Right, this was reported the other day on IRC by Mattia Rizzolo. The
combination of -Sextreme -z9 and parallel xz makes this use more than
the available address space. I'll change the code to limit based on
memory available. Although as was mentioned on a thread on d-d, those
settings are pretty unfriendly IMO, even more for memory constrained
arches, but oh well. dpkg should never fail to operate on those
conditions.

Thanks,
Guillem

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

From: Guillem Jover <guillem@debian.org>

To: Andreas Beckmann <anbe@debian.org>, 846564@bugs.debian.org

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 05:25:49 +0100

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

Hi!

On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> Right, this was reported the other day on IRC by Mattia Rizzolo. The
> combination of -Sextreme -z9 and parallel xz makes this use more than
> the available address space. I'll change the code to limit based on
> memory available. Although as was mentioned on a thread on d-d, those
> settings are pretty unfriendly IMO, even more for memory constrained
> arches, but oh well. dpkg should never fail to operate on those
> conditions.

I've got the attached patch now, but I've been unable to test that
specific incarnation as I don't have 32-bit machine with many cores.
And neither are the i386 nor armhf porter boxes. I've just verified
that it does what it is intended by hardcoding the number of threads
to 32 and setting the physical memory limit to 2 GiB. And it reduced
the threads down to 12 when building one of those font packages.

If someone could test this on such 32-bit machine, that would be
appreciated.

Thanks,
Guillem

[0001-libdpkg-Decrease-xz-encoder-threads-to-not-exceed-me.patch (text/x-diff, attachment)]

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

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

To: Guillem Jover <guillem@debian.org>, 846564@bugs.debian.org

Cc: Andreas Beckmann <anbe@debian.org>, Mattia Rizzolo <mattia@debian.org>

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 10:01:27 +0000

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

On Sun, Dec 04, 2016 at 05:25:49AM +0100, Guillem Jover wrote:
> On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> > Right, this was reported the other day on IRC by Mattia Rizzolo. The
> > combination of -Sextreme -z9 and parallel xz makes this use more than
> > the available address space. I'll change the code to limit based on
> > memory available. Although as was mentioned on a thread on d-d, those
> > settings are pretty unfriendly IMO, even more for memory constrained
> > arches, but oh well. dpkg should never fail to operate on those
> > conditions.
> 
> I've got the attached patch now, but I've been unable to test that
> specific incarnation as I don't have 32-bit machine with many cores.
> And neither are the i386 nor armhf porter boxes. I've just verified
> that it does what it is intended by hardcoding the number of threads
> to 32 and setting the physical memory limit to 2 GiB. And it reduced
> the threads down to 12 when building one of those font packages.
> 
> If someone could test this on such 32-bit machine, that would be
> appreciated.

I fear I dont really have the time to test this, but the i386 nodes used
for reproducible builds testing have 10 cores and 36gb ram, plus we have
several quad and octo core armhf systems (with 2-4gb ram).

Maybe Mattia can test that? (and what exactly? Apply the patch here,
sure and then build which package? (for the unlikely case that I'll find
time soon…)


-- 
cheers,
	Holger

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

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

From: Mattia Rizzolo <mattia@debian.org>

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

Cc: Guillem Jover <guillem@debian.org>, 846564@bugs.debian.org, Andreas Beckmann <anbe@debian.org>

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 14:11:57 +0100

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

On Sun, Dec 04, 2016 at 10:01:27AM +0000, Holger Levsen wrote:
> > If someone could test this on such 32-bit machine, that would be
> > appreciated.
> 
> Maybe Mattia can test that? (and what exactly? Apply the patch here,
> sure and then build which package? (for the unlikely case that I'll find
> time soon…)

I can surely find the time to test it.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

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

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

From: Adrian Bunk <bunk@stusta.de>

To: Guillem Jover <guillem@debian.org>, 846564@bugs.debian.org

Cc: Andreas Beckmann <anbe@debian.org>

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 16:07:16 +0200

On Sun, Dec 04, 2016 at 05:25:49AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> > Right, this was reported the other day on IRC by Mattia Rizzolo. The
> > combination of -Sextreme -z9 and parallel xz makes this use more than
> > the available address space. I'll change the code to limit based on
> > memory available. Although as was mentioned on a thread on d-d, those
> > settings are pretty unfriendly IMO, even more for memory constrained
> > arches, but oh well. dpkg should never fail to operate on those
> > conditions.
> 
> I've got the attached patch now, but I've been unable to test that
> specific incarnation as I don't have 32-bit machine with many cores.
> And neither are the i386 nor armhf porter boxes. I've just verified
> that it does what it is intended by hardcoding the number of threads
> to 32 and setting the physical memory limit to 2 GiB. And it reduced
> the threads down to 12 when building one of those font packages.
>...

Your patch won't solve it - the problem is not physical memory.

The problem is that on 32 bit you cannot use more than 2-3 GB
(depending on the architecture) in one process.

#845757 was on a mipsel buildd with 4 cores [1] and 8 GB RAM.

I don't know how much RAM the amd64/i386 buildds have,
but I'd guess more than 4 GB...

A hard upper limit somewhere around 1.5 GB on all 32 bit architectures
(or on all architectures, if that's easier to implement) is required.

(I'd also suggest a MBF for all the packages that mess with the 
 compressor for no good reason - just like the ones using bzip2
 this only causes troubles.)

> Thanks,
> Guillem

cu
Adrian
 
[1] 4x 674 MiB with -9 > 2 GB limit on 32bit mips/mipsel

-- 

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

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

From: Guillem Jover <guillem@debian.org>

To: Adrian Bunk <bunk@stusta.de>, 846564@bugs.debian.org

Cc: Andreas Beckmann <anbe@debian.org>

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 17:20:09 +0100

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

On Sun, 2016-12-04 at 16:07:16 +0200, Adrian Bunk wrote:
> On Sun, Dec 04, 2016 at 05:25:49AM +0100, Guillem Jover wrote:
> > On Fri, 2016-12-02 at 10:31:58 +0100, Guillem Jover wrote:
> > > Right, this was reported the other day on IRC by Mattia Rizzolo. The
> > > combination of -Sextreme -z9 and parallel xz makes this use more than
> > > the available address space. I'll change the code to limit based on
> > > memory available. Although as was mentioned on a thread on d-d, those
> > > settings are pretty unfriendly IMO, even more for memory constrained
> > > arches, but oh well. dpkg should never fail to operate on those
> > > conditions.
> > 
> > I've got the attached patch now, but I've been unable to test that
> > specific incarnation as I don't have 32-bit machine with many cores.
> > And neither are the i386 nor armhf porter boxes. I've just verified
> > that it does what it is intended by hardcoding the number of threads
> > to 32 and setting the physical memory limit to 2 GiB. And it reduced
> > the threads down to 12 when building one of those font packages.

> Your patch won't solve it - the problem is not physical memory.
> 
> The problem is that on 32 bit you cannot use more than 2-3 GB
> (depending on the architecture) in one process.

Right, I'm aware of the distinction, but I guess I was wrongly
assuming the lzma_physmem() function would return (userspace)
addressable physical memory. Checking it now, it seems like not,
as it uses stuff like sysconf(_SC_PHYS_PAGES).

> #845757 was on a mipsel buildd with 4 cores [1] and 8 GB RAM.

Ah, thanks, I'm testing as I write this a new patch I've prepared on
eller.d.o (mipsel) which seems to have the right conditions.

> I don't know how much RAM the amd64/i386 buildds have,
> but I'd guess more than 4 GB...
> 
> A hard upper limit somewhere around 1.5 GB on all 32 bit architectures
> (or on all architectures, if that's easier to implement) is required.

The patch now clamps the physical memory to INTPTR_MAX. So that we both
do not exceed the physical memory available nor the addressable limit.

But I should indeed probably also subtract some space for the rest of
the userland that might be running. I'll do that later today.

> (I'd also suggest a MBF for all the packages that mess with the 
>  compressor for no good reason - just like the ones using bzip2
>  this only causes troubles.)

This has been brought up on d-d some time ago. And many of the
packages affected do not even really benefit from such extreme
settings as the dictionary size is bigger than the actual data
to compress. There's a bug in lintian to report an error on this.

Thanks,
Guillem

[0001-libdpkg-Decrease-xz-encoder-threads-to-not-exceed-me.patch (text/x-diff, attachment)]

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

From: Adrian Bunk <bunk@stusta.de>

To: Guillem Jover <guillem@debian.org>, 846564@bugs.debian.org

Cc: Andreas Beckmann <anbe@debian.org>

Subject: Re: Bug#846564: dpkg-deb: 'compressing tar member: lzma error: Cannot allocate memory' on 32-bit architectures on dpkg-deb -Zxz -Sextreme -z9

Date: Sun, 4 Dec 2016 18:46:42 +0200

On Sun, Dec 04, 2016 at 05:20:09PM +0100, Guillem Jover wrote:
> On Sun, 2016-12-04 at 16:07:16 +0200, Adrian Bunk wrote:
>...
> > I don't know how much RAM the amd64/i386 buildds have,
> > but I'd guess more than 4 GB...
> > 
> > A hard upper limit somewhere around 1.5 GB on all 32 bit architectures
> > (or on all architectures, if that's easier to implement) is required.
> 
> The patch now clamps the physical memory to INTPTR_MAX. So that we both
> do not exceed the physical memory available nor the addressable limit.
> 
> But I should indeed probably also subtract some space for the rest of
> the userland that might be running. I'll do that later today.
>...

It is a bit more complicated.

Clamping to something like 80% of INTPTR_MAX might be good enough
for practical purposes, but technically this limit is not related
to INTPTR_MAX.

Addressable are actually 4 GB.

The problem is that these 4 GB are split between user memory and
kernel lowmem.

On several architectures (e.g. i386, ARM) it is actually a configure 
option of the kernel whether you want 1 GB, 2 GB or 3 GB of user memory
(with accordingly less kernel lowmem).

< 2 GB user memory is unlikely to be a configuration you will see
in practice (especially not on the buildds), so staying some margin
below 2 GB on 32 bit (e.g. 80% of INTPTR_MAX) should work fine in
practice.

cu
Adrian

-- 

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

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

From: Guillem Jover <guillem@debian.org>

To: 846564-submitter@bugs.debian.org

Subject: Bug#846564 in package dpkg marked as pending

Date: Sat, 17 Dec 2016 01:43:19 +0000

Control: tag 846564 pending

Hi!

Bug #846564 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=6801351

---
commit 680135184b16269ef414897ba7bc64b2f51df4c7
Author: Guillem Jover <guillem@debian.org>
Date:   Sun Dec 4 02:35:27 2016 +0100

    libdpkg: Decrease xz encoder threads to not exceed memory limits
    
    Automatically decrease xz encoder threads to try to not exceed available
    memory limits. This should alleviated the insane requirements of memory
    needed on 32-bit architectures with many cores, which results in more
    than the userspace addressable memory, when using settings such as
    -z9 and/or -Sextreme in dpkg-deb.
    
    Closes: #846564

diff --git a/debian/changelog b/debian/changelog
index ef98459..b10957d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,11 @@ dpkg (1.18.16) UNRELEASED; urgency=medium
     by deb-version(5), but the code was letting those through.
   * Use lzma_cputhreads() instead of sysconf(_SC_NPROCESSORS_ONLN) as the
     former is way more portable.
+  * Automatically decrease xz encoder threads to try to not exceed available
+    memory limits. This should alleviated the insane requirements of memory
+    needed on 32-bit architectures with many cores, which results in more
+    than the userspace addressable memory, when using settings such as
+    -z9 and/or -Sextreme in dpkg-deb. Closes: #846564
   * Perl modules:
     - Whitelist DPKG_GENSYMBOLS_CHECK_LEVEL, DPKG_ROOT, DPKG_ADMINDIR and
       DPKG_DATADIR environment variables in Dpkg::Build::Info.

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

From: Guillem Jover <guillem@debian.org>

To: 846564-close@bugs.debian.org

Subject: Bug#846564: fixed in dpkg 1.18.16

Date: Sat, 17 Dec 2016 01:48:43 +0000

Source: dpkg
Source-Version: 1.18.16

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 846564@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: Sat, 17 Dec 2016 00:25:53 +0100
Source: dpkg
Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
Architecture: source
Version: 1.18.16
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: 84434 671074 844701 844955 846395 846564 847220 848378 848379
Changes:
 dpkg (1.18.16) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * Add support for specifying multiple targets on «dpkg-buildpackage -T»
     which will be run successively. Closes: #671074
   * Reject empty upstream versions in C and perl code. These are not permitted
     by deb-version(5), but the code was letting those through.
   * Use lzma_cputhreads() instead of sysconf(_SC_NPROCESSORS_ONLN) as the
     former is way more portable.
   * Automatically decrease xz encoder threads to try to not exceed available
     memory limits. This should alleviated the insane requirements of memory
     needed on 32-bit architectures with many cores, which results in more
     than the userspace addressable memory, when using settings such as
     -z9 and/or -Sextreme in dpkg-deb. Closes: #846564
   * Add new dpkg --validate-<thing> commands to validate the syntax of
     various <thing>s, where the current list is «pkgname», «trigname»,
     «archname» and «version».
   * Use the new dpkg --validate-version command in dpkg-maintscript-helper,
     instead of abusing the --compare-versions command to perform version
     validation. Closes: #844701
   * Allow readlink(2) to return a size smaller than stat(2) in dpkg. Some
     bogus filesystems do not return the actual symlink size in st_size,
     which contradicts POSIX. But allowing the case where the returned size
     is smaller than the one used to allocate memory is harmless, although
     suspect. Let it through, but still print a warning so that users can
     install stuff but are reminded they need to get a fixed filesystem in
     place. This has affected at least ecryptfs in the past and now
     file-based encryption support in ext4 on Android N.
   * Add new dpkg-query virtual field source:Upstream-Version. Closes: #84434
   * Perl modules:
     - Whitelist DPKG_GENSYMBOLS_CHECK_LEVEL, DPKG_ROOT, DPKG_ADMINDIR and
       DPKG_DATADIR environment variables in Dpkg::Build::Info.
   * Documentation:
     - State the current working directory used when running dpkg-buildpackage
       hooks.
     - Add a new ENVIRONMENT section to dpkg-gensymbols(1) and document
       DPKG_GENSYMBOLS_CHECK_LEVEL there.
     - Fix bogus description of --force-confmiss in dpkg(1). Regression
       introduced in 1.16.4. Reported by Sven Joachim <svenjoac@gmx.de>.
       Closes: #846395
     - Update dpkg-parsechangelog parser options. The options specific to
       the changelog parser program did not get updated when the parser got
       switched to be a perl module. Missed in dpkg 1.18.8.
   * Build system:
     - Enable compression libs also in automatic check mode in configure.
     - Honor DPKG_DATADIR again in the installed Dpkg modules. This was an
       explicit public interface, documented in the man page.
 .
   [ Updated programs translations ]
   * Dutch (Frans Spiesschaert). Closes: #848378
   * Simplified Chinese (Zhou Mo). Closes: #844955
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Swedish (Martin Bagge). Closes: #847220
 .
   [ Updated man pages translations ]
   * Dutch (Frans Spiesschaert). Closes: #848379
   * German (Helge Kreutzmann).
Checksums-Sha1:
 e3d512941f09fb28e30fe264698cdc8c349a6e6f 2032 dpkg_1.18.16.dsc
 238330ea73e8b545444e678c820dfe237632d1c5 4498872 dpkg_1.18.16.tar.xz
Checksums-Sha256:
 660dfc799aa67da75157ca6927d2a7c6c5818fe4042f5c6b2c499f3ac12a0259 2032 dpkg_1.18.16.dsc
 4b147ccf8753e02e2bb598263b4a0ec51418d3c30da08776bad32059a7741388 4498872 dpkg_1.18.16.tar.xz
Files:
 9142a5ec2c6d1317081b1528bcdb6feb 2032 admin required dpkg_1.18.16.dsc
 60de677bfe04d4ba8adaa22279363af0 4498872 admin required dpkg_1.18.16.tar.xz

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

iQIzBAEBCgAdFiEETz509DYFDBD1aWV0uXK/PqSuV6MFAlhUl0YACgkQuXK/PqSu
V6NMNRAAnGwgOkqH1RhI1kCbE0g+9PbSFbL6WmqvF1tjP25SMnImE3Rubn5/5RLL
hPJvJWLNCNUqhtKzo+7eAP5vDZLIl+DWnzm1wouaHK+p5yZ32wg/W8NqjWvm4plx
cSncbOdWnNs1TjYtTo0IjCt44gQsxw0RhV3TGVivvTWDrZm52VR//AFjWEXnFquA
PSZ17NLfrnqEqaGE5IjnNQpc7UANzDXLRVwyVBNnOaOypV00UJWFVMDevXs3GwMK
qQhmSutIgPA9rX/V7U5PfvEXkX382P8INSQAFNGI/ezUTjo4iswgE/J5xlydprU3
RbOYHM3UwdifjPvxhUVmw/bhVZw57VJ5sSlXj/k4DIkxQnqZ9NbACCsIRizeP24S
GTI79uV7jH2PXAlSZb3ik5fBNVk6zBT27V3w4FtxPkvbn0PhNRb+ini1sOgvT1zT
kBFEmWLyPSaVIEuMLQoqbgPtfnIPZIRUIMsDu33jtvn+2L/Tgtvvv+N31Mw/zuc5
5ja5M8Hkpn9MnRXZyzTp3lZkXhwan5263GbEshEFAsTJPgssAhhrRzyKJWNMPY7x
wknFKq5020Ye0Imr7rGowVorHCa1JJJmgUp2pimGccwE3Al4NhgmndKkD7qf+tfb
IMyr+BdZYhRwNQYTTVmv6SkmhDsOtN+soDXNC6PakMmBWan3QWo=
=qoqy
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.