I encountered this problem doing automated builds. It seems that the latest stage3 tarball (amd64) has python3 set as the system python. I'm guessing this is not intentional. Reproducible: Always Steps to Reproduce: s3test # mkdir gentoo s3test # tar xjpf stage3-amd64-20100729.tar.bz2 -C gentoo s3test # chroot gentoo /bin/bash / # eselect python list Available Python interpreters: [1] python2.6 [2] python3.1 * / # python --version Python 3.1.2 This causes problems with subsequent emerges if they involve python as most packages still depend on python2 as the system python. The workaround is to simply run "eselect python set python2". After unpacking the tarball and doing a chroot, but this may be a major hangup for those doing their first Gentoo install and are not familar eselect. s3test # md5sum stage3-amd64-20100729.tar.bz2 496d7a2977dcd5f035d729c9e5c76b24 stage3-amd64-20100729.tar.bz2
Please pull affected stage3s until we have a resolution. This will avoid #gentoo and the forums getting flooded Added QA to CC
If there's a cause for using the 'blocker' severity, I think this bug is one. CCing infra for Roy's request.
I already pulled these stages...
(In reply to comment #3) > I already pulled these stages... > Thanks!
Argh, I know this isn't really you're problem per-se, but just FYI. The 20100617 tarball apparently uses a different glibc than the 20100729 tarball. And I created binary packages when the 20100729 was the "latest". Now after I update system and it pulls in the bash binary package, everything fails because bash was built against a different glibc (from 20100729). Not a problem I just need to recompile these binary packages. But I'd just thought I'd let you know in case you start to encounter some weird bug reports.
I don't know what's responsible for setting python3 as the default interpreter, but I suppose that the python ebuilds/eclasses are likely suspects.
*** Bug 330943 has been marked as a duplicate of this bug. ***
The infra aspect of this bug is gone. Removing us.
Maybe bug 321785 caused python3 to be set as the default interpreter for stage1, and then that was inherited by stage2 and stage3?
Seems not to be a problem with subsequent stage3s. Fixed.
The problem occurs again in stage3-i686-20101228.tar.bz2 at http://distfiles.gentoo.org/releases/x86/autobuilds.
Also re-occurs for stage3-amd64-20101230.tar.bz2
(In reply to comment #12) > Also re-occurs for stage3-amd64-20101230.tar.bz2 It's a separate problem with known solution, which will be applied somewhen.
I just committed a revert to python-2.6.6-r1 which should fix this. I'm currently running local tests to verify if it works or not.
Just downloaded stage3-i686-20110315.tar.bz2 from the autobuilds, unpacked and saw the default python profile is still set to 3.1 (though 2.6 is available).