The python bindings for Gtk/Gnome2 break Gtk/Gnome1 bindings, they use the same namespaces. There is no solution that i'm aware of, so you can only choose to use one of the sets of bindings. Using both might lead to fatal errors and segfaults. Ii have only marginally tested it, but i can assure most Gnome1 scripts will break. So for Gnome1 the packages installed should be pygtk-0.6.8-r2 or gnome-python-1.4.1-r4 and for Gnome2 it should be pygtk-1.99.x (in todays state of the portage tree). Gnome2 bindings were tested from CVS.
we should probably add a conflict between the new and old and new...
First problematic ebuild found : ftpcube. It depends on the gnome1 bindings and it won't work for people testing the gnome2 beta. Maybe add a <dev-python/pygtk-1.99 dependency ?
ftpcube is fixed
Ok, as promised here's a solution. A bit late, i've been busy. It's not beautiful, but it works (at least for me). This one is for pygtk2, it basicly puts pygtk2 in a non-interfering path so pygtk1 (gnome-python1) doesn't call any of it's functions/classes (which resulted in all the weird behaviour). To run pygtk1 programs nothing extra is needed, to run pygtk2 scripts we need to add the path to pygtk2 in the PYTHONPATH var. Right now the path for pygtk2 is <python_install_dir>/site-packages/pygtk2/ (normally it would be in <python_install_dir>/site-packages/ ), it seemed logical to have pygtk2 as the 'harder to reach one' for now : most scripts will still be GTK1. I suppose we could have some wrapper shellscript to run pygtk2 apps, which basicly only exports the pygtk2 PYTHONPATH and then runs the script. Make the move from one to the other for users as clean as possible (i don't think there are any pygtk2 scripts in portage yet). I've contacted the author about adding install paths configurability to the config script, right now i do it by patching it. Attached is the diff for in the pygtk files dir and the updated pygtk-1.99.10 ebuild. Let me know what you think of this solution and if it's ok with you i can make a gnome-python2 ebuild as well with the same solution.
Created attachment 1935 [details, diff] pygtk-1.99.10 configure patch
Created attachment 1936 [details] pygtk-1.99.10 adapted ebuild to incorporate the patch
sounds like a working solution, I'm having some time off so I'm not commiting at once.
Created attachment 2013 [details] pygtk-1.99.10.ebuild Adapted ebuild to add dependency on PyOpenGL ebuild (bug #4658). Also added license. Obsoletes the other earlier 1.99.10 ebuild.
Created attachment 2205 [details] pygtk-1.99.11.ebuild [update] Well, since there's a new version i decided to dump the ebuild here and fix a dumb mistake i made. Somehow i thought pygtks opengl stuff binded to PyOpenGL, but it just wants gtkglarea. What the hell was i thinking ? Must've been very late at night and in a serious sleep deprived state ;) Ah well, one good thing that came from it is that i submitted an PyOpenGL ebuild (which was quite a nasty build to get right) :) Note that i changed the patch name in this ebuild to something more general, cause it seems to be a not so version specific diff. As soon as this get submitted in the CVS tree i will submit a gnome-python ebuild.
anyone on this bug CC want to work on eroaster?
*** Bug 5243 has been marked as a duplicate of this bug. ***
Created attachment 2688 [details] pygtk-1.99.12.ebuild Here's another version (1.99.12) with some updates. Made deps a bit shorter and did what i think is the right thing with the opengl dep. If PyOpenGL is not installed OGL still won't work, altough it's not a direct dependency. I suppose when you have opengl as use flag, you expect a working solution so i think it needs to be installed anyway. (PyOpenGL is bug #4658)
Created attachment 3657 [details] pygtk-1.99.13.ebuild The new pygtk development version, now incorporates a different path in it's configure script so patching as i did in earlier versions is no longer necessary. The PYTHONPATH now should be set /usr/lib/pyton2.2/site-packages/gtk-2.0 for pygtk2 scripts to work. Enabling opengl is possible, but for me it results in breakage due to some path problems in a gtkglarea.la file. This is imo a problem with the opengl-update script or the gtkglarea ebuilds and they should be fixed in some way, ill open a bug/look into that later. It's easy to make a link around the problem if you really want to use opengl. gnome-python ebuild also coming up (really this time)
*** Bug 6261 has been marked as a duplicate of this bug. ***
in the tree. Closing
