Bug#509192: pygobject: timestamp skew can cause misbuild with wrong python versions

Colin Watson cjwatson at ubuntu.com
Fri Dec 19 13:48:47 UTC 2008


Package: pygobject
Version: 2.15.4-1
Severity: normal
Tags: patch
User: ubuntu-devel at 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:

<cjwatson at 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 at 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                                       [cjwatson at ubuntu.com]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timestamp.diff
Type: text/x-diff
Size: 1473 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20081219/e598661a/attachment.diff 


More information about the pkg-gnome-maintainers mailing list