This is for tracking purposes as we need to make sure we have a newer enough portage version to fix bug 478188, feel free to CC arches when you prefer
From a tools-portage perspective, we have to fix/stablize the tools to work with this version of portage and the repos.conf changes. The tools-portage team is low on resources to do this quickly right now, so any and all help is appreciated.
(In reply to Paul Varner from comment #1) > From a tools-portage perspective, we have to fix/stablize the tools to work > with this version of portage and the repos.conf changes. I've updated the ebuilds to automatically generate a make.conf PORTDIR="/usr/portage" backward compatibility setting. It shows like a normal CONFIG_PROTECT update that the user will be able to apply via etc-update or dispatch-conf.
Also, see bug 479062 for catalyst make.conf patch.
I see portage-2.1.13.2 is removed from the tree. Is the plan now to stabilize 2.2.0 without any more 2.1.x stabilizations?
(In reply to boxcars from comment #4) > I see portage-2.1.13.2 is removed from the tree. Is the plan now to > stabilize 2.2.0 without any more 2.1.x stabilizations? Yes, well actually I want to do a 2.2.1 release and stabilize that, because of bug 481628.
Actually, bug 481628 was not really a regression, so we're not waiting on that. However bug 480736 is a regression, and it's now fixed in 2.2.1.
@arch teams: Please stabilize sys-apps/portage-2.2.1, but first stabilize app-portage/eix-0.29.3 if you haven't already (bug 482942). Bug #472632 tracks bugs fixed since 2.1.12.2. It's possible that some users will experience some minor snags involving the new userpriv (bug 477664) and usersync (bug 477682) FEATURES defaults, but the upgrade should be smooth for most users. If you don't have userpriv enabled yet, and you have lots of "live" sources in $DISTDIR, then pkg_postinst may consume a lot of time adjusting ownership of files in $DISTDIR.
Stable for HPPA.
x86 stable
arm stable
Before try to keyword I update the entire gentoo-x86 and I get: sys-apps/portage/portage-2.2.1.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['virtual/pypy:1.9', 'dev-lang/python:3.1']
(In reply to Agostino Sarubbo from comment #11) > Before try to keyword I update the entire gentoo-x86 and I get: > > sys-apps/portage/portage-2.2.1.ebuild: DEPEND: > amd64(default/linux/amd64/13.0) ['virtual/pypy:1.9', 'dev-lang/python:3.1'] I've committed a fix for this. Though, as long as portage is going to inline parts of the eclasses, issues like this are going to arise every time we change the list of supported implementations, and possibly other internals.
amd64 stable
ppc64 stable
ia64 stable
alpha stable
sparc stable
ppc stable
SH is not anymore a stable arch, removing it from the cc list
S390 is not anymore a stable arch, removing it from the cc list
M68K is not anymore a stable arch, removing it from the cc list