I've just updated python-exec and basically nuked my system: (this was 3.4) % eselect python show python2.7 (this confuses the hell out of me) % eselect python list Available Python interpreters, in order of preference: [1] python2.7 * [2] python3.4 * [3] python2.7 * [4] python3.5 * [5] python2.7 * (trying to remediate things) % ebuild python-exec-2.3.ebuild digest merge clean /gentoo/prefix64/usr/lib/portage/bin/filter-bash-environment.py: no supported Python implementation variant found! can't do anything here now...
Please give us the following information: 1. emerge --info 2. Version of app-eselect/eselect-python If /usr/bin/emerge is broken, try running /gentoo/prefix64/usr/lib/python-exec/python3.4/emerge directly.
And from which version were you updating?
I came from 3.2, went to 3.2.1 and then my system was like this. Tracking down how eselect python list works, it seems something went wrong with python-exec.conf: % grep -v '^#' $EPREFIX/etc/python-exec/python-exec.conf python2.7 python3.4 python2.7 python3.5 python2.7 so that's where the dups come from. % emerge --info Portage 2.2.20-prefix (python 2.7.11-final-0, prefix/sunos/solaris/5.11/x64, gcc-4.7.3, unavailable, 5.11 i86pc) ================================================================= System uname: Solaris-2.11-i86pc-i386-64bit-ELF Timestamp of repository gentoo_prefix: Thu, 18 Feb 2016 17:11:44 +0000 sh bash 4.3_p39 ld GNU ld (GNU Binutils) 2.24 app-shells/bash: 4.3_p39::gentoo_prefix_svn dev-java/java-config: 2.2.0::gentoo_prefix_svn dev-lang/perl: 5.22.1::gentoo_prefix dev-lang/python: 2.7.11::gentoo_prefix_svn, 3.4.3-r5::gentoo_prefix_svn, 3.5.1::gentoo_prefix_svn dev-util/cmake: 3.4.3::gentoo_prefix dev-util/pkgconfig: 0.29::gentoo_prefix sys-devel/autoconf: 2.69::gentoo_prefix_svn sys-devel/automake: 1.12.4::gentoo_prefix, 1.14.1::gentoo_prefix_svn, 1.15::gentoo_prefix_svn sys-devel/binutils: 2.24-r2::gentoo_prefix sys-devel/gcc: 4.7.3-r1::gentoo_prefix_svn sys-devel/gcc-config: 1.8-r1::gentoo_prefix_svn sys-devel/libtool: 2.4.6-r1::gentoo_prefix_svn sys-devel/make: 4.1-r1::gentoo_prefix Repositories: gentoo_prefix location: /net/amun/export/scratch0/gentoo/prefix-rsync-tree sync-type: rsync sync-uri: invalid://null priority: -1000 aliases: gentoo gentoo_prefix_svn location: /export/gentoo/prefix-tree masters: gentoo_prefix priority: 0 ACCEPT_KEYWORDS="~x64-solaris" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-solaris2.11" CFLAGS=" -O3 -march=core2 -pipe" CHOST="x86_64-pc-solaris2.11" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS=" -O3 -march=core2 -pipe" DISTDIR="/export/gentoo/distfiles" FCFLAGS="" FEATURES="assume-digests binpkg-logs case-insensitive-fs collision-protect distlocks ebuild-locks fixlafiles force-prefix merge-sync news nostrip parallel-fetch preserve-libs protect-owned sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans unprivileged userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="ftp://mirror.leaseweb.com/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LDFLAGS="" MAKEOPTS="-j3" PKGDIR="/gentoo/prefix64/usr/portage/packages" PORTAGE_CONFIGROOT="/gentoo/prefix64/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/gentoo/prefix64/var/tmp" USE="cracklib cxx ipv6 modules ncurses nls prefix prefix-guest readline ssl unicode x64-solaris xattr zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="SunOS" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse" KERNEL="SunOS" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4 python3_5" RUBY_TARGETS="ruby20 ruby21 ruby22" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON % qlist -Iv eselect-python python-exec app-eselect/eselect-python-20160207 dev-lang/python-exec-2.3.1 emerging no longer works, but I'll play with python-exec.conf to see if that deconfuses portage enough.
ok, removing the dups won't help: Calculating dependencies... done! [ebuild UD ] dev-lang/python-exec-2.3:2::gentoo_prefix [2.3.1:2::gentoo_prefix] PYTHON_TARGETS="(python2_7) (python3_3) (python3_4) (python3_5) (-jython2_7) (-pypy) (-pypy3)" 0 KiB Total: 1 package (1 downgrade), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-lang/python-exec-2.3::gentoo_prefix * python-exec-2.3.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] /gentoo/prefix64/usr/lib/portage/bin/filter-bash-environment.py: no supported Python implementation variant found! * ERROR: dev-lang/python-exec-2.3::gentoo_prefix failed (setup phase): * filter-bash-environment.py failed * that script has shebang #!/gentoo/prefix64/usr/bin/python -b which is likely what's error coming from, so I changed that to point to python3.4, but that didn't help much.
Duplicates shouldn't matter here. Are you sure there's nothing wrong with your installation of portage?
Does running /gentoo/prefix64/usr/bin/python directly work for you?
I've mutilated my portage install to replace usage of PORTAGE_PYTHON with the 3.4 executable in usr/bin. Now I was able to downgrade python-exec. Next thing I re-emerged portage to clean up my changes. After this it seems I can emerge packages again without problems. And yes, running /gentoo/prefix64/usr/bin/python with 3.2.1 did work just fine. Behaviour is still odd with 3.2: % eselect python show python3.4 % eselect python list Available Python interpreters, in order of preference: [1] python3.4 * [2] python3.5 [3] python2.7 % eselect python set python3.5 % eselect python list Available Python interpreters, in order of preference: [1] python3.5 * [2] python3.4 * [3] python2.7 but portage is able to emerge things with this.
Ok, I've figured out the underlying bug. 1. since eselect-python-20151117 or python-exec-2.2 the /usr/bin/python does not report the same sys.executable as the old wrapper did. old: $ python -c 'import sys; print(sys.executable)' /usr/bin/python2.7 new: $ python -c 'import sys; print(sys.executable)' /usr/bin/python This is because I assumed it is desirable to keep wrapping transparent. However, in this case this is a problem since Portage (and probably more programs) look sys.executable up to get the Python interpreter path. So instead of the interpreter, they get our wrapper which is not so bad yet but... 2. python-exec-2.3.1 started to install the wrapper to /usr/bin which allowed us to use a symlink instead of copying it to /usr/bin/python. Which wouldn't be bad if not the fact that Portage uses realpath() on sys.executable. As a result, it gets expanded into python-exec2c and Portage assumes this is the correct Python interpreter, and this is a problem. Now, I'm not sure why you are able to trigger the problem and we are not. This may be another issue, and it may be worthy looking into. In particular, I'm surprised Portage is using: /gentoo/prefix64/usr/lib/portage/bin/filter-bash-environment.py. because it should be using something like: /gentoo/prefix64/usr/lib/portage/python3.4/filter-bash-environment.py. Which means you are either using an outdated Portage or something went very wrong during install. But I don't think this would be the source of the problem or rather, that this would prevent us from hitting it.
Ah, I forgot the most important. I will try to fix this for python-exec-2.3.2. Hopefully it would be enough to add argv[0] setting and we wouldn't have to reintroduce the awful argv[0] patches that were in the Python interpreter. It shouldn't cause any specific issues since for Python scripts, the kernel replaces argv[0] with the target path anyway. So the end result on Linux will be the same, and if it was inconsistent on other systems, it will become consistent now.
Two things, we use old portage (2.2.20), and due to a problem in the past, portage was emerged when only python2.7 and 3.4 were available. Later I emerged python3.5, but since 3.4 was set as active interpreter, portage worked fine. I suspect this might be relevant here, since chosing python3.5 to execute here, would immediately fail on "import python" since the libs weren't compiled for it.
commit 8a26ecd1c274d8c98f4d4e49a522b7cbb9ba1c12 Author: Michał Górny <mgorny@gentoo.org> Date: Thu Feb 18 22:42:14 2016 dev-lang/python-exec: Bugfix bump to 2.3.2, #574970 Bump to bugfix 2.3.2 release with improved error handling, proper argv[0] value for Python interpreter wrapping and a README with recovery instructions. Bug: https://bugs.gentoo.org/574970 Please confirm if it fixes all the issues for you.
thanks, yes I will
2.3.2 seems to work sofar
I could have sworn you asked me about testing 2.4.1 in this bug, and that I reopened it, but it seems it's not, anyway, fwiw, I've tested 2.4.1 and it seems to work fine, thanks
I recall that as well, so this must have been some other bug.
