it is a FHS violation for non-portable binary files to be stored in /usr/share/ dev-python/pygtk sticks .pyc/.pyo files in there which causes problems obviously when upgrading python versions $ /usr/share/pygtk/2.0/codegen/ -v dev-python/pygtk-2.12.0 (/usr/share/pygtk/2.0/codegen) $ ls /usr/share/pygtk/2.0/codegen/*.pyc /usr/share/pygtk/2.0/codegen/argtypes.pyc /usr/share/pygtk/2.0/codegen/docextract.pyc /usr/share/pygtk/2.0/codegen/mkskel.pyc /usr/share/pygtk/2.0/codegen/codegen.pyc /usr/share/pygtk/2.0/codegen/docgen.pyc /usr/share/pygtk/2.0/codegen/override.pyc /usr/share/pygtk/2.0/codegen/createdefs.pyc /usr/share/pygtk/2.0/codegen/h2def.pyc /usr/share/pygtk/2.0/codegen/reversewrapper.pyc /usr/share/pygtk/2.0/codegen/definitions.pyc /usr/share/pygtk/2.0/codegen/__init__.pyc /usr/share/pygtk/2.0/codegen/scmexpr.pyc /usr/share/pygtk/2.0/codegen/defsparser.pyc /usr/share/pygtk/2.0/codegen/mergedefs.pyc
*** Bug 217591 has been marked as a duplicate of this bug. ***
Created attachment 149701 [details, diff] patch to install codegen into /usr/lib/python-2.x/site-packages
Patch looks good, but I don't really see the point of : pkgpythondir = $(pyexecdir)/gtk-2.0 codegendir = $(pkgpythondir)/codegen Why not do : codegendir = $(pyexecdir)/gtk-2.0/codegen ...unless "pkgpythondir" is reused someplace... Am I missing something? Patch should be sent upstream too imho :) Great stuff
(In reply to comment #3) > Patch should be sent upstream too imho :) Great stuff /me should have checked his inbox thoroughly before writing dumb comments :p
(In reply to comment #3) > Patch looks good, but I don't really see the point of : > > pkgpythondir = $(pyexecdir)/gtk-2.0 > codegendir = $(pkgpythondir)/codegen > > Why not do : > > codegendir = $(pyexecdir)/gtk-2.0/codegen I just copied the way upstream did it for other stuff, though I do take your point. And the set of functions exported by the python m4 macros just added to the confusion, till I found the documentation.
(In reply to comment #5) > I just copied the way upstream did it for other stuff, though I do take your > point. And the set of functions exported by the python m4 macros just added to > the confusion, till I found the documentation. To reiterate aforementioned confusion -- I reviewed the patch again, and I believe pkgpythondir is used by the codegen_PYTHON line below in the same file to determine where all those .py files are sent.
Created attachment 154565 [details, diff] patch to install codegen into /usr/lib/python-2.x/site-packages Simpler patch, should be safer imho.
I've just committed my patch to portage on pygtk-2.12.1-r1. Closing
After i installed the new revision i got this error while building the gimp: /usr/bin/python: can't open file '/lib/python2.5/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No such file or directory Which is probably due to the fact that /usr/bin/pygtk-codegen-2.0 looks like this: #!/bin/sh prefix=/usr datarootdir=${prefix}/share datadir=/usr/share codegendir=${exec_prefix}/lib/python2.5/site-packages/gtk-2.0/codegen PYTHONPATH=$codegendir export PYTHONPATH exec /usr/bin/python $codegendir/codegen.py "$@" Note that exec_prefix isn't set anywhere...
Thanks for pointing that out. I've fixed it.
(In reply to comment #10) > Thanks for pointing that out. I've fixed it. > Just out of curiosity, if the old version of pygtk-2.12.1-r1 needed the exec_prefix correction in the patch to fix this issue, why wasn't it bumped to pygtk-2.12.1-r2? I ask because the exec_prefix bug caused gtk-vnc not to build (see bug #224039), and if the pygtk version number isn't bumped, doing another emerge--sync and emerge -u world won't pull the fix in.
Rebuilding pygtk should have been enough. I've forced a revbump just to be sure, ebuilds are identical. Thanks
*** Bug 232279 has been marked as a duplicate of this bug. ***
