python-gobject in hardy-updates on sparc misbuilt only for python2.5

Bug #309674 reported by Colin Watson on 2008-12-19
Affects Status Importance Assigned to Milestone
pygobject (Debian)
Fix Released
pygobject (Ubuntu)

Bug Description

The version of pygobject in hardy-updates on sparc is misbuilt to supply only a python2.5 version. This causes ubiquity to fail to build since python-gtk2 is uninstallable (

The cause of this is timestamp skew in the build; although it currently happens to apply only to sparc, it could affect any other architecture in a future build, and therefore should be fixed before it bites us in a more painful place.

Looking at the pygobject source package in hardy-updates, it includes the following two patches:

<cjwatson@sarantium ~/src/ubuntu/pygobject/pygobject-2.14.2>$ diffstat debian/patches/60_use-python-config-for-includes.patch
 aclocal.m4 | 843 ++++++++++++++++++++++-------------------------------------
 configure | 217 ++++++++------- | 4
 3 files changed, 449 insertions(+), 615 deletions(-)
<cjwatson@sarantium ~/src/ubuntu/pygobject/pygobject-2.14.2>$ diffstat debian/patches/61_dont_use_setwakeupfd.patch
 configure | 62 ----------------------------------------------------------- | 20 -------------------
 2 files changed, 82 deletions(-)

If the second patch happens to be applied sufficiently later (in the next second) than the first, the standard Automake rules to rebuild autotools files when they change will note that aclocal.m4 is older than, and will therefore rerun aclocal and autoconf, and subsequently run ./config.status --recheck. These are run as subprocesses of make and therefore without the PYTHON environment variable that debian/rules passes to configure; as a result, ./config.status picks up the default system python (2.5) rather than the one forced by the PYTHON environment variable (which is 2.4 in the first build pass). You can see the problem in action by comparing these two build logs:

Possible fixes include: (a) regenerate aclocal.m4 in a later patch rather than in 60_use-python-config-for-includes.patch; (b) touch aclocal.m4 and configure after applying patches; (c) set PYTHON when calling make so that even if ./config.status --recheck is run it will produce correct results. The versions of pygobject in intrepid and jaunty do (a) (they contain debian/patches/90_autofoo.patch) and therefore do not suffer from this problem, although in principle they might later if the autotools patch were removed.

I am inclined to recommend approach (c) in both hardy-updates and jaunty, on the basis that it is a more permanent fix.

1. with hardy-updates enabled and installed, test two or more applications that use pygtk: e.g., alacarte, update-manager, system-config-printer-gnome, quodlibet
2. enable hardy-proposed and install the python-gobject package there
3. retest that the above applications continue to work.

This does not test that the python2.4 bindings that have been reintroduced on sparc work correctly - nothing in Ubuntu 8.04 should be using python2.4, really - so we assume that the fact that the python2.4 bindings are again present in the package is sufficient evidence that this is fixed.

Colin Watson (cjwatson) on 2008-12-19
Changed in pygobject:
importance: Undecided → Critical
importance: Undecided → Critical
importance: Critical → High
Colin Watson (cjwatson) wrote :

This is consistently reproducible by editing the apply-patches rule in /usr/share/cdbs/1/rules/ and inserting a 'sleep 2' command just before the end of the for loop.

Colin Watson (cjwatson) wrote :
Loïc Minier (lool) wrote :

I'd recommend implementing (a) as well, or also (d): patch in AM_MAINTAINER_MODE. I'm not too confident in the effect of re-running the autotools, even with PYTHON passed to the make which will do so.

Colin Watson (cjwatson) wrote :

While I haven't tried building it myself, is fine with me. Loïc, can you go ahead and upload this?

Martin Pitt (pitti) wrote :

Why do we need both changes? I like Loic's approach in moving the configure/aclocal.m4 changes to the last patch, since that will fix the bug without introducing any other changes. I don't particularly like a re-running of autoconf tools, since I got bitten too often by that. It would only mean to replace one known trap with a potential new one.

So I recommend (a), and I'd also be fine with (b), but vote against (c) for this SRU.

Loic, why does your debdiff have a changed config.guess/sub? (They are inline, not in the 62_autofoo patch)


Colin Watson (cjwatson) wrote :

config.guess and config.sub are updated automatically by debian/rules. However, for the purposes of building a minimal change, you can avoid this by temporarily moving /usr/share/misc/config.{guess,sub} aside.

Loïc Minier (lool) wrote :

RIght, it's cdbs' unconditional config.guess/.sub update mechanism; I could hand fix the debdiff or workaround the update, but it wouldn't represent the actual source which I'll upload as it will have to be cleaned when building the source (I don't think you can debuild/dpkg-buildpackage with both -S -sa and -nc).

Colin Watson (cjwatson) wrote :

That's why I said that you can avoid it by temporarily moving /usr/share/misc/config.{guess,sub} aside; that way you can 'debuild -S' and it won't change those files.

Loïc Minier (lool) wrote :

So, I did workaround the autoupdate in the attached new debdiff, but be aware that config.sub/.guess will be copied over nevertheless during the build (see debian/rules around line 84), and a subsequent uploader will have to workaround this manually as well.

Loïc Minier (lool) wrote :

For the record, I changed debian/rules in pygobject's packaging SVN repo to backup/restore config.guess and .sub after patching/before unpatching, and these files wont show up in the diff anymore.

Martin Pitt (pitti) wrote :

So both of you have the firm opinion that the debian/rules behaviour change should be done in an SRU? It seems to be a big potential trap to me.

Colin Watson (cjwatson) wrote :

It's just the opposite of a trap; it's a further safety measure. It arranges that, *even if* an autotools update is accidentally run, then everything will still work. The intention is not that an autotools update *should* be run - I agree that that is often risky - but to provide insurance in case it is.

In the event that an autotools update is not run, the debian/rules change has no effect.

Martin Pitt (pitti) wrote :

Ah, thanks for the explanation. Fine for me then.

Changed in pygobject:
status: New → Fix Committed
Martin Pitt (pitti) wrote :

Accepted into hardy-proposed, please test and give feedback here. Please see for documentation how to enable and use -proposed. Thank you in advance!

Martin Pitt (pitti) wrote :

Please fix this in Jaunty soon, too.

Changed in pygobject:
status: New → Triaged
Loïc Minier (lool) wrote :

The problem isn't present in jaunty as there's a separate patch for the autotools update. The PYTHON= robustness change is present in Debian's SVN, but isn't merged yet in jaunty; I think it can wait until our next rebase on Debian, either in jaunty or jaunty+1.

Changed in pygobject:
status: Triaged → Fix Released
Loïc Minier (lool) wrote :

NB: Package built fine on all arches in hardy-proposed.

I don't have a hardy desktop; would be nice if someone with a hardy install would smoketest the binaries.

Steve Langasek (vorlon) on 2009-01-27
description: updated
Steve Beattie (sbeattie) wrote :

Using python-gobject 2.14.2-0ubuntu2 in hardy-proposed I saw no regressions in behavior versus python-gobject 2.14.2-0ubuntu1 in hardy-updates while using update-manager, alacarte, quodibet, or system-config-printer-gnome. Also, the examples in /usr/share/doc/python-gobject/examples behave identically between the two versions.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pygobject - 2.14.2-0ubuntu2

pygobject (2.14.2-0ubuntu2) hardy-proposed; urgency=low

  [ Colin Watson ]
  * Pass PYTHON environment variable to make as well as configure, in case
    timestamp skew causes make to rerun autoconf and ./config.status
    --recheck (LP: #309674).

  [ Loic Minier ]
  * New patch, 62_autofoo, to hold diff against aclocal.m4 and configure
    instead of 60_use-python-config-for-includes and 61_dont_use_setwakeupfd;
    fixes timestamp skew; LP: #309674.

 -- Loic Minier <email address hidden> Fri, 19 Dec 2008 15:59:36 +0100

Changed in pygobject:
status: Fix Committed → Fix Released
Changed in pygobject:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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