package libapt-pkg4.12 0.8.16~exp12ubuntu3 failed to install/upgrade: './usr/share/locale/ar/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system

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

I guess this is another variation of Bug #871083 "gzip -9n sometimes generates a different output file on different architectures"
which still hasn't been fixed.

Still no update to the broken package..... A recompile with the fixed gzip would most likely do the trick.

Unpacking libapt-pkg4.12:i386 (from .../libapt-pkg4.12_0.8.16~exp12ubuntu3_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libapt-pkg4.12_0.8.16~exp12ubuntu3_i386.deb (--unpack):
 './usr/share/locale/de/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

This is completely unrelated to bug #871083, which is a bug specific to gzip. I haven't investigated this issue yet, but I suspect the apt source strings differ across architectures, causing different translations to be used for each. That's the only explanation I have for .mo files being different on each architecture.

$ diff -u i386.po amd64.po
--- i386.po 2012-03-16 17:55:12.000000000 +0000
+++ amd64.po 2012-03-16 17:55:19.000000000 +0000
@@ -2,7 +2,7 @@
 msgstr ""
 "Project-Id-Version: apt_po\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2012-03-15 18:54+0000\n"
+"POT-Creation-Date: 2012-03-15 18:53+0000\n"
 "PO-Revision-Date: 2006-10-20 21:28+0300\n"
 "Last-Translator: Ossama M. Khayat <email address hidden>\n"
 "Language-Team: Arabic <email address hidden>\n"
$

So the root cause here is that the pot file is being regenerated at build time when it shouldn't be.

The bug still exists with libapt-pkg4.12_0.8.16~exp12ubuntu6

Unpacking libapt-pkg4.12:i386 (from .../libapt-pkg4.12_0.8.16~exp12ubuntu6_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libapt-pkg4.12_0.8.16~exp12ubuntu6_i386.deb (--unpack):
 './usr/share/locale/de/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)

The trick will probably be in keeping Launchpad Translations happy at the same time. Some folks went around a bunch of packages a while back and changed them to generate .pot files at build time in order to ensure that they were up to date ...

fixable by making the .pot target in po/makefile actually know about the source dependencies, and only regenerate when the .pot's out of date. Since the generation is done in ./debian/rules clean which is a prereq for source package generation, that would ensure it's always up to date in the .tar.gz and doesn't have to be rebuilt at package time.

However, apt's po/makefile is a very NIH bit of make. It's probably a bit of work to replace this with the standard gettextize boilerplate.

It might be fair to note that "debian/rules clean" isn't, actually, a requirement for generating source packages and if someone does a -S -nc build of apt, this will fail subtly (ie: in the multiarch case) later, so you may need to belt-and-suspenders your "fix it properly in distclean" thing with some way to fail the build if you detect that things weren't cleaned. Which could be hard.

That said, due to apt's distclean also being required to do things like update autoconf and version macros all over the source, and other such fun, it might be fair to assume that no one would upload apt with a -nc upload.

Still, up until this proposed change, an -nc upload (from pristine source) wouldn't produce different results post-build than a normal upload. Food for thought, if this makes apt one of the few packages that absolutely MUST be cleaned pre-source-upload.

(I still think conflating "debian/rules clean" with all the things that "make distclean" does is terribly wrong, and the right fix is probably making apt upstream no longer native, so there's a clear distinction between "distcleaning an upstream release" and "cleaning a debian source package", but that's clearly not a five minute fix, and it's also likely to be contentious)

David, I see that you have a branch linked for this bug. The solution you propose seems to have a couple of issues:

 - The .pot generation appears to no longer happen as part of the source build, ever. This means that the .pot file may be out of date in the source package, impacting launchpad translation imports.
 - The header is being dropped from the .pot file to avoid introducing skew. But the header provides important information to translators about whether there's a newer .pot that needs (msg)merged for their translation.

What we want here is for the .pot update target to be called in clean, but with proper make dependencies so that it's only *actually* regenerated when there have been source changes. This is easily done when using the standard gettextize makefiles, but is going to be somewhat trickier with these home-grown makefiles for handling multiple domains.

Bah, nevermind; the upstream gettextize does this:

# This rule has no dependencies: we don't need to update $(DOMAIN).pot at
# every "make" invocation, only create it when it is missing.
# Only "make $(DOMAIN).pot-update" or "make dist" will force an update.
$(srcdir)/$(DOMAIN).pot:
        $(MAKE) $(DOMAIN).pot-update

So since we're not using 'make dist', but instead 'make distclean', this doesn't actually appear to provide much advantage.

And reading David's diff more closely, I see that the header is dropped only from the auto-split per-domain .pot files and not from apt-all.pot. That makes sense to me.

So the only issue, I think, is that this update-pot target isn't being called as part of the source package generation when it really ought to be.

I'll propose a branch to address this.

This bug was fixed in the package apt - 0.8.16~exp12ubuntu7

---------------
apt (0.8.16~exp12ubuntu7) precise; urgency=low

  * clean up obsolete conffile /etc/apt/apt.conf.d/01ubuntu, which was
    dropped in maverick.
  * Build-depend on gettext:any for cross-building support.
  * Don't treat build-depends-indep as cross-build-dependencies; we should
    always install the host arch versions. LP: #968828.
  * Makefile, po/makefile: make sure our pot generation datestamp doesn't
    change at build time, since this makes translations fail to be
    co-installable with multiarch. Based on a patch by David Kalnischkies.
    Closes: #659333, LP: #924628.
  * For cross-build-dependencies, Architecture: all packages should be
    treated as implicitly Multi-Arch: foreign, because either they *are*
    M-A: foreign when used as a build-dependency, or they need to be updated
    to not be Architecture: all; and since cross-build-deps are new
    functionality in apt, we can safely make this change without breaking
    existing systems. Closes: #666772.
 -- Steve Langasek <email address hidden> Thu, 05 Apr 2012 18:00:23 -0700