After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 382249 - configure on ubuntu edgy fails to find pygtk
configure on ubuntu edgy fails to find pygtk
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: General
Git
Other All
: Normal normal
: 0.10.2
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2006-12-04 13:29 UTC by Richard Boulton
Modified: 2006-12-04 15:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed workaround for bad detection of pygtk on edgy (1001 bytes, patch)
2006-12-04 13:32 UTC, Richard Boulton
none Details | Review
pure python configure.ac pygtk check (1.03 KB, patch)
2006-12-04 15:01 UTC, Edward Hervey
none Details | Review
small text fix (1.02 KB, patch)
2006-12-04 15:04 UTC, Edward Hervey
none Details | Review

Description Richard Boulton 2006-12-04 13:29:19 UTC
Please describe the problem:
ubuntu edgy pacakges contain modules for multiple versions of python in a single packages.  In particular, the pygtk package contains versions for python2.4 and python2.5.  However, the pkg-config file for this package is only able to report the location of the files for a single version of the package, and reports that for python2.5.  The default version of python on most ubuntu edgy systems is python2.4, so this results in a version mismatch if configure believes the pkg-config return value.  This can be worked around for looking for this version mismatch and ignoring the result of pkg-config if it is dubious.

Steps to reproduce:
1. run ./configure on an ubuntu edgy machine, with appropriate packages installed.

Actual results:
Configure reports:

checking for GST... yes
checking for PYGTK... yes
configure: Using pygtk installed in /usr/lib/python2.5/site-packages
checking for pycairo... /usr/lib/python2.5/site-packages/cairo/__init__.py:1: RuntimeWarning: Python C API version mismatch for module cairo._cairo: This Python has API version 1012, module cairo._cairo has version 1013.
  from _cairo import *
found
checking for gtk.glade... not found
configure: error: You need to have python libglade bindings installed


Expected results:
configure should use the version of pygtk installed in /usr/lib/python2.4/site-packages, since this is the version of python in /usr/bin/python.  No version mismatch warning for pycairo should be emitted, and python libglade bindings should be found.

Does this happen every time?
Yes

Other information:
Proposed workaround for configure.ac to be attached shortly.
Comment 1 Richard Boulton 2006-12-04 13:32:35 UTC
Created attachment 77635 [details] [review]
Proposed workaround for bad detection of pygtk on edgy
Comment 2 Edward Hervey 2006-12-04 14:59:54 UTC
I've been thinking more about this, and we have no need whatsoever to know where the modules are installed... as long as we can access them.

Here's a rewritten version of the checks, in python.

Comments are welcome. If it makes sense for everybody, I'll rewrite all the checks for python modules in a similar way.
Comment 3 Edward Hervey 2006-12-04 15:01:12 UTC
Created attachment 77644 [details] [review]
pure python configure.ac pygtk check
Comment 4 Edward Hervey 2006-12-04 15:04:23 UTC
Created attachment 77645 [details] [review]
small text fix

the text in the above patch wasn't correct.
Comment 5 Edward Hervey 2006-12-04 15:48:34 UTC
2006-12-04  Edward Hervey  <edward@fluendo.com>

	* configure.ac:
	Switch checks for gst-python and pygtk to python checks instead of
	relying on pkg-config since there might be several versions of the
	modules (on per python version) and pkg-config only handles one version.
	Fixes #382249