After last "emerge -uDN world" a new Python 2.7 installed. After it I did revdep-rebuild, run python-updater ${options} and then emerge --depclean. It removed dev-lang/python-2.6.6-r2 but somehow it failed. I can't run emerge, I even can't run a Python interpreter. Reproducible: Always Steps to Reproduce: 1. Have last stable portage 2. emerge -uDN world (Python 2.7 will be installed) 3. python-updater ${options} 4. revdep-rebuild 5. emerge --depclean -> python 2.6 is removed Actual Results: Python is removed, a lot of utilities stop working. Expected Results: Python 2.7 should replace 2.6 normally Here is the error message of emerge --depclean: * Depclean may break link level dependencies. Thus, it is * recommended to use a tool such as `revdep-rebuild` (from * app-portage/gentoolkit) in order to detect such breakage. * * Always study the list of packages to be cleaned for any obvious * mistakes. Packages that are part of the world set will always * be kept. They can be manually added to this set with * `emerge --noreplace <atom>`. Packages that are listed in * package.provided (see portage(5)) will be removed by * depclean, even if they are part of the world set. * * As a safety measure, depclean will not remove any packages * unless *all* required dependencies have been resolved. As a * consequence, it is often necessary to run `emerge --update * --newuse --deep @world` prior to depclean. Calculating dependencies... done! >>> Calculating removal order... dev-lang/python selected: 2.6.6-r2 protected: none omitted: 2.7.1-r1 3.1.3-r1 All selected packages: dev-lang/python-2.6.6-r2 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging dev-lang/python-2.6.6-r2... /usr/lib64/portage/bin/ebuild.sh: řádek 1818: /usr/bin/python2.6: Adresář nebo soubor neexistuje * ERROR: dev-lang/python-2.6.6-r2 failed (postrm phase): * filter-bash-environment.py failed * * Call stack: * ebuild.sh, line 1950: Called preprocess_ebuild_env * ebuild.sh, line 1837: Called filter_readonly_variables * ebuild.sh, line 1818: Called die * The specific snippet of code: * "${PORTAGE_PYTHON:-/usr/bin/python}" "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die "filter-bash-environment.py failed" * * If you need support, post the output of 'emerge --info =dev-lang/python-2.6.6-r2', * the complete build log and the output of 'emerge -pqv =dev-lang/python-2.6.6-r2'. * The complete build log is located at '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/temp/environment'. * S: '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/work/python-2.6.6' /usr/lib64/portage/bin/ebuild-ipc: řádek 7: /usr/bin/python2.6: Adresář nebo soubor neexistuje /usr/lib64/portage/bin/ebuild-ipc: řádek 7: exec: /usr/bin/python2.6: nelze provést: Adresář nebo soubor neexistuje * The ebuild phase 'postrm' has exited unexpectedly. This type of behavior * is known to be triggered by things such as failed variable assignments * (bug #190128) or bad substitution errors (bug #200313). Normally, before * exiting, bash should have displayed an error message above. If bash did * not produce an error message above, it's possible that the ebuild has * called `exit` when it should have called `die` instead. This behavior * may also be triggered by a corrupt bash binary or a hardware problem * such as memory or cpu malfunction. If the problem is not reproducible or * it appears to occur randomly, then it is likely to be triggered by a * hardware problem. If you suspect a hardware problem then you should try * some basic hardware diagnostics such as memtest. Please do not report * this as a bug unless it is consistently reproducible and you are sure * that your bash binary and hardware are functioning properly. /usr/lib64/portage/bin/ebuild.sh: řádek 1818: /usr/bin/python2.6: Adresář nebo soubor neexistuje * ERROR: dev-lang/python-2.6.6-r2 failed: * filter-bash-environment.py failed * * Call stack: * misc-functions.sh, line 17: Called source '/usr/lib64/portage/bin/ebuild.sh' * ebuild.sh, line 1950: Called preprocess_ebuild_env * ebuild.sh, line 1837: Called filter_readonly_variables * ebuild.sh, line 1818: Called die * The specific snippet of code: * "${PORTAGE_PYTHON:-/usr/bin/python}" "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die "filter-bash-environment.py failed" * * If you need support, post the output of 'emerge --info =dev-lang/python-2.6.6-r2', * the complete build log and the output of 'emerge -pqv =dev-lang/python-2.6.6-r2'. * This ebuild is from an overlay named 'gentoo': '/var/db/pkg/' * The complete build log is located at '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/temp/environment'. * S: '/var/tmp/binpkgs/dev-lang/python-2.6.6-r2/work/python-2.6.6' /usr/lib64/portage/bin/ebuild-ipc: řádek 7: /usr/bin/python2.6: Adresář nebo soubor neexistuje /usr/lib64/portage/bin/ebuild-ipc: řádek 7: exec: /usr/bin/python2.6: nelze provést: Adresář nebo soubor neexistuje * The ebuild phase 'die_hooks' has exited unexpectedly. This type of * behavior is known to be triggered by things such as failed variable * assignments (bug #190128) or bad substitution errors (bug #200313). * Normally, before exiting, bash should have displayed an error message * above. If bash did not produce an error message above, it's possible * that the ebuild has called `exit` when it should have called `die` * instead. This behavior may also be triggered by a corrupt bash binary or * a hardware problem such as memory or cpu malfunction. If the problem is * not reproducible or it appears to occur randomly, then it is likely to * be triggered by a hardware problem. If you suspect a hardware problem * then you should try some basic hardware diagnostics such as memtest. * Please do not report this as a bug unless it is consistently * reproducible and you are sure that your bash binary and hardware are * functioning properly. !!! FAILED postrm: 1 * The 'postrm' phase of the 'dev-lang/python-2.6.6-r2' package has failed * with exit value 1. * * The problem occurred while executing the ebuild file named * 'python-2.6.6-r2.ebuild' located in the '/var/db/pkg/dev- * lang/python-2.6.6-r2' directory. If necessary, manually remove the * environment.bz2 file and/or the ebuild file located in that directory. * * Removal of the environment.bz2 file is preferred since it may allow the * removal phases to execute successfully. The ebuild will be sourced and * the eclasses from the current portage tree will be used when necessary. * Removal of the ebuild file will cause the pkg_prerm() and pkg_postrm() * removal phases to be skipped entirely.
I am able to switch to Python 2.7 via "eselect python set 1". However I think user should be informed about this change.
And for example if I try revdep-rebuild with Python 2.7, it starts reemerging some packages and it fails: snippet: libtool: compile: x86_64-pc-linux-gnu-gcc -pthread -DHAVE_CONFIG_H -I. -I.. -I/usr/include/python2.7 -I/usr/include/python2.7 -pthread -DQT_SHARED -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -pthread -DQT_SHARED -I/usr/include/libgnomecanvas-2.0 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/libart-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pixman-1 -I/usr/include/libpng14 -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -O2 -pipe -march=core2 -Wall -std=c9x -fno-strict-aliasing -MT gnomecanvas_la-canvasmodule.lo -MD -MP -MF .deps/gnomecanvas_la-canvasmodule.Tpo -c canvasmodule.c -fPIC -DPIC -o .libs/gnomecanvas_la-canvasmodule.o /usr/bin/python2: can't open file '/usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No such file or directory make[2]: *** [canvas.c] Error 2 make[2]: *** Waiting for unfinished jobs.... mv -f .deps/gnomecanvas_la-canvasmodule.Tpo .deps/gnomecanvas_la-canvasmodule.Plo make[2]: Leaving directory `/var/tmp/portage/dev-python/libgnomecanvas-python-2.28.1/work/gnome-python-2.28.1-2.7/gnomecanvas' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-python/libgnomecanvas-python-2.28.1/work/gnome-python-2.28.1-2.7' make: *** [all] Error 2 emake failed * ERROR: dev-python/libgnomecanvas-python-2.28.1 failed (compile phase): * Building failed with CPython 2.7 in building() function * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 5604: Called gnome-python-common_src_compile * environment, line 2955: Called python_execute_function '-s' 'building' * environment, line 4177: Called die * The specific snippet of code: * die "${failure_message}"; * * If you need support, post the output of 'emerge --info =dev-python/libgnomecanvas-python-2.28.1', * the complete build log and the output of 'emerge -pqv =dev-python/libgnomecanvas-python-2.28.1'. * The complete build log is located at '/var/tmp/portage/dev-python/libgnomecanvas-python-2.28.1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/libgnomecanvas-python-2.28.1/temp/environment'. * S: '/var/tmp/portage/dev-python/libgnomecanvas-python-2.28.1/work/gnome-python-2.28.1'
(In reply to comment #2) > '/usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No > such file or directory On my PC I got this: # qfile codegen.py dev-python/pygobject (/usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py) So try: emerge -a1 dev-python/pygobject
(In reply to comment #3) > (In reply to comment #2) > > > '/usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No > > such file or directory > > On my PC I got this: > > # qfile codegen.py > dev-python/pygobject > (/usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py) > > So try: > > emerge -a1 dev-python/pygobject I've got: michal@usambara ~ $ eselect python list Available Python interpreters: [1] python2.7 * [2] python3.1 michal@usambara ~ $ qfile codegen.py dev-python/pygobject (/usr/lib64/python2.6/site-packages/gtk-2.0/codegen/codegen.py) Apparently Python 2.6 wasn't replaced completely.
Same problem. The postrm phase (eselect_python_update function) of the python ebuild designed to switch python to some other version via eselect, but ebuild.sh died before pkg_postrm is called. ebuild.sh: line 1818 "${PORTAGE_PYTHON:-/usr/bin/python}" "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die "filter-bash-environment.py failed" PORTAGE_PYTHON is set to old version at this time. Ebuild or portage itself needs to be fixed somehow.
Unstable Portage has been already fixed to disallow uninstallation of currently used Python interpreter...
(In reply to comment #6) > Unstable Portage has been already fixed to disallow uninstallation of currently > used Python interpreter... So what is the solution for my problem? Is it recommended to uninstall Python 2.7 and install Python 2.6 again (emerge --oneshot =dev-lang/python-2.6.6-r2) and then "emerge -uDN world"? I still have problems with another packages like dev-python/notify-python-0.1.1-r2: make[2]: Entering directory `/var/tmp/portage/dev-python/notify-python-0.1.1-r2/work/notify-python-0.1.1-2.7/src' if /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_LOG_DOMAIN=\"pynotify-python\" -DDATADIR=\"/usr/share\" -DLIBDIR=\"/usr/lib64\" -pthread -DQT_SHARED -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include/qt4 -I/usr/include/qt4/QtGui -I/usr/include/libdrm -I/usr/include/qt4/QtCore -I/usr/include/python2.7 -O2 -pipe -march=core2 -MT pynotifymodule.lo -MD -MP -MF ".deps/pynotifymodule.Tpo" -c -o pynotifymodule.lo pynotifymodule.c; \ then mv -f ".deps/pynotifymodule.Tpo" ".deps/pynotifymodule.Plo"; else rm -f ".deps/pynotifymodule.Tpo"; exit 1; fi (cd . \ && /usr/bin/python /usr/lib64/python2.6/site-packages/gtk-2.0/codegen/codegen.py \ --register /usr/share/pygtk/2.0/defs/gtk-types.defs \ --register /usr/share/pygtk/2.0/defs/gdk-types.defs \ --override pynotify.override \ --prefix pypynotify pynotify.defs) > gen-pynotify.c \ && cp gen-pynotify.c pynotify.c \ && rm -f gen-pynotify.c /usr/bin/python2.7: can't open file '/usr/lib64/python2.6/site-packages/gtk-2.0/codegen/codegen.py': [Errno 2] No such file or directory make[2]: *** [pynotify.c] Error 2 make[2]: *** Waiting for unfinished jobs.... As you can see it still tries to use Python 2.6 even if I have Python 2.7 installed and selected via eselect.
(In reply to comment #7) Reinstall dev-python/pygobject.
I have been trying to deal with this problem also. I did the following: bireme ~ # emerge --tree --ask --verbose <dev-lang/python-2.7 to install python2.6 hoping that will resolve the lack of 2.6 problem. But then when I do: bireme ~ # eselect python list Available Python interpreters: [1] python2.7 [2] python3.1 * and I don't see 2.6. And still have problems with the lact of 2.6. I did as #8 suggested but get: >>> Emerging (1 of 1) dev-python/pygobject-2.26.0-r1 * pygobject-2.26.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * Package: dev-python/pygobject-2.26.0-r1 * Repository: gentoo * Maintainer: gnome@gentoo.org python@gentoo.org * USE: amd64 cairo elibc_glibc kernel_linux multilib threads userland_GNU * FEATURES: sandbox >>> Unpacking source... >>> Unpacking pygobject-2.26.0.tar.bz2 to /var/tmp/portage/dev-python/pygobject-2.26.0-r1/work >>> Source unpacked in /var/tmp/portage/dev-python/pygobject-2.26.0-r1/work >>> Preparing source in /var/tmp/portage/dev-python/pygobject-2.26.0-r1/work/pygobject-2.26.0 ... * Fixing OMF Makefiles ... [ ok ] * Running elibtoolize in: pygobject-2.26.0/ * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... * Applying pygobject-2.15.4-fix-codegen-location.patch ... [ ok ] * Applying pygobject-2.26.0-make_check.patch ... [ ok ] * Applying pygobject-2.18.0-support_multiple_python_versions.patch ... [ ok ] * Applying pygobject-2.26.0-disable-non-working-tests.patch ... [ ok ] * Applying pygobject-2.26.0-nocrash.patch ... [ ok ] * Applying pygobject-2.26.0-disabled-threads.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/dev-python/pygobject-2.26.0-r1/work/pygobject-2.26.0' ... * Running aclocal -I m4 ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal -I m4 ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy ... [ ok ] * Path to 'python': '/usr/bin/python' * ABI: 'amd64' * DEFAULT_ABI: 'amd64' * EPYTHON: 'python2.6' * PYTHON_ABI: '2.6' * Locally active version of Python: '' * ERROR: dev-python/pygobject-2.26.0-r1 failed (prepare phase): * 'python' does not respect EPYTHON variable * * Call stack: * ebuild.sh, line 56: Called src_prepare * environment, line 5701: Called python_copy_sources * environment, line 3981: Called _python_calculate_PYTHON_ABIS * environment, line 729: Called _python_final_sanity_checks * environment, line 863: Called die * The specific snippet of code: * die "'python' does not respect EPYTHON variable"; * * If you need support, post the output of 'emerge --info =dev-python/pygobject-2.26.0-r1', * the complete build log and the output of 'emerge -pqv =dev-python/pygobject-2.26.0-r1'. * The complete build log is located at '/var/tmp/portage/dev-python/pygobject-2.26.0-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/pygobject-2.26.0-r1/temp/environment'. * S: '/var/tmp/portage/dev-python/pygobject-2.26.0-r1/work/pygobject-2.26.0' >>> Failed to emerge dev-python/pygobject-2.26.0-r1, Log file:
Changing back to python2.7 and taking 2.6 out of USE_PYTHON="2.7 3.1" in the /etc/make.conf file seems to have fixed all my problems.
Looks to me like the issues here have been fixed.
