When Issuing the following command: emerge -u world --emptytree (this tells me that it will update 104 packages) the system recompiles all packages until it gets to the portage package itself (package #22 in my case). After portage has been compiled, it restarts at package # 1 with the following message: --- AUTOCLEAN: Nothing unmerged. *** RESTARTING emerge via exec() after change of portage version. *** emerge --update --emptytree world Then it starts with package 1 again. It was restarting for the fifth time when I saw what it was doing and cancelled it manually via CTRL-C... Reproducible: Always Steps to Reproduce: 1. emerge -u world --emptytree 2. 3. Actual Results: <package 1 to 22 recompiled (22 being portage) then the following:> --- AUTOCLEAN: Nothing unmerged. *** RESTARTING emerge via exec() after change of portage version. *** emerge --update --emptytree world <then starts again with package 1 so on and so forth, infinite loop> Expected Results: should have proceeded with package 23 until all 104 packages had been recompiled. Gentoo version 1.4, installed with GRP, portage had been emerged by itself with -u before attempting complete recompile of system with source code being downloaded from ADelie Linux Mirror. Don't know if I can remove portage from the world file so that it does not become updated by the emerge -u world command. Either that or "mask" it somehow.
*** Bug 31300 has been marked as a duplicate of this bug. ***
*** Bug 31339 has been marked as a duplicate of this bug. ***
The problem seems to be in emerge assuming that the portage version is of the form p-v1-v2, this problem occures when the portage version is of the form p-v1-v2-v3. So if you have portage 2.0.49-r13-2 installed emerge -e will always fail, because emerge is comparing 2.0.49-r13 with 2.0.49-r13-2, they are never equal so it restarts the emerge -e. Please look in /usr/bin/emerge At line 1182 mysplit=portage.pkgsplit(x[2]) After the above statement is executed mysplit[0] will contain "sys-apps/portage" mysplit[1] will contain "2.0.49" mysplit[2] will contain "-r13" While portage.VERSION is "2.0.49-r13-2" So the compares at lines 1187 and 1196:- if mysplit[1]+mysplit[2]!=portage.VERSION will always fail! I wish I was versed enought with python and portage to fix the above. I hope that someone more competent than I will fix the above bug.
This should be a blocker considering that the current version of portage is "2.0.49-r13-2" (so everyone is affected) and the need to do emerge -e for those who have recently updated their compilers and associated libraries. Perhaps the easiest fix is to ensure that subsequent portage version names are of the form "p-v1-v2" so that emerge will not shoke on it. Can we have a new portage ebuild with a nice version name which emerge can deal with?
Created attachment 19359 [details] fixed portage-2.0.49-r13_fixdbmsg.diff.gz The is in portage-2.0.49-r13_fixdbmsg.diff, it's changing the portage version to 2.0.49-r13-2, since there is no such ebuild emerge -e will never satisfy the portage-2.0.49-r13 dependency, and will loop forever. I have removed the VERSION change from the patch file. Simply put the attached file in /usr/portage/sys-apps/portage/files/ and emerge -e world or emerge -e system will no longer forever loop. I hope this solves the problem.
Nick, what's up with this 49-r13-2 version ? Also shouldn't it compare the version of the installed package and not the internal portage version ?
Hello Marius, Would changing mysplit=portage.pkgsplit(x[2]) to mysplit=portage.pkgsplit(x[3]) in /usr/bin/emerge at line 1182 solve the problem? I am just curious and don't speak python :-(
nope, x[3] is something completely different as far as I understand that part. I'll attach a patch that will use the package version for the comparison instead of the internal portage version. Either we use that or verify the internal version, but I think the package version is the right thing (tm) to use.
Created attachment 19440 [details, diff] patch to use the package version This patch only fixes the version comparison problem, it still needs a fix for pkgcache in portage.py to work properly (you can just comment the first 4 lines in pkgsplit() to "fix" it).
Isn't it possible to just get rid of the r13-2 version (make it r14 perhaps...) ?
That's possible but it doesn't prevent future errors caused by "invalid" portage versions.
Using the package version doesn't help... as the new one is used after it's merged. Defeats the purpose. You'd have to store it at startup. The version string shouldn't have been like that. My mistake. It'll be fixed in the next maintainence set.
*** Bug 31646 has been marked as a duplicate of this bug. ***
*** Bug 31772 has been marked as a duplicate of this bug. ***
I am getting this with portage-2.0.49-r21 Has it really been fixed ?
I tryed the patch but the same thing happens... This has haunted me for the last 2 days!
The problem with portage-2.0.49-r21 is that it still has version number -r20 inside, resulting in the "emerge -e loop".
when i 'emerge -e system', emerge starts to build all the packages in the system but when he finishes portage-2.0.49-r21 it restarts the unfinished emerge causing a loop. i understand this feature is nice when updating, but not when emerging everything again. it could be included a feature to mark portage from a 'system' or 'world' group to emerge only once or else when portage emerges it will reload all over again.
