this is fixed, I'm reporting it so that people who search for it can benefit from the information I have. Well, my portage stopped working; what probably caused it was the removal of a stale xfree class from my PORTDIR_OVERLAY (see #63503 for info). All kinds of commands would just stay there - even "emerge -V". If I interrupt it (ctrl-C), I get a traceback that says something about trying to lock a file. (I'm attaching the full traceback here) I'll explain the solution in a comment. Reproducible: Always Steps to Reproduce:
Created attachment 40345 [details] full traceback of interrupting emerge
Here's how it was fixed, thanks to carpaski on IRC. First, edit /usr/lib/portage/pym/portage.py Find "def autouse"; in my version (2.0.50-r11) it's at line 1108. Add a line, just before the "global", so that the method looks like this: def autouse(myvartree,use_cache=1): "returns set of USE variables auto-enabled due to packages being installed" return "" global usedefaults if profiledir==None: return "" myusevars="" ... After you do this, your portage should be running, but DON'T USE IT YET for anything normal - it's severely crippled. Instead, immediately run "emerge sync" and let it finish the cache update. You will get hundreds of errors in the cache update - that's NORMAL. Then "emerge portage". After that, it should work normally again.
btw, carpaski also claims this is fixed (as in, can't happen) in portage 2.0.51_rc1
