Public bug reported:

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:

<cjwat...@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(-)
<cjwat...@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.

** Affects: pygobject (Ubuntu)
     Importance: High
         Status: New

** Affects: pygobject (Ubuntu Hardy)
     Importance: Critical
         Status: New

** Changed in: pygobject (Ubuntu)
   Importance: Undecided => Critical

** Changed in: pygobject (Ubuntu Hardy)
   Importance: Undecided => Critical

** Changed in: pygobject (Ubuntu)
   Importance: Critical => High

-- 
python-gobject in hardy-updates on sparc misbuilt only for python2.5
https://bugs.launchpad.net/bugs/309674
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to pygobject in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

Reply via email to