python-gobject in hardy-updates on sparc misbuilt only for python2.5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pygobject (Debian) |
Fix Released
|
Unknown
|
|||
pygobject (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Hardy |
Fix Released
|
Critical
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Unassigned |
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 (http://
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/
aclocal.m4 | 843 +++++++
configure | 217 ++++++++-------
configure.ac | 4
3 files changed, 449 insertions(+), 615 deletions(-)
<cjwatson@sarantium ~/src/ubuntu/
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://
http://
Possible fixes include: (a) regenerate aclocal.m4 in a later patch rather than in 60_use-
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-
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.
Related branches
Changed in pygobject: | |
importance: | Undecided → Critical |
importance: | Undecided → Critical |
importance: | Critical → High |
description: | updated |
Changed in pygobject: | |
status: | Unknown → Fix Released |
This is consistently reproducible by editing the apply-patches rule in /usr/share/ cdbs/1/ rules/simple- patchsys. mk and inserting a 'sleep 2' command just before the end of the for loop.