The `emerge -e system world' command, which is executed after a successful `emerge --sync', causes portage to be emerged, which fails with this console output: >>> Original instance of package unmerged safely. * * FEATURES="userfetch" is now enabled by default. Depending on your ${DISTDIR} * permissions, this may result in Permission Denied errors. If you would like * to fetch with superuser privileges, add FEATURES="-userfetch" to make.conf. * * The world file now supports slot atoms such as 'sys-devel/gcc:3.4'. In some * cases, emerge --depclean may remove slots that it would not have removed * in the past. The emerge --noreplace command can be used to add an atom to * the world file and prevent matching packages from being removed. A slot * atom will be recorded in the world file for any atom that is precise enough * to identify a specific slot. * * For help with using portage please consult the Gentoo Handbook * at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3 * /tmp/local/g2/usr/lib/portage/bin/ebuild.sh: line 1462: /tmp/local/g2/var/tmp/._portage_reinstall_.4EJ5jN/bin/filter-bash-environment.py: No such file or directory /tmp/local/g2/usr/lib/portage/bin/ebuild.sh: line 1462: /tmp/local/g2/var/tmp/._portage_reinstall_.4EJ5jN/bin/filter-bash-environment.py: No such file or directory * * ERROR: sys-apps/portage-2.2.00.9063 failed. * Call stack: * misc-functions.sh, line 18: Called source '/tmp/local/g2/usr/lib/portage/bin/ebuild.sh' * ebuild.sh, line 1632: Called die * The specific snippet of code: * preprocess_ebuild_env || \ * die "error processing environment" * The die message: * error processing environment * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/tmp/local/g2/var/tmp/portage/sys-apps/portage-2.2.00.9063/temp/build.log'. * The ebuild environment file is located at '/tmp/local/g2/var/tmp/portage/sys-apps/portage-2.2.00.9063/temp/environment'. * !!! post postinst failed; exiting. !!! FAILED postinst: 1
that is a one-time "feature". In fact your portage is fine, so please restart the merge. After this time, you'll never see it again. It happens when upgrading from a certain portage version (in the bootstrap image) to a recent one, starting I think 3 or 4 releases back ago.
Created attachment 139585 [details] build log
(In reply to comment #1) > that is a one-time "feature". In fact your portage is fine, so please restart > the merge. After this time, you'll never see it again. It happens when > upgrading from a certain portage version (in the bootstrap image) to a recent > one, starting I think 3 or 4 releases back ago. > OK, will try it ...
Looks promising. I am redoing `emerge -e system world', and portage was emerged successfully this time. Package 11 out of 69 is being emerged as I write this. So, the workaround is to retry the `emerge -e system world' once if it terminates with a nonzero status. But shouldn't this still be treated as a bug (minor, not blocker)?
The only way out is to make a new snapshot, which has a newer portage such that the problem doesn't occur. Alternative would be if Portage would get fixed for this case, but I have no clue where it comes from exactly. So I'll have to do the first one. I have to do that anyway, as our 64-bits targets need them to bootstrap. However, starting from those, you no longer need to emerge subversion explicitly as it's included in the system set for prefix now.
