gzip -9n sometimes generates a different output file on 64 bit

[Gareth Hart]

When I went to upgrade my computer tonight, the libtasn1-3 2.10-1 package refuses to install, citing that "'./usr/share/doc/libtasn1-3/NEWS.gz' is different from the same file on the system". Both the 32-bit and 64-bit versions of libtasn1-3 break each other and creates an impossible situation, which is now also preventing other packages from installing (different bug) as a consequence.

I am using Precise with the latest updates (11/11/2011) installed.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libtasn1-3 2.10-1
ProcVersionSignature: Ubuntu 3.1.0-2.3-generic 3.1.0
Uname: Linux 3.1.0-2-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.26-0ubuntu1
Architecture: amd64
Date: Fri Nov 11 21:14:19 2011
InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 LANGUAGE=en_GB:en
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: libtasn1-3
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jonathan Thomas (echidnaman)]

As a workaround, sudo rm /usr/share/doc/libtasn1-3/NEWS.gz, sudo apt-get install -f

[Martin Pitt (pitti)]

I can confirm the gzip bug on current amd64 oneiric:

dpkg-deb -x /var/cache/apt/archives/libtasn1-3_2.10-1_i386.deb /tmp/i386

amd64 version:
$ md5sum /usr/share/doc/libtasn1-3/NEWS.gz
ab72644ef4dfcaac1e789c5f7da57fab /usr/share/doc/libtasn1-3/NEWS.gz
i386 version:
$ md5sum /tmp/i386/usr/share/doc/libtasn1-3/NEWS.gz
11d5af6dcae12ac9564ca7a6a2055cbf /tmp/i386/usr/share/doc/libtasn1-3/NEWS.gz

Curiously re-compressing the file on amd64 gives the i386 version to me:
$ gzip -cd /usr/share/doc/libtasn1-3/NEWS.gz | gzip -9n | md5sum -
11d5af6dcae12ac9564ca7a6a2055cbf -

[Martin Pitt (pitti)]

I tried re-compressing this NEWS file (gzip -c9n NEWS |md5sum) under these conditions:

 * on my amd64 precise workstation
 * under lucid/amd64 on the porter box
 * in precise/amd64 dchroot on the porter box
 * in precise/i386 dchroot on the porter box
 * no-change rebuild of libtasn1-3 on my workstation
 * no-change rebuild of libtasn1-3 in my PPA

I'm unable to reproduce the file with the ab72644ef4dfcaac1e789c5f7da57f checksum.

[Martin Pitt (pitti)]

I'll try a no-change precise upload as the next debugging step. If it succeeds, we'll have unbroken precise upgrades, and if not, we at least know that it is reproducible somehow.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libtasn1-3 - 2.10-1build1

---------------
libtasn1-3 (2.10-1build1) precise; urgency=low

  * No-change rebuild to (hopefully) fix unreproducible broken NEWS.gz on
    amd64. (LP: #889303)
 -- Martin Pitt <email address hidden> Mon, 14 Nov 2011 08:41:08 +0100

[Martin Pitt (pitti)]

So that didn't help, still wrong:

$ dpkg-deb -x libtasn1-3_2.10-1build1_amd64.deb x
$ md5sum x/usr/share/doc/libtasn1-3/NEWS.gz
ab72644ef4dfcaac1e789c5f7da57fab x/usr/share/doc/libtasn1-3/NEWS.gz

[Martin Pitt (pitti)]

I fail to see the difference between the builder (allspice) and the osageorange porter box. Both are amd64 machines running the lucid kernel (at least I assume that for allspice), and in both cases we are running a precise chroot on top of it to build the package.

Potential other differences might be the file system in use, in all cases above I was using ext4. But if buildds use something special there, then apparently only the distro builders, not the PPA ones.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libtasn1-3 - 2.10-1ubuntu1

---------------
libtasn1-3 (2.10-1ubuntu1) precise; urgency=low

  * debian/rules: Disable compression of NEWS file for now to unbreak
    upgrades. Debugging the underlying gzip bug is quite hard and will take
    more time than a few hours. (LP: #889303)
 -- Martin Pitt <email address hidden> Mon, 14 Nov 2011 08:59:19 +0100

[Martin Pitt (pitti)]

If bug 871083 really is the same problem, then this isn't limited to 1.4, but also affects 1.3.12. Rolling back gzip thus wouldn't really help here.

[Michael Rawson (michael.rawson)]

So is this now fixed, or what?

[Michael Rawson (michael.rawson)]

Sorry, redirected from another bug (clone, apprently). never mind me. :)