Package: pygobject
Version: 2.15.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch jaunty

[I originally reported this as https://bugs.launchpad.net/bugs/309674.]

The version of pygobject in Ubuntu hardy-updates on sparc is misbuilt to
supply only a python2.5 version. This causes other packages to fail to
build since python-gtk2 is uninstallable (e.g.
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 and doesn't affect Debian or more recent
versions of Ubuntu right now, it could still show up randomly 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; again, this isn't a problem in current unstable since the
python2.4 build is disabled, but the problem is just dormant, not truly
fixed). 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

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.

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. More recent versions of pygobject 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) for the future, on the basis
that it is a more permanent fix. The attached patch does this. (In fact
it's probably slightly overkill since second and subsequent make calls
won't run ./config.status --recheck again, but I thought overkill was
better than underkill.)

Thanks,

-- 
Colin Watson                                       [cjwat...@ubuntu.com]
  * 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).

diff -u pygobject-2.15.4/debian/rules pygobject-2.15.4/debian/rules
--- pygobject-2.15.4/debian/rules
+++ pygobject-2.15.4/debian/rules
@@ -42,13 +42,13 @@
 
 build-%/build-stamp: build-%/configure-stamp
 	dh_testdir
-	$(MAKE) -C build-$*
-	-$(MAKE) -C build-$* check
+	PYTHON=/usr/bin/python$* $(MAKE) -C build-$*
+	-PYTHON=/usr/bin/python$* $(MAKE) -C build-$* check
 	touch $@
 
 dbg-build-%/build-stamp: dbg-build-%/configure-stamp
 	dh_testdir
-	$(MAKE) -C dbg-build-$*
+	PYTHON=/usr/bin/python$*-dbg $(MAKE) -C dbg-build-$*
 	touch $@
 
 build: $(PYVERS:%=build-%/build-stamp) $(PYVERS:%=dbg-build-%/build-stamp)
@@ -61,12 +61,12 @@
 install-%: build-%/build-stamp
 	dh_testdir
 	dh_testroot
-	$(MAKE) -C build-$* install DESTDIR=$(CURDIR)/debian/python-gobject-dev
+	PYTHON=/usr/bin/python$* $(MAKE) -C build-$* install DESTDIR=$(CURDIR)/debian/python-gobject-dev
 
 dbg-install-%: dbg-build-%/build-stamp
 	dh_testdir
 	dh_testroot
-	$(MAKE) -C dbg-build-$* install DESTDIR=$(CURDIR)/debian/python-gobject-dbg
+	PYTHON=/usr/bin/python$*-dbg $(MAKE) -C dbg-build-$* install DESTDIR=$(CURDIR)/debian/python-gobject-dbg
 	find debian/python-gobject-dbg ! -type d ! \( -name '*.so' -o -name '*.so.*' \) -print0 | xargs -0 rm -f
 	find debian/python-gobject-dbg -depth -empty -exec rmdir {} \;
 

Reply via email to