vte-0.16.8 does not build the python module, even if the "python" useflag is set: python -c "import vte" Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named vte See Comment#2 in bug #189556. I think it is related to this.
Just saw the following message floating by during ./configure: checking for headers required to compile python extensions... not found Python bindings disabled.
Created attachment 128812 [details, diff] vte-0.16.8-python-config.patch This is a patch disabling the call to "python-config". This can only considered to be a workaround. A better way would be to make "python-config" recognize the "--includes" parameter and return the correct result.
Created attachment 128813 [details] vte-0.16.8.ebuild with patch applied And here the ebuild applying this patch. Changes to old version: added 3 lines in src_unpack(): # python-config workaround epatch ${FILESDIR}/${P}-python-config.patch eautoconf
Definitely python-2.4 related... $ equery f vte | grep python /usr/lib/python2.5 /usr/lib/python2.5/site-packages /usr/lib/python2.5/site-packages/gtk-2.0 /usr/lib/python2.5/site-packages/gtk-2.0/vtemodule.a /usr/lib/python2.5/site-packages/gtk-2.0/vtemodule.la /usr/lib/python2.5/site-packages/gtk-2.0/vtemodule.so $ python Python 2.5.1 (r251:54863, Aug 17 2007, 23:09:28) [GCC 4.2.0 (Gentoo 4.2.0)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import vte >>>
perhaps it works with python-2.5, because 2.5's python-config honors the "--includes" option
I'll have a look at the patch later today.
i think we should bring python 2.5 to ~arch instead of patching vte and other stuff that is broken with the current python.
If you want to do this, I'd propose to mask this vte version until python-2.5 is unmasked. But I think, patching the current python with the python-config proposed in bug #188029 would be the easiest and best thing.
(In reply to comment #7) > i think we should bring python 2.5 to ~arch instead of patching vte and other > stuff that is broken with the current python. I wouldn't like GNOME 2.20 stabling to be hindered with python2.5 stabling being a precondition for that. It's a no-brainer to get a revbump of 2.4 with a python-config fix (that is backwards compliant in reporting ldflags with no argument) stable, while stabling 2.5 (once it gets out of mask even) can delay for reasons unrelated to us.
Ok ... now python-2.5 has been unmasked. Just putting ">=python-2.5" into the vte-ebuild should be sufficient. (No more patching ...)
(In reply to comment #10) > Ok ... now python-2.5 has been unmasked. Just putting ">=python-2.5" into the > vte-ebuild should be sufficient. (No more patching ...) > No it isn't the right solution we need to wait to stablize python 2.5.
(In reply to comment #11) > (In reply to comment #10) > > Ok ... now python-2.5 has been unmasked. Just putting ">=python-2.5" into the > > vte-ebuild should be sufficient. (No more patching ...) > > > > No it isn't the right solution we need to wait to stablize python 2.5. > But vte-0.16.8 is unstable too - so it wouldn't matter ... And I think, a non-optimal temporary solution is better then just leaving it buggy
Okay, I've made the dep >=dev-lang/python-2.4.4-r5. This version has the fixed python-config. All is now well with the world.
Great - thanks