When running emerge kde on a nearly fresh install, it dies at kdemultimedia and kdebase with: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-kdebase-3.0.4-r3-5720.log" mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde
That's odd, I thought I fixed that in kde.eclass. I don't quite see how it could still occur with the fix there. Hmm. I will have to think about it, don't have any ideas right away. Could you please give me an ls -laR of /var/tmp/portage/kdebase-3.0.4-r3/temp. If you want to, disable the sandbox for now (the access to ~/.kde is harmless) but be prepared to test possible fixes for me later :-)
When compiling kdeutils, I noticed that some (all?) of the access violations were within the configure....
ls -laR /var/tmp/portage/kdebase-3.0.4-r3/temp /home/papercrane /var/tmp/portage/kdebase-3.0.4-r3/temp: total 58 drwxr-xr-x 3 root root 192 Dec 9 13:38 ./ drwxr-xr-x 3 root root 104 Dec 9 21:06 ../ -rw-r--r-- 1 root root 41088 Dec 10 09:48 eclass-debug.log drwxr-xr-x 4 root root 96 Dec 6 01:07 fakehome/ -rw-r--r-- 1 root root 405 Dec 9 13:38 kde -rwxr-xr-x 1 root root 34 Dec 9 13:38 kde-3.0.4 -rw-r--r-- 1 root root 48 Dec 9 13:38 kscreensaver /var/tmp/portage/kdebase-3.0.4-r3/temp/fakehome: total 2 drwxr-xr-x 4 root root 96 Dec 6 01:07 ./ drwxr-xr-x 3 root root 192 Dec 9 13:38 ../ drwxr-xr-x 2 root root 48 Dec 6 01:07 .kde/ drwxr-xr-x 2 root root 120 Dec 6 02:30 .qt/ /var/tmp/portage/kdebase-3.0.4-r3/temp/fakehome/.kde: total 1 drwxr-xr-x 2 root root 48 Dec 6 01:07 ./ drwxr-xr-x 4 root root 96 Dec 6 01:07 ../ /var/tmp/portage/kdebase-3.0.4-r3/temp/fakehome/.qt: total 5 drwxr-xr-x 2 root root 120 Dec 6 02:30 ./ drwxr-xr-x 4 root root 96 Dec 6 01:07 ../ -rw------- 1 root root 0 Dec 6 02:30 .qt_plugins_3.0rc.lock -rw-r--r-- 1 root root 487 Dec 6 02:30 qt_plugins_3.0rc
Another note. I'm running this in a sudo -s environment, so my $HOME is not /root.
I'm not completely sure yet, but I think I found a way around this problem. Instead of using a sudo -s shell, I'm using an su shell. The packages seem to be installing fine, confirmation to come once my system finishes compiling. I think the reason the hack in kde.eclass didn't work is that with sudo -s I'm not 'really' root. I still have my own environment, so the install script (or shell or something else) recreates the home directory (probably from /etc/passwd). su makes me the 'real' superuser, so it trusts $HOME.
I was right. kdeedu just installed without a hitch. I'm going to continue installing kde now, but I assume it's all going to work just fine now. So I've found a way around the problem....but why is the kde install trying to create a /root/.kde?
It's doing that to write to some config files and to upset me... The new/upcoming user-mode compiling feature of emerge should help here. An access denied message from the filesystem shouldn't abort compilation, only our sandbox code does that. Hopefully that will finally close this set of problems... About sudo , I'm not sure I understand how it can stop me from exporting HOME=$T/fakehome and having access redirected there. Hm...
*** Bug 15078 has been marked as a duplicate of this bug. ***
*** Bug 15115 has been marked as a duplicate of this bug. ***
Any update on this? I think the changes in portage since the initial bug report *should* have fixed this problem.
Closing as fixed, as it's old and there's been no update in correspondance for some time.
Is this bug actually fixed...? I am having the same problem when using sudo. I haven't gotten the chance to use it with just 'su' yet, but the symptoms are all the same.
Nope, it ain't fixed. See also #38442
