When I try to emerge multiple packges in one command for example: emerge maven-bin valgrind argyllcms nodejs The content of /var/lib/portage/world is destroyed and the content is the name of last emerged package. Reproducible: Always Steps to Reproduce: 1. backup /var/lib/portage/world 2. emerge any more then one packages 3. check content /var/lib/portage/world
I'll apply immediate precautionary mask.
+ 11 Feb 2015; Michał Górny <mgorny@gentoo.org> package.mask: + Mask new portage versions because of bug #539746. Applied.
Got hit by this bug yesterday. Afterwards --depclean tried to remove half of my system....
Can confirm, after two randomly chosen packages, world contains only the last entry: # emerge radlib quazip -av (...) $ cat /var/lib/portage/world dev-libs/quazip
Can confirm as well. Emerged two randomly choosen packages and got the same effect.
Can also confirrm, although based on personal experience, it only appears to happen _after_ the last package is merged.
I just did some testing and it seems it is only triggered for new pkgs added to the list. emerging 2 pkgs already in the list, does not re-produce. I do fear that this error will apply to several last releases of portage. I think my world file has been messed with for quite some time and have been avoiding a depclean because of it. I'll try to find out why. I do not recall any code changes in the world file handling for many releases. So, why is this only being discovered now.
(In reply to Brian Dolbec from comment #7) > I do fear that this error will apply to several last releases of portage. I > think my world file has been messed with for quite some time and have been > avoiding a depclean because of it. I'm not sure. Just few days ago I setup a new system with portage-2.2.15, I surely added several new packages using emerge -av name1 name2 ... to the system and /var/lib/portage/world file is OK here. So this is clear 2.2.16 regression.
(In reply to Brian Dolbec from comment #7) > I do fear that this error will apply to several last releases of portage. I > think my world file has been messed with for quite some time and have been > avoiding a depclean because of it. Downgrade to 2.2.15 fixed the problem for me.
OK, found and confirmed it to be commit a4784ffb9406e69811aaf21818459aff00fadb6b I've reverted it in git for now. Ill push out 2.2.17 when we have a proper fix to replace that commit.
(In reply to Brian Dolbec from comment #10) > OK, found and confirmed it to be commit > a4784ffb9406e69811aaf21818459aff00fadb6b > > I've reverted it in git for now. Ill push out 2.2.17 when we have a proper > fix to replace that commit. I have a working fix in the following branch: https://github.com/zmedico/portage/tree/bug_539746 I've posted it for review here: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/5216
This is in the master branch now: https://github.com/gentoo/portage/commit/c3586c5e15c8373d08f9192713a2b03d4542faaf
having patched _sets/files.py <-->def write(self): <--><-->self._pkgset._atoms = self._atoms.copy() <--><-->self._pkgset.write() <--><-->self._setset._nonatoms = self._nonatoms.copy() <--><-->self._setset.write() <-->def load(self): <--><-->self._setAtoms(chain(self._pkgset, self._setset)) --- gives a portage-2.2.16 flawlessly working
and yet -9999 is still hardmasked for this bug? I hit this back in beginning of January, never pieced what happened together. World file can be pretty easily regenerated with a script though. I'm including details below because even if off-topic it might save a lot of frustration. Information here for anyone unfortunate enough to hit this bug: http://forums.gentoo.org/viewtopic-t-869667.html Install eix and uncomment the eix lines in the script... comment out the equery lines and it should work well.
portage-2.2.16 Portage-2.2.17 has been released with all 2.2.16 regressions fixed.
Oops, portage-2.2.16 has been removed from the tree.
