While trying to update/emerge gentoolkit or any other packages emerge crashes. Everything has begun after the last portage update. Reproducible: Always Steps to Reproduce: 1.emerge sync 2.emerge -u portage 3.emerge -u gentoolkit Actual Results: # emerge -u gentoolkit Traceback (most recent call last): File "/usr/bin/emerge", line 14, in ? import portage File "/usr/lib/portage/pym/portage.py", line 6111, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1384, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"]) File "/usr/lib/portage/pym/portage.py", line 1122, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no") File "/usr/lib/portage/pym/portage.py", line 3301, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3044, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3030, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' Expected Results: emerge/update of the gentoolkit or any other package. emerge info is also broken, however I still can provide you with some info manually. CFLAGS="-O3 -march=athlon-xp -funroll-loops -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" USE="-gnome"
sry that i couldnt add the portage version earlier however by the time i wrote the bug report everything was broken. I installed the portage-rescue and I'm able to tell now that it was portage version 2.0.50. But since then i get this error message when i try to emerge the latest portage version again. # emerge portage Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/portage-2.0.50 to / >>> md5 ;-) portage-2.0.50.tar.bz2 ACCESS DENIED open_wr: /etc/passwd ACCESS DENIED open_wr: /etc/passwd >>> Unpacking source... >>> Unpacking portage-2.0.50.tar.bz2 to /var/tmp/portage/portage-2.0.50/work >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-portage-2.0.50-22850.log" open_wr: /etc/passwd open_wr: /etc/passwd open_wr: /etc/group open_wr: /etc/passwd -------------------------------------------------------------------------------- at least info works again :) Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r9) ================================================================= System uname: 2.4.20-gentoo-r8 i686 AMD Athlon(tm) XP 2000+ GENTOO_MIRRORS="http://gentoo.oregonstate.edu/ http://distro.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss apm avi crypt cups encode foomaticdb gif gtk2 jpeg gnome libg++ libwww mad mikmod mpeg ncurses nls pdflib png quicktime slang spell truetype xml2 xmms xv zlib gdbm berkdb readline arts svga tcltk X sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl cdr" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-O2 -mcpu=i686 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Hmm, from my understanding of the code logic this bug is not possible. If anyone still has the problem please say and don't use the rescue so we can try to reproduce it (otherwise we can't fix it).
There is a portage-2.0.50-r1 rescue tarball available. See the readme.
Someone still needs info on this, cause i have this problem as well. To rescue or not to rescue ?
retracting that offer, can't do without portage on my main machine for long.
The original problem is not fixed in -r1
genone: Can you reproduce thie bug in -r1? I can't in my environment..
This bug seems to affect users at random, I was never affected by it but I'm currently investigating it with some users and they assured me that it's not fixed with -r1.
I found the problem and fixed it in CVS.
*** Bug 41373 has been marked as a duplicate of this bug. ***
*** Bug 40763 has been marked as a duplicate of this bug. ***
Bug 41373 was marked as duplicate. I'm copying my comment on it. ---- I guess I fixed this bug (but it haven't been released yet). I'd like to confirm the fix can fix in several cases. So, can you try the patch? It's just one line. Line 3029 in /usr/lib/portage/pym/portage.py.(2.0.50-r1) From if portdbapi: To if myportapi:
Hello Masatomo, The problem still persists. I made the changes that you recommended. After saving the file when I run emerge world ...nothing happens.
hmm, Can you shom me the Traceback?
Can you tell me what you would like me to execute. I am not too good with these things. Sorry Peace, Shoan.
I guess you fail to emerge with Traceback message like comment #1. We'd like to see the Traceback message. It helps us to resolve this problem.
I am actually not getting any message. Below is what happens gentoo root # emerge world and thats it. It just stays like that. No message and it doesn't return to prompt/shell. Peace, Shoan.
emerge behaves as mentioned by Shoan. Therefore I hit Ctrl-C and got the following Traceback. I hope this helps. (btw: 1: emerge consumes no cpu while it hangs 2: etc-update works after patching the portage.py ) # emerge --info Traceback (most recent call last): File "/usr/bin/emerge", line 278, in ? tmpsettings = portage.config(clone=portage.settings) File "/usr/lib/portage/pym/portage.py", line 1301, in __init__ self.regenerate() File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): File "/usr/lib/portage/pym/portage.py", line 4714, in match return self.xmatch("match-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 4701, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep,mykey)) File "/usr/lib/portage/pym/portage.py", line 4687, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 4782, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 4545, in aux_get mylock = lockfile(mydbkey,unlinkfile=1) File "/usr/lib/portage/pym/portage.py", line 89, in lockfile fcntl.flock(myfd,fcntl.LOCK_EX) KeyboardInterrupt
I also have the same problem after updating portage: sys-apps/portage selected: 2.0.49-r21 protected: 2.0.50-r1 omitted: none jstubbs from irc guided me to change: Line 3029 in /usr/lib/portage/pym/portage.py.(2.0.50-r1) From if portdbapi: To if myportapi: I have the same problem as noted in Comment #18 etc-update runs - anything emerge just hangs - ctrl-c gives this: bash-2.05b# emerge -dup Traceback (most recent call last): File "/usr/bin/emerge", line 278, in ? tmpsettings = portage.config(clone=portage.settings) File "/usr/lib/portage/pym/portage.py", line 1301, in __init__ self.regenerate() File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): File "/usr/lib/portage/pym/portage.py", line 4714, in match return self.xmatch("match-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 4701, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep,mykey)) File "/usr/lib/portage/pym/portage.py", line 4687, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 4782, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 4547, in aux_get myret=doebuild(myebuild,"depend","/",self.mysettings,dbkey=mydbkey) File "/usr/lib/portage/pym/portage.py", line 2073, in doebuild mysettings.reset(use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1338, in reset self.regenerate(use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): File "/usr/lib/portage/pym/portage.py", line 4714, in match return self.xmatch("match-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 4701, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep,mykey)) File "/usr/lib/portage/pym/portage.py", line 4687, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 4782, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 4545, in aux_get mylock = lockfile(mydbkey,unlinkfile=1) File "/usr/lib/portage/pym/portage.py", line 89, in lockfile fcntl.flock(myfd,fcntl.LOCK_EX) KeyboardInterrupt
I couldnt do without the portage for so long, so I had to rescue it. I initially tried to portage-rescue-2.0.50-r1-x86.tbz2 but that did not work for me as the same error persisted. Later downloaded portage-rescue-2.0.47-r10-x86.tbz2 and rescued using it. That worked for me. I deleted the portage tar ball from /usr/portage/distfiles and did an emerge sync. After doing so, I emerge the portage again and this time it worked. :) But now each time I do a emerge world I get the following: gentoo root # emerge world -pv These are the packages that I would merge, in order: !!! Invalid db entry: /var/db/pkg//sys-kernel !!! Invalid db entry: /var/db/pkg//sys-devel !!! Invalid db entry: /var/db/pkg//sys-apps !!! Invalid db entry: /var/db/pkg//sys-libs !!! Invalid db entry: /var/db/pkg//dev-lang !!! Invalid db entry: /var/db/pkg//dev-libs !!! Invalid db entry: /var/db/pkg//dev-python !!! Invalid db entry: /var/db/pkg//app-arch !!! Invalid db entry: /var/db/pkg//app-shells <snip> !!! Invalid db entry: /var/db/pkg//x11-base !!! Invalid db entry: /var/db/pkg//dev-util !!! Invalid db entry: /var/db/pkg//x11-libs !!! Invalid db entry: /var/db/pkg//gnome-base !!! Invalid db entry: /var/db/pkg//x11-wm !!! Invalid db entry: /var/db/pkg//media-video !!! Invalid db entry: /var/db/pkg//dev-java !!! Invalid db entry: /var/db/pkg//net-www !!! Invalid db entry: /var/db/pkg//media-sound !!! Invalid db entry: /var/db/pkg//net-im !!! Invalid db entry: /var/db/pkg//app-text !!! Invalid db entry: /var/db/pkg//net-nds !!! Invalid db entry: /var/db/pkg//x11-themes !!! Invalid db entry: /var/db/pkg//net-print !!! Invalid db entry: /var/db/pkg//dev-perl !!! Invalid db entry: /var/db/pkg//gnome-extra !!! Invalid db entry: /var/db/pkg//net-ftp !!! Invalid db entry: /var/db/pkg//x11-plugins !!! Invalid db entry: /var/db/pkg//media-plugins !!! Invalid db entry: /var/db/pkg//app-crypt !!! Invalid db entry: /var/db/pkg//x11-terms !!! Invalid db entry: /var/db/pkg//media-gfx !!! Invalid db entry: /var/db/pkg//app-dicts !!! Invalid db entry: /var/db/pkg//app-portage !!! Invalid db entry: /var/db/pkg//net-analyzer !!! Invalid db entry: /var/db/pkg//app-office !!! Invalid db entry: /var/db/pkg//net-irc !!! Invalid db entry: /var/db/pkg//app-vim !!! Invalid db entry: /var/db/pkg//net-firewall !!! Invalid db entry: /var/db/pkg//net-libs !!! Invalid db entry: /var/db/pkg//dev-db !!! Invalid db entry: /var/db/pkg//dev-php !!! Invalid db entry: /var/db/pkg//net-fs !!! Invalid db entry: /var/db/pkg//kde-base !!! Invalid db entry: /var/db/pkg//app-doc !!! Invalid db entry: /var/db/pkg//net-wireless *** Package in world file is not installed: //net-www/mozilla-firebird ...done! [ebuild U ] sys-kernel/genkernel-3.0.1_beta12 [3.0.1_beta11] 0 kB [ebuild U ] x11-base/xfree-4.3.0-r5 [4.3.0-r4] -3dfx -3dnow -cjk -debug -doc -ipv6 -mmx +nls +pam -sdk -sse -static +truetype +xml2 17,522 kB [ebuild U ] sys-apps/hotplug-20040105 [20030805-r3] 56 kB Total size of downloads: 17,579 kB gentoo root # But the emerge works nonetheless. Anything I/you can do to fix the "Invlid db entry"?
Besides my previous comment, another thing that I noticed is that after I did emerge world on rebooting my machine I noticed that all configurations were back to default. /etc/conf.d/net /etc/fstab /etc/group /etc/modules.autoload.d/kernel-2.6 /etc/rc.conf
I emerged portage-2.0.50-r1 again (using portage-2.0.49-r21) this time logging the output and found: ... Recalculating the counter... FAILED to update counter. !!! This is a problem. ccache Traceback (most recent call last): File "<string>", line 2, in ? File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' ... Thereafter I changed portdbap to myportapi in line 3029 of portage.py before building the package: # ebuild /usr/portage/sys-apps/portage/portage-2.0.50-r1.ebuild unpack # emacs /var/tmp/portage/portage-2.0.50-r1/work/portage-2.0.50-r1/pym/portage.py # touch /var/tmp/portage/portage-2.0.50-r1/.compiled # ebuild /usr/portage/sys-apps/portage/portage-2.0.50-r1.ebuild merge result: ... Recalculating the counter... Counter updated successfully. ... But still emerge hangs as before.
*** Bug 41734 has been marked as a duplicate of this bug. ***
I also tried the fix as proposed below by swapping the one line of code with the other proposed one, and now my emerge rsync, python-updater, etc, hang just as described by others. Also, when I interrupt it with CNTRL-C I also get the same traceback. What is the solution to this problem?
I just found the way to reproduce this bug. (Thanks to higuchi) In /var/cache/edb/virtuals: virtual/jre dev-java/sun-jdk But sun-jdk was already removed. In this case, this bug happens. (I guess it happened in old Portage. I know old portage often didn't remove package from the virtuals file.) This bug should be fixed in comment #12 patch. Or you can fix by removing sun-jdk from /var/cache/edb/virtuals . But I can't reproduce the hang thing.. I guess it's temporary problem by lock process.
I removed all java entries from /var/cache/edb/virtuals. Then I updated portage. It works fine now. (no hanging anymore.) Thanks!
Removing the java lines from that file fixed it for me also. The hanging no longer occurs. What an odd problem. Maybe someone can explain why that might have caused portage to hang?
Pulling everything Java from mine worked for me too.
I forgot to say. /usr/lib/portage/bin/fixvirtuals also fixes your virtuals file.
*** Bug 42230 has been marked as a duplicate of this bug. ***
I saw this same thing in a different way. After unmerging blackdown-jre and blackdown-jdk, I saw the Traceback in the bug description everytime emerge ran to do anything. The patch to line 3092 of python.py completely fixed this without needing to edit the virtuals file.
No one here ever mentioned how long emerge hung for... If it wasn't over 10 minutes, then I wouldn't call that a legitimate hang, unless you can identify the exact location in code where this occurs.
For me it would hang indefinitely.
it would hang indefinitely.
*** Bug 45377 has been marked as a duplicate of this bug. ***
Hello everyone. I'd like to submit my own experience with this bug - since it seems to be a little different from the one submitted before. First, emerge doesn't hang with me. Just returns the traceback and exit. The problem began at the end of the "emerge sync" procedure, to be exact, after the ">>> Updating Portage cache... ...done!" step. I looked into /var/cache/edb/virtuals but no reference to jre, sun, java or anything else related. Here is the traceback that pops when calling emerge: Traceback (most recent call last): File "/usr/bin/emerge", line 14, in ? import portage File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' I found interesting that calling /usr/lib/portage/bin/fixvirtuals returns the same traceback (the first line is a bit different, you should guess why ;), fixpackages returns the same... I would have liked to install one of the fixes, but since they are tbz2 and that even "emerge --version" doesn't work, I'm a bit stuck with that.
The cause was due to to packages listed in /var/cache/edb/virtuals not actually being installed. Here's a crude script for you to check: cd /var/db/pkg for i in `cat /var/cache/edb/virtuals | awk '{print $2}'`; do ls $i* > /dev/null 2>&1 || echo $i; done The problem is definitely fixed in -r4 as I found that I have a bogus virtual by using this but my portage is working fine. What version are you using? You can find out from /var/db/pkg/sys-apps/portage-2.0.xx
We have the exact same problem as in comment #36 on our new server which went into production today. :( After migrating all the data, a final "emerge sync" killed Portage. Here's the traceback: Traceback (most recent call last): File "/usr/lib/portage/bin/fixvirtuals", line 9, in ? import portage File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' Exact same traceback for etcat, env-update and the likes. Downloaded portage-rescue-2.0.50-r1-x86.tbz2 and used it according to README.RESCUE, but the problem still persists. :-(
see bug 47063
I think my problem is similar to bug#47063 Traceback (most recent call last): File "/usr/bin/emerge", line 14, in ? import portage File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' Portage 2.0.50-r3
Same problem here. The fix in comment 19 didn't help, neither did removing all sun-jdk entries from /var/cache/edb/virtuals. venus root # emerge sync Traceback (most recent call last): File "/usr/bin/emerge", line 14, in ? import portage File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match'
The same bug appears while trying to install a new system with livecd and stage2- and stage3-tarballs downloaded this morning resp. this afternoon (on a Pentium 4). I followed the instructions in the documentation, have just chroot'ed to /mnt/gentoo and downloaded the portage tree with "emerge sync". Any consecutive call to emerge shows the traceback as in comment #36. Note: the script from comment #37 show gzip, nano and python (don't know if that helps).
See my patch in http://bugs.gentoo.org/show_bug.cgi?id=42230 It should fix the matter at least for people with production systems that need to be up and running 24/7. In my opinion, it should be a matter of good programming style to avoid such undefined conditions, even more in python, which otherwise tends to become spaghetti. Regards, Torsten
I've the same problem on my AlphaStation after an emerge sync few minutes ago. # emerge sync <cut> Number of files: 80515 Number of files transferred: 608 Total file size: 62886683 bytes Total transferred file size: 1035255 bytes Literal data: 1035255 bytes Matched data: 0 bytes File list size: 1771262 Total bytes written: 12345 Total bytes read: 2834308 wrote 12345 bytes read 2834308 bytes 6491.80 bytes/sec total size is 62886683 speedup is 22.09 >>> Updating Portage cache... ...done! Traceback (most recent call last): File "/usr/bin/emerge", line 2250, in ? reload(portage) File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cac he) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match Every emerge command fail with this error. I use portage-2.0.50-r3 and the profile default-alpha-2004.0 /etc/make.conf : # These settings were set by the catalyst build script that automatically built this stage CFLAGS="-mcpu=ev4 -O3 -mieee -pipe" CHOST="alpha-unknown-linux-gnu" USE="apache2 berkdb mysql mbox xml2 xml perl -X -qt -kde -arts -oss -gnome -xmms -avi -cups -java -quicktime -gtk -gtk2 -oggvorbis -encode -foomaticdb -xv -mpeg -motif -mikmod -opengl" CXXFLAGS="${CFLAGS}" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" GENTOO_MIRRORS="ftp://sunsite.cnlab-switch.ch/mirror/gentoo http://gentoo.oregonstate.edu/" ACCEPT_KEYWORDS="alpha" This system was installed yesterday with this stage3 <ftp://ibiblio.org/pub/Linux/distributions/gentoo/experimental/alpha/stages/stage3-alpha-20040313.tar.bz2>
I tried <a href="http://bugs.gentoo.org/show_bug.cgi?id=40831#c19">Comment #19</a>'s suggestion of replacing 'portdbapi' to 'myportapi' on line 3029 in file '/usr/lib/portage/pym/portage.py' and that seemed to fix everything for me. I am currently using portage version 2.0.50-r1, and given the current circumstances, will not update for a little while. I was able to do an emerge rsync and -up world just fine. I'm also gonig to refrain from performing upgrades, just as a pre-caution. Just thought I'd give that update because it seems as if that fix is working for some people and not others?
Torsten, I don't think your patch will fix anything because above in that block if/else you have: if myportapi: for x in candidate: if( type(x)==types.ListType): Note the first line. In my file, that was on line 3030, I think you're working off of a different version than I. I'm currently using 2.0.50-r1. So, 'myportapi' is already checked to see if it already defined....
Similar problems here, after emerge sync nothing worked. Patch in 42230 seems to fix this, no problems anymore. Portage 2.0.50-r3 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.3-gentoo-r1)
fixed it for me too Portage 2.0.50-r3 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.4.24-hardened-r1)
Akshai, in fact, the critical line in 2.0.50-r1 is 3038. Seems like you are already using a patched version, since the line 3030 (with some fuzz around) looks like follows for me: --- snip --- #use not masked pkg if portdbapi: for x in candidate: if (type(x)==types.ListType): --- snap --- Seems that you already have the fix from comment #19 applied. I didn't do that, since it seems too risky to virtually hide a full tree of if/elif statements by changing a variable name here. My patch only "fixes" the last elif in case of myportapi == None. Regards, Torsten
I only applied this: http://bugs.gentoo.org/attachment.cgi?id=25970&action=view
Torsten, Ah, of course, you're correct. I had already made code changes from Comment #19. I didn't realize that. Thanks.
Today I upgraded to portage-2.5.0-r3 in two of my machines, and after that I couldn't use emerge, I got the same traceback described in this bug in both machines. I have "real" /usr/portage on one machine (server) and mount it over nfs on the other (firewall). After unmounting /usr/portage on firewall I could use emerge as normal, so I issued an "emerge sync" and after this I get the same error again... so I think there should be something wrong in the portage tree. Anyone is experiencing this problem or is just me?
Applying the pattch mentioned in comment #50 fixed the problem for me!
I get the same exact traceback as comment 1 when I follow stage 2 install from http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=0&chap=0. Using the stage2 for the i686 package. Step number 6a: "emerge sync". It goes through and says it's all done, but when it usually does the "Performing Global Updates" it instead crashes with traceback in comment #1. >>> Updating Portage cache... ...done! Traceback (most recent call last): File "/usr/bin/emerge", line 2250, in ? reload(portage) File "/usr/lib/portage/pym/portage.py", line 6128, in ? settings.regenerate() # XXX: Regenerate use after we get a vartree -- GLOBAL File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi.match(x): AttributeError: 'NoneType' object has no attribute 'match' I then applied patch from comment #50 and tried "emerge sync" again. It went ahead and did the "Performing Global Updates": livecd / # vi /usr/lib/portage/pym/portage.py bash: vi: command not found livecd / # nano -w !$ nano -w /usr/lib/portage/pym/portage.py livecd / # emerge sync Performing Global Updates: /usr/portage/profiles/updates/1Q-2003 (Could take a couple minutes if you have a lot of binary packages.) .='update pass' *='binary update' @='/var/db move' s='/var/db SLOT move' S='binary SLOT move' .......................... Performing Global Updates: /usr/portage/profiles/updates/1Q-2004 (Could take a couple minutes if you have a lot of binary packages.) .='update pass' *='binary update' @='/var/db move' s='/var/db SLOT move' S='binary SLOT move' ......................................... Performing Global Updates: /usr/portage/profiles/updates/2Q-2004 (Could take a couple minutes if you have a lot of binary packages.) .='update pass' *='binary update' @='/var/db move' s='/var/db SLOT move' S='binary SLOT move' ................. and then it freezes. When I ctrl-c out of it I get the traceback in comment #18. Traceback (most recent call last): File "/usr/bin/emerge", line 278, in ? tmpsettings = portage.config(clone=portage.settings) File "/usr/lib/portage/pym/portage.py", line 1301, in __init__ self.regenerate() File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi and myportapi.match(x): File "/usr/lib/portage/pym/portage.py", line 4714, in match return self.xmatch("match-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 4701, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep,mykey)) File "/usr/lib/portage/pym/portage.py", line 4687, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 4782, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 4547, in aux_get myret=doebuild(myebuild,"depend","/",self.mysettings,dbkey=mydbkey) File "/usr/lib/portage/pym/portage.py", line 2073, in doebuild mysettings.reset(use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1338, in reset self.regenerate(use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1392, in regenerate self.configdict["auto"]["USE"]=autouse(db[root]["vartree"],use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 1121, in autouse myresult=dep_check(mydep,myvartree.dbapi,None,use="no",use_cache=use_cache) File "/usr/lib/portage/pym/portage.py", line 3309, in dep_check mylist=flatten(dep_listcleanup(dep_zapdeps(mysplit,mysplit2))) File "/usr/lib/portage/pym/portage.py", line 3052, in dep_zapdeps myresult=dep_zapdeps(unreduced[x],reduced[x]) File "/usr/lib/portage/pym/portage.py", line 3038, in dep_zapdeps elif myportapi and myportapi.match(x): File "/usr/lib/portage/pym/portage.py", line 4714, in match return self.xmatch("match-visible",mydep) File "/usr/lib/portage/pym/portage.py", line 4701, in xmatch myval=match_from_list(mydep,self.xmatch("list-visible",None,mydep,mykey)) File "/usr/lib/portage/pym/portage.py", line 4687, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 4782, in gvisible myaux=db["/"]["porttree"].dbapi.aux_get(mycpv, ["KEYWORDS"]) File "/usr/lib/portage/pym/portage.py", line 4545, in aux_get mylock = lockfile(mydbkey,unlinkfile=1) File "/usr/lib/portage/pym/portage.py", line 89, in lockfile fcntl.flock(myfd,fcntl.LOCK_EX) KeyboardInterrupt Just tried it from stage 1 and got the same results. Is there a workaround that I can do so I can get gentoo installed?
FYI : Building a fresh machine here and applying the patch mentioned in comment 50 does nothing but cause portage to hang and do nothing. Can't even get output from 'emerge info'. This appears to have taken out 4 machines here (with 15 more to go). The patch does nothing on all machines.
Update to comment #54. Workaround for fresh intalls: Comment out lines 3038 and 3039. So, change: elif myportapi.match(x): return x To: #elif myportapi.match(x): #return x Then run "emerge sync". Then uncomment lines 3038 and 3039 and apply patch from comment #50. Ugh!
I did #55, but after --sync and uncomment, the bug is back again.
Commenting out lines 3038,3039 of /usr/lib/portage/pym/portage.py fixed my first problem for me so I could do an emerge sync and upgrade to portage-2.0.50-r3. Then I applied the patch at http://bugs.gentoo.org/attachment.cgi?id=25970&action=view and had a working portage system again.
comment #12 also works.
comment #58 worked for me too.
I experienced the same problem as in #54. The workaround in #56 seemed to fix it, but: I'm trying to install from stage1. When I run /usr/portage/scripts/bootstrap.sh as in step 6.c (Code Listing 11) I get the error again and my changes to /usr/lib/portage/pym/portage.py are undone.
This worked for me. Line 3029 in /usr/lib/portage/pym/portage.py.(2.0.50-r1) From if portdbapi: To if myportapi:
I had the same problem after a simple a emerge rsync. After rm -rf /usr/portage/* emerge worked again and I rsynced. After the this my portage (-2.0.50-r1) was still okey. Looks like some files in the new portage tree freaked him out.
*** Bug 47328 has been marked as a duplicate of this bug. ***
I'm the author of comment #36. I'd like to thank the submitter of the comment #50 since it seems to have fixed the problem. Amazing it was so "easy" to fix. "emerge sync" is working right now. I hope I'm not talking too fast...
*** Bug 47677 has been marked as a duplicate of this bug. ***
Patch in comment 50 works for me too.
Just FYI, the "rm -rf /usr/portage/*" fixed the problem on all my affected machines. Dindn't have to change a single char in portage... :-) Radek
This bug has been inactive for more than 90 days. Presumably this bug has been fixed?
Bug has been fixed and released in stable portages on or before 2.0.51-r2