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

Bug #924628 reported by crocea
34
This bug affects 4 people
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Fix Released
Medium
Steve Langasek
Precise
Fix Released
Medium
Steve Langasek

Bug Description

Unpacking libapt-inst1.4:i386 (from .../libapt-inst1.4_0.8.16~exp12ubuntu3_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libapt-inst1.4_0.8.16~exp12ubuntu3_i386.deb (--unpack):
 './usr/share/locale/ar/LC_MESSAGES/libapt-inst1.4.mo' is different from the same file on the system

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/ar/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)

ProblemType: Package
DistroRelease: Ubuntu 12.04
Package: libapt-pkg4.12 0.8.16~exp12ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-9.16-generic 3.2.1
Uname: Linux 3.2.0-9-generic x86_64
ApportVersion: 1.91-0ubuntu1
Architecture: amd64
Date: Tue Jan 31 18:58:28 2012
DpkgTerminalLog:
 Unpacking libapt-pkg4.12 (from .../libapt-pkg4.12_0.8.16~exp12ubuntu3_amd64.deb) ...
 Selecting previously unselected package libapt-pkg4.12:i386.
 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/ar/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system
DuplicateSignature:
 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/ar/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system
ErrorMessage: './usr/share/locale/ar/LC_MESSAGES/libapt-pkg4.12.mo' is different from the same file on the system
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
SourcePackage: apt
Title: 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
UpgradeStatus: Upgraded to precise on 2012-01-13 (18 days ago)

Related branches

Revision history for this message
crocea (crocea) wrote :
tags: removed: need-duplicate-check
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in apt (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael Neuffer (neuffer) wrote :

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.

Revision history for this message
Michael Neuffer (neuffer) wrote :

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)

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Changed in apt (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Steve Langasek (vorlon)
tags: added: multiarch rls-p-tracking
Revision history for this message
Steve Langasek (vorlon) wrote :

$ 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.

Revision history for this message
Michael Neuffer (neuffer) wrote :

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)

Revision history for this message
Colin Watson (cjwatson) wrote :

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 ...

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Adam Conrad (adconrad) wrote :

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.

Revision history for this message
Adam Conrad (adconrad) wrote :

(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)

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Steve Langasek (vorlon)
Changed in apt (Ubuntu Precise):
assignee: nobody → Steve Langasek (vorlon)
Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Revision history for this message
Steve Langasek (vorlon) wrote :

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.

Steve Langasek (vorlon)
Changed in apt (Ubuntu Precise):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in apt (Ubuntu Precise):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.