Reproducible: Always Steps to Reproduce: 1. emerge py-rrdtool Actual Results: !!! object doesn't support item deletion !!! 'rm -Rf /usr/portage/profiles; emerge sync' may fix this. If it does !!! not then please report this to bugs.gentoo.org and, if possible, a dev !!! on #gentoo (irc.freenode.org) Expected Results: emerge py-rrdtool "emerge info" doesn't work
I get the same error after I did an "emerge sync" this morning.
Same here Comment #2. Deleting the profiles dir and re-sync does not help. Error stays the same
Update: I am experiencing this issue with portage-2.0.50-r10.
What does the following give? ls -l /etc | grep make.profile
make.profile -> /usr/portage/profiles/default-linux/x86/2004.2/gcc34/2.6
Ok, this did the trick for me: Switch the symlink (/etc/make.profile) back to '/usr/portage/default-x86-2004.2'. Upgrade to newest (masked) portage which is 2.0.51_pre20 atm. Link /etc/make.profile to '/usr/portage/profiles/default-linux/x86/2004.2/gcc34/2.6' again. Portage Team: please confirm this, ymmv Cheers, Marc.
*** Bug 62945 has been marked as a duplicate of this bug. ***
ok, seems there is a bug in 2.0.50 parsing cascaded profiles, the make.defaults files are adjusted to this, thanks to jstubbs please sync 35 mins after reading this comment and test with your portage 2.0.50-r10 thank you Daniel
Problem persists - tried again just five minutes ago.
the problem is in the CFLAGS in make.defaults 2.0.50 reacts to them differently than 2.0.51 i took out CFLAGS for now until i get a chance to get some longer talk with carpaski in regards to cascading profiles
It may be quicker for 2.0.51 to come out than to fix this "broken" (read: historically incorrect) CFLAGS. The backport would be fairly sizable to update the cascade functions. I recommend using 51, unless -r12 happens to have the backport.
Use 51 for cascades.
*** Bug 69203 has been marked as a duplicate of this bug. ***