Bugzilla Bug 189770

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 an attachment (id=128812) [details]
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 an attachment (id=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