This is what I did: $ emerge rsync $ emerge -pu system $ emerge -u system $ ... use qpkg -d -v to get rid of dups $ emerge -pu world These are the packages that I would merge, in order. Calculating world dependencies -Traceback (most recent call last): File "/usr/bin/emerge", line 1325, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 771, in xcreate if not self.create(myk): File "/usr/bin/emerge", line 643, in create mycheck=portage.dep_check(mydep[myroot],mydbapi) File "/usr/lib/python2.2/site-packages/portage.py", line 2122, in dep_check mydict[x]=1 TypeError: list objects are unhashable Then I tried rm -r /var/cache/edb/dep/* and a new emerge -pu world. No luck. I tried remerging portage, deleting the dep cache; no luck. I have Python 2.2.1-r2 and python-fchksum 1.6.1 installed along with portage version 2.0.28 //Mark
I've tried portage .28,.29,and the .30_alpha, get the same results from all three. emerge rsync ---snip---- wrote 91584 bytes read 1534458 bytes 8765.73 bytes/sec total size is 21404817 speedup is 13.16 >>> Updating Portage cache... Traceback (most recent call last): File "/usr/bin/emerge", line 1325, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 771, in xcreate if not self.create(myk): File "/usr/bin/emerge", line 696, in create self.create(myk,parent) File "/usr/bin/emerge", line 696, in create self.create(myk,parent) File "/usr/bin/emerge", line 643, in create mycheck=portage.dep_check(mydep[myroot],mydbapi) File "/usr/lib/python2.2/site-packages/portage.py", line 2119, in dep_check mylist=dep_listcleanup(dep_zapdeps(mysplit,mysplit2)) File "/usr/lib/python2.2/site-packages/portage.py", line 1880, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/python2.2/site-packages/portage.py", line 1864, in dep_zapdeps if unreduced[0]=="||": IndexError: list index out of range emerge -pu world These are the packages that I would merge, in order. Calculating world dependencies -Traceback (most recent call last): File "/usr/bin/emerge", line 1325, in ? if not mydepgraph.xcreate(myaction): File "/usr/bin/emerge", line 771, in xcreate if not self.create(myk): File "/usr/bin/emerge", line 696, in create self.create(myk,parent) File "/usr/bin/emerge", line 696, in create self.create(myk,parent) File "/usr/bin/emerge", line 643, in create mycheck=portage.dep_check(mydep[myroot],mydbapi) File "/usr/lib/python2.2/site-packages/portage.py", line 2119, in dep_check mylist=dep_listcleanup(dep_zapdeps(mysplit,mysplit2)) File "/usr/lib/python2.2/site-packages/portage.py", line 1880, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/python2.2/site-packages/portage.py", line 1864, in dep_zapdeps if unreduced[0]=="||": IndexError: list index out of range
Did some playing around right now - it appears to be a combination of -pu world that portage is dying on. I can do an emerge -p world, and emerge -u world, or an emerge -pu system without any incident. It is only the combination of emerge -pu world that bombs out with the below error messages (the rsync error went away during a new rsync).
For me the problem seems to be in certain ebuilds that don't work. After an rsync I got the problem. But trying everything from world shows that some ebuilds fail with this error.
i can confirm this on 28, 29 and 30_alpha* too emerge world --> ok emerge -u world --> NOT ok (TypeError) emerge -p world --> ok emerge -up world --> NOT ok (TypeError)
*** Bug 7129 has been marked as a duplicate of this bug. ***
I did a emerge -p -u on each package in my world file and got the results that can be seen at http://stuwww.kub.nl/~s920851/portageerror Before each emerge I did an echo of the package name. Tracing the errors I finally ended up at the postgresql-7.2.2 ebuild. The culpit is the following line: x86? ( java? ( =virtual/jdk-1.3* >=dev-java/ant-1.3 ) ) See the double use dependency. Well portage-2.0.28 has a problem with that. Change the above line into: java? ( =virtual/jdk-1.3* >=dev-java/ant-1.3 ) and everything will work like a charm again. Of course the above is a workaround, and portage might need to support the above construction, but the removal of this error should go first.
I get the same traceback but I can't even do a non-pretend --update world.
Checked in the temporary change to postgresql build as mentioned above and at least I can --update world again
Ditto on the postgres line. Is this bad syntax in the ebuild?
These deps are valid; Portage.py was missing a call to flatten() to flatten the list before processing it. Will be fixed in Portage 2.0.30.
