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 (http://launchpadlibrarian.net/20576122/buildlog_ubuntu-hardy-sparc.ubiquity_1.8.13_FAILEDTOBUILD.txt.gz).
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 ++++++++-------
configure.ac | 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 -----------------------------------------------------------
configure.ac | 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 configure.ac, 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:
http://launchpadlibrarian.net/15910647/buildlog_ubuntu-hardy-i386.pygobject_2.14.2-0ubuntu1_FULLYBUILT.txt.gz
http://launchpadlibrarian.net/15911262/buildlog_ubuntu-hardy-sparc.pygobject_2.14.2-0ubuntu1_FULLYBUILT.txt.gz
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.
TEST CASE:
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.
This is consistently reproducible by editing the apply-patches rule in /usr/share/