This is the error. Environment settings, python version and portage version stated below. astarte mail # emerge -uD world -p These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] sys-apps/procps-3.1.14 [3.1.13] [ebuild N ] dev-php/mod_php-4.3.3-r2 [ebuild U ] sys-apps/findutils-4.1.20-r1 [4.1.20] [ebuild U ] net-misc/wget-1.9 [1.8.2-r3] Traceback (most recent call last): File "/usr/bin/emerge", line 2133, in ? mydepgraph.display(mydepgraph.altlist()) File "/usr/bin/emerge", line 1103, in display elif (not "--emptytree" in myopts) and portage.db[x[1]]["vartree"].exists_specific_cat(x[2]): File "/usr/lib/python2.2/site-packages/portage.py", line 3469, in exists_specific_cat self.invalidentry(self.root+"var/db/pkg/"+a[0]+"/"+x) AttributeError: vartree instance has no attribute 'invalidentry' astarte mail # python version 2.2.3-r4 portage version 2.0.49-r15 nothing special in /etc/make.conf (well there's accept_keywords="~x86")
*** Bug 31904 has been marked as a duplicate of this bug. ***
*** Bug 31986 has been marked as a duplicate of this bug. ***
I can confirm the problem. python version 2.2.3-r1 portage version 2.0.49-r15
python's up to r4 now. After updating it, can anyone confirm it no longer happens now? Cheers, Mark
nope, even with python 2.2.3-r4 I get the same results. (maybe it has something to do something to do with portage 2.0.49-r15 ?)
yup, I encountered it the first time after the portage update
I solved the problem for me: I was sure that there is something wrong with the portage database, so I tried /usr/lib/portage/bin/fix-db.py and got this error: ERROR: Package directory is empty for 'app-editors/-MERGING-vim-6.2-r3' Deleting this directory. Remerge if you want it back. I looked into /var/db/pkg/app-editors and there was a file "-MERGING-vim-6.2-r3.portage_lockfile", looks like portage didnt deleted it when i installed vim the last time. I reemerged vim and the error in #1 was gone. Try the fix-db.py script or look for *portage_lockfile in /var/db and see if it helps.
*** Bug 31803 has been marked as a duplicate of this bug. ***
*** Bug 32305 has been marked as a duplicate of this bug. ***
The /usr/lib/portage/bin/fix-db.py and deleting the lockfile method fixed it for me as well.
Is the vartree class supposed to lack the method called 'invalidentry' though, this is what generates the exception (if this is a way of propagating an error, its a dirty one).
Sorry, wrong bug
Deleting /var/db/pkg/*portage_lockfile worked for me as well, as far as letting emerge -up world succeed. But running emerge -p koffice would cause the error again. It caused -MERGING-jbigkit-1.4.portage_lockfile to re-appear in the /var/db/pkg/media-libs folder every time it ran. Finally, I deleted the file and then emerged jbigkit. After that, I haven't had any issues, and both emerge -p koffice and emerge -up world work fine. Note that emerge -p imagemagick was causing the same issue as well, so I think there was a string of dependencies in there and one of the ebuilds was bad.
so who is going to assign this bug anyway? In the mean time, my problems vanished. I'd like you who are still having these problems to delete lock files (they are only required during portage install), then re-emerge python and after that portage, then look again to see if this problem re-occurs. It can't hurt to try anyway.
*** Bug 32736 has been marked as a duplicate of this bug. ***
I had the same problem, re-emerged python and then protage as Mark requested, and the problem did NOT recur :-)
*** Bug 33367 has been marked as a duplicate of this bug. ***
/usr/lib/portage/bin/fix-db.py Crashes for me: # /usr/lib/portage/bin/fix-db.py ERROR: Package directory is empty for 'sys-devel/-MERGING-gnuconfig-20030708' Deleting this directory. Remerge if you want it back. Traceback (most recent call last): File "/usr/lib/portage/bin/fix-db.py", line 54, in ? pkgdirlist = os.listdir(pkgdir) OSError: [Errno 20] Not a directory: '/var/db/pkg/sys-devel/-MERGING-gnuconfig-20030708.portage_lockfile/' however a rm /var/db/pkg/*/*lock* did the trick
This bug seems to have outdated itself. Please notice me if I have to reopen it.
I actually just fixed the syntax errors in the cvs version of portage.py. (22 Nov '03)
*** Bug 34157 has been marked as a duplicate of this bug. ***
*** Bug 34207 has been marked as a duplicate of this bug. ***
how is this a resolved, when machines out there, who try to emerge -up world cant? This is something that should be fixed, drobbins said he looked at it and it was doing something it shouldn't have. Ask him for more details. I don't believe a quasi-work-around qualifies as being fixed.
Actually drobbins said he fixed it. I don't quite understand why you reopened this bug Kevyn?
Created attachment 21225 [details, diff] drobbins' changes This is the diff between cvs versions 1.346 and 1.347 which has the changes that drobbins made and should fix the problem until the change is incorporated in the next portage release, which should be soon.
CVS contains the fix for this bug and carpaski has knowledge of this bug -- so it should appear in an upcoming release of portage (possibly -r17, I'm trying to comfirm this).
Mark, My bug got rolled into this one as a duplicate, and someone saying they fixed it, and commiting code to portage is not a fix. A fix is when it gets to the users and can be verifed fixed. Thats why I re-opened it. It's not yet fixed. The problem still occurs. And will do so until a new version of portage is released. Patches while ok for work-arounds, don't actually fix the orginal problem. Maybe I'm too used to doing bugs the commercial way, with a real QA process where bugs don't get closed until they are verified fixed....it just seems really short sighted to close bugs when the shipping code is still broken. If this bug needs to be re-assigned to the person in charge of incorporating the fix into portage, then so be it. But I don't feel this should be closed just because someone did a cvs up on a patch they created. If they feel like adding it to the portage ebuild, sure. But until then, It's not fixed.
Don't know Kevyn. As far as I know the 'Good Way[tm]' is to resolve this bug because it has been fixed by drobbins now. Though it's not in portage /yet/, when I see the fix is working, I should confirm it (Or whoever has the rights to do so). This is, I guess, why Jason resolved it, which I would do as well. So you see, > My bug got rolled into this one as a duplicate, and someone saying they fixed > it, and commiting code to portage is not a fix. A fix is when it gets to the > users and can be verifed fixed. Not true imho. A fix is when the code has been fixed. If a new problem occurs create a new bug. If this problem re-occurs /after/ people have checked it, reopen it. This is all I will say about it though, you're the dev so you decide what to do now. Critisism is welcome btw so if I misunderstood let me know.
wrong, it's fixed when the fix arrives at the user.
It's a matter of opinion, technically the bug *is* fixed. Perhaps we should develope a gentoo bug closing policy from this... :)
The DRobbins patch fixed this for me.
*** Bug 34349 has been marked as a duplicate of this bug. ***
*** Bug 34532 has been marked as a duplicate of this bug. ***
*** Bug 34729 has been marked as a duplicate of this bug. ***
*** Bug 34955 has been marked as a duplicate of this bug. ***
I filed a bug report on this that was marked as a duplicate, Bug 34955, and had a little different take on the bug. I got the same traceback that you all did on an 'emerge -p', but what was causing it for me was a dependency in the ebuild on 'virtual/linux-sources' There wasn't any virtual/linux-sources entry in my /var/cache/edb/virtuals As soon as I added that entry, 'emerge -p' worked just fine. Check out Bug 34955 for a more detailed account.
*** Bug 35495 has been marked as a duplicate of this bug. ***
AOL Same problem here. I'm on Portage 2.0.49-r18, so patch wasn't even close to go in. Hand-changed 3 references in vartree instead, and left the two in vardbapi. Anyway, I also needed to fix the invalidentry-function itself. It tried to do something like this: match = re.search(".*/-MERGING-(.*)",mypath) if match: writemsg(red("INCOMPLETE MERGE:")+match[0]+"\n") Barfing on match[0]. Changed to match = re.search(".*/-MERGING-(.*)",mypath) if match: writemsg(red("INCOMPLETE MERGE:")+match.group(1)+"\n") Not quite sure if the if-statement there will skip on a non-match or not, I'm not a python-coder. At least now my portage manages to emerge --pretend, for the first time in weeks.
So, may this bug be closed yet?
sorry -- you said -r18 and I misread it as -r15, so denote that last comment plz :)
*** Bug 36232 has been marked as a duplicate of this bug. ***
could a dev give a status update on this bug?
well, if you look at the Keywords on this bug, you'll see 'InCVS' ... this is fixed with 2.0.50_preX, perhaps just not with 2.0.49-rXX ? i dont know because i'm using 2.0.50_preX
This error happened to me just yesterday again, on a computer that had portage 2.0.49-r18, when doing 'emerge -pu portage'. I have upgraded to 2.0.49-r20 now and the error does not appear any longer, thus it seems to me upgrading to 2.0.49-r20 is enough.
I hope this isn't something that's been dealt with, but I think the problems I'm getting are re: this bug. When I emerge a package, I get !!! Couldn't find match for app-portage/ufed !!! Invalid db entry: /var/db/pkg/*sys-fs/devfsd (repeated three times) This is after emerge ufed -- however, the emerge succeeds. emerge -pv portage [ebuild R ] sys-apps/portage-2.0.49-r21 -build
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
