GNOME Bugzilla – Bug 547778
Trunk fails to build
Last modified: 2009-01-18 09:41:56 UTC
SVN trunk fails to build. I made sure I *do* have all the required Python modules by importing them manually from a Python console. No idea why the check fails. Running ./configure --enable-maintainer-mode --prefix /opt/gnome-2-24 --libdir ${exec_prefix}/lib --disable-static --enable-gtk-doc ... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for a Python interpreter with version >= 2.4... python checking for python... /usr/bin/python checking for python version... 2.5 checking for python platform... linux2 checking for python script directory... ${prefix}/lib/python2.5/site-packages checking for python extension module directory... ${exec_prefix}/lib/python2.5/site-packages checking whether to run pyreqs.py... yes checking ./pyreqs.py... bonobo ORBit pygtk gtk *MISSING* no configure: error: Could not find required Python module *** error during stage configure of accerciser: ########## Error running ./autogen.sh --prefix /opt/gnome-2-24 --libdir '${exec_prefix}/lib' --disable-static --enable-gtk-doc *** [39/44]
this is because accerciser doesn't properly list its dependencies in configure.ac, please include what's listed at http://live.gnome.org/Accerciser (section requirements) in a PKG_CHECK_MODULES and AM_PYTHON_MOD checks form.
May I also point to http://uwstopia.nl/blog/2006/11/using-autotools-to-detect-python-modules ? It's NOT good to check at compile time, because some stuff may just not be there (or depending on $DISPLAY or whatever). This is not my personal opinion, but one raised by distributors.
Accerciser should be able to be built in a headless environment (ie. no $DISPLAY). If it doesn't, it's a bug. I forgot about it, but this is why we provide the --without-pyreqs flag, for package builders. Gilles, I don't fully understand your comment, could you provide a patch?
Wouter, I would be curious to see the output of the following: modules = ['bonobo', 'ORBit', 'pygtk', 'gtk', 'gtk.glade', 'gtk.gdk', 'wnck', 'pyatspi'] for name in modules: m = __import__(name) Also, how about the output of the following from a terminal?: python -c 'import gtk'
I already tried that. Here's the output: [...] Indeed, none at all ;)
Also pyreqs.py doesn't use import pygtk ; pygtk.require('2.0') which means it won't find pygtk modules if they are installed in a directory where .pth files are not parsed automatically (this is the case with jhbuild).
FWIW, running pyreqs.py here gives me: /gnome/releases/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:48: RuntimeWarning: tp_compare didn't return -1 or -2 for exception from gtk import _gtk bonobo ORBit pygtk ImportError: could not import gio ImportError: could not import gio gtk gtk.glade *MISSING* What's interesting, though, is that if I move the gtk.glade before the pygtk one, it works fine...
I've built with --without-pyreqs, and now I get this when running accerciser: /gnome/releases/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:48: RuntimeWarning: tp_compare didn't return -1 or -2 for exception from gtk import _gtk ImportError: could not import gio ImportError: could not import gio Traceback (most recent call last):
+ Trace 206257
it = gtk.IconTheme()
Maybe it's something broken in my python setup, though?
Vincent, Can't think of anything off the top of my head, but do other python based gnome modules run ok?
Wouter, do you have more info on your specific case? Could you build and run Accerciser with --without-pyreqs? Andre, you marked this as a blocker, do you see it too?
(In reply to comment #9) > Vincent, > Can't think of anything off the top of my head, but do other python based gnome > modules run ok? > Yes, they do work fine. But again, could be a local issue in my case.
src/accerciser.in has: import gnome # make this program accessible props = { gnome.PARAM_APP_DATADIR : os.path.join(sys.prefix, 'share')} gnome.program_init('accerciser', '@VERSION@', properties=props) import pygtk pygtk.require('2.0') import gtk I believe import pygtk; pygtk.require('2.0') should come *before* importing the gnome module.
Created attachment 118252 [details] [review] accerciser-HEAD-autofoo.patch Eitan, here is a patch that shows what I was thinking about, this is shamelessly copied from orca module but given that you use pyreqs, I don't know if it's that useful (didn't realized what pyreqs did before). It also includes some little autofoo tweaks. btw guys, it should builds and runs nicely on my gentoo, even though it only puts a red shadow on my desktop and I can't do anything else than switch apps with alt+tab.
Eitan: PING - Patch attached
Created attachment 122270 [details] [review] import pygtk first, so pygtk.require is run before other modules Gilles: that won't be enough, as pygtk.require('2.0') needs to be called for gtk-related modules to be found (unless installed in directories that are already in sys.path). The fix is actually to let pyreqs.py check for pygtk first; so it will then run pygtk.require('2.0') which will add appropriate paths to sys.path, so other modules will be found in the correct location.
Note comment #12 has already been fixed in svn.
bgmerrell: ping
Sorry for flaking on this. I committed patch #2. Wouter, could you please confirm that this is fixed in trunk? There have been a few interwoven issues in this patch. If anybody (besides Wouter) feels like their issue has not been addressed, please open a new patch.
(In reply to comment #18) > Wouter, could you please confirm that this is fixed in > trunk? Sorry, I don't have any Gnome development tree on my machines right now, so I can't test your patch.
I will close this bug. Like I said above, if there are any other build hardships, please open a new bug. Thanks Wouter for the initial report, and thanks Fredric for the patch!