emerge [anything] fails since my latest world -u! No error messages, just another shell prompt. I'm stalled! Here are a couple of examples: ---- emerge portage Calculating dependencies ...done! >>> emerge (1 of 1) sys-apps/portage-2.0.45-r1 to / ---- emerge gplflash Calculating dependencies ...done! >>> emerge (1 of 1) net-www/gplflash-0.4.10-r1 to / >>> md5 ;-) flash-0.4.10.tgz ----
Created attachment 6222 [details] emerge info
Use the rescue portage. Read: /usr/portage/sys-apps/portage/files/README.RESCUE
Portage-rescue package did not solve the problem. Thanks anyway.
Avi Schwartz reported the same problem on the gentoo-dev mailing list. Setting FEATURES=-sandbox allowed him to emerge again. What version of portage are you using? What version of portage did you try to rescue with? Try turning off sandbox (as above) and then emerge portage.
My version of Portage and of Portage-rescue is 2.0.44. Other details are available in the attached file (att. #6222, see above). With the workaround you suggested I managed to update portage to v2.0.45-r1, but the problem persists! Of course, now I can update a package if I really need it. Thank you for your precious help!
I noticed a possibly related glitch: I cannot play files with mplayer anymore because a module (read_subtitles_file) crashes. An error message few lines above reads: "Can't find HOME directory". However ll ~ -d works and $HOME is set. This happens ONLY under the root account.
I found a workaround: it is sufficient to "export HOME=/root" (as root, of course) before emerging. This is because, although $HOME seems to be set (is shown by "set"), it is not read by getenv calls (they just return NULL), thus making the sandbox module crash. Can anyone tell me how is this possible?
I've got a fix in cvs to be released shortly. Not sure how successful this will be though. If home isn't set, I export it as PORTAGE_TMPDIR (Lets fakeroot/droppriv work too, I hope.)
Anyone know a general reason HOME couldn't be getenv()'d ?
Possibly if you start a terminal/whatever without logging in ( the old problem where you have to tell gnome-terminal/whatever to behave like login), but he does say that it is present if he run 'set'. I guess it can also be possible that something in sandbox is borked, but I rather find that unlikely, as (if I remember correct) sandbox do not use/alter HOME.
grep 'root' /etc/passwd Is the info proper?
It is. (root:x:0:0::/root:/bin/bash) In fact, HOME is "set" correctly even though it cannot be getenv()'d.
Created attachment 6461 [details] Results of a simple test I built a program to getenv() a certain environment variable, then I run it over the whole environment. Variables marked by "(null)" cannot be getenv()'d even though they are set. I also dug a little bit in the bash source, but I couldn't find the cause of this yet. However, those vars are set internally and can only be accessed by internal bash routines, so they are shown with set, they are used for path expansion and shell prompt visualization. I'll keep you informed as I find out more pieces of the puzzle...
Ok, I found the culprit: it was a crappy script named "sux" (very appropriate!). It tries to copy the X cookies and to build a valid "su" command line, but produces something that seems to work and eventually hijacks the environment quite badly. I don't know how, exactly, since I hate hacking through shell scripts. I think I'll rewrite everything in Ruby. Please re-open this bug if anyone experiences this problem and is not using sux. Anyway, it wasn't exactly portage's fault (well, just lack of error handling, really). Thank you!
