Comment 0 for bug 309674

Colin Watson (cjwatson) wrote :

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.