If pyhton-2.7 is installed aside 2.6 the ebuild will try to try to do some work with 2.7-components. This causes an error : Building failed with CPython 2.7 in python_default_function() function Reproducible: Always Steps to Reproduce: 1.eix-sync 2.emerge -u @world 3. Actual Results: build stops with errormassage Expected Results: should finish and merge Did a try to install libreoffice. For that i had to install python-2.7 and added USE_PYTHON="2.6 2.7 3.1" to make.conf. Todays general update wanted to update gnome-doc-utils-0.20.2 to 20.3. This failed with the above error. I put a modified ebuild to my privat overlay. That works. See attatchment.
Created attachment 258643 [details] modified and working ebuild changed two lines to restrict python-2.7
Please attach build.log when it fails
Created attachment 258644 [details] build.log sorry - here it is.
Did you run python-updater after setting USE_PYTHON, as it seems libxml2 is installed only for python2.6 ?
(In reply to comment #4) > Did you run python-updater after setting USE_PYTHON, as it seems libxml2 is > installed only for python2.6 ? > yes i did. Some irritation because "eselect python" ! It is still set to 2.6 as main active one. Does this matter ? When i try now nothing comes up !!???
(In reply to comment #4) > Did you run python-updater after setting USE_PYTHON, as it seems libxml2 is > installed only for python2.6 ? > You right there are no 2.7 site-packages from libxml2 installed. I did a reinstall an - no - 2.7 is not done. But some strange behaviour arrises when i do eselect python set 2 (2.7) and try an emerge : Traceback (most recent call last): File "/usr/bin/emerge", line 43, in <module> retval = emerge_main() File "/usr/lib64/portage/pym/_emerge/main.py", line 1617, in emerge_main myopts, myaction, myfiles, spinner) File "/usr/lib64/portage/pym/_emerge/actions.py", line 435, in action_build retval = mergetask.merge() File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 997, in merge rval = self._merge() File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1305, in _merge self._main_loop() File "/usr/lib64/portage/pym/_emerge/Scheduler.py", line 1452, in _main_loop self._poll_loop() File "/usr/lib64/portage/pym/_emerge/PollScheduler.py", line 133, in _poll_loop handler(f, event) File "/usr/lib64/portage/pym/_emerge/SpawnProcess.py", line 150, in _output_handler buf.fromfile(files.process, self._bufsize) IOError: [Errno 11] Resource temporarily unavailable This seems not that good. Every emerge done with 2.7 activated dies.
Solved the last problem. Reinstalled portage with python3 USE-Flag. Then within an activated 2.7 emergeing was no problem. But this did not solve the gnome-doc-utils problem. Still the same error in spite of activated 2.6 or 2.7 .
You are doing it wrong. When setting USE_PYTHON, you first need to rebuild all python packages so that they can install modules for the appropriate version of python. So what you should have done before enabling python 2.7 as your main interpreter is to stick to 2.6, run python-updater, then change to 2.7.
(In reply to comment #8) > You are doing it wrong. When setting USE_PYTHON, you first need to rebuild all > python packages so that they can install modules for the appropriate version of > python. So what you should have done before enabling python 2.7 as your main > interpreter is to stick to 2.6, run python-updater, then change to 2.7. > This is exactly what i did. To concentrate it - steps were : 1.installed 2.7 as dependency of libreoffice 2.added USE_PYTHON="2.6 2.7" to make.conf 3.run python-updater 4.eselect python set 2 (2.7) 5.emerge stoped working (see above) 6.eselect python set 1 (2.6) 7.added USE-Flag of portage to python3 8.emerge portage (installed python3) 9.again eselect python set 2 (2.7) 10.emerge gnome-doc-utils Resulted in the same error So if this was wrong tell me and tell me please what to do to solve a possible problem. At the moment emerge is working well (set back to 2.6) and i dont see problems with the compiled programs. thanks a lot
did you check if libxml2 has been rebuilt ? If not, then the bug should be forwarded to python guys, if you can reproduce.
Created attachment 258742 [details] 1. build.log libxml2 compiled with active 2.6 gnome-doc-utils compiled with active 2.6
Created attachment 258744 [details] 2. build.log libxml2 compield with 2.6 gnome-doc-utils with activated 2.7
Created attachment 258746 [details] 3. build.log libxml2 compield with activated 2.7 gnome-doch-utils compiled with activated 2.7
(In reply to comment #10) > did you check if libxml2 has been rebuilt ? If not, then the bug should be > forwarded to python guys, if you can reproduce. See the different combinations of erronious build.logs. Looks really like a libxml2 problem that is not building the optimizations and site-packages. Its always just building for the activated python-version while gnome-doc-utils is looking for both of them. hope this helps a bit
I want to know if you rebuilt libxml2 so it has multiple python slots support or not, not what fails if you don't. Please attach the output of: $ qlist libxml2
Created attachment 258756 [details] result of qlist libxml2 here it is
ok, could you paste your emerge --info now ?
Created attachment 258759 [details] emerge --info ok
(In reply to comment #17) > ok, could you paste your emerge --info now ? > is this one related ? http://forum.soft32.com/linux/gentoo-dev-rfc-Sane-defaults-USE_PYTHON-patch-python-eclass-ftopict526186.html
> ACCEPT_KEYWORDS="amd64" that's what I thought... for one, USE_PYTHON is not something that is ready for general consumption and for two, there is no way current stable tree knows how to deal with it yet. Please do not mix stable and unstable without understanding what the features you want to test are doing.
(In reply to comment #20) > > ACCEPT_KEYWORDS="amd64" > > that's what I thought... > > for one, USE_PYTHON is not something that is ready for general consumption and > for two, there is no way current stable tree knows how to deal with it yet. > Please do not mix stable and unstable without understanding what the features > you want to test are doing. > you right. I want a mostly stable machine. But some packages like libreoffice (worse a try) or others i use permanently like scribus, lyx, avidemux, gimp, pgadmin3, mythtv, vlc, cups set to ~arch - forcing some other packages to be in package.keywords either as long as its needed. So this is not an ever growing file. This is going for some years now giving the opportunity to see if dumped ~packages could go stable. And this was the first encounter that problems could not be solved in a way it is not interfering with other programs in a noticable and unpleasant way. I think it was worse to discover and as i noted in #1 there is at least a dirty workaround. Thanks for all your work - i know from hartblog you are involved in that particular problem.
while the intention to test ~arch packages readiness for stabilization is noble, combining with USE_PYTHON is really not a good idea. Even ~arch is not really ready for it so arch is still a long shot :)
