kdebase 3.0.3 ebuild does not work correctly in the sandbox. This manifests itself on a clean system with no prior versions of kde present. The result is that kdebase does not install correctly. KDE will *NEVER* be able to be installed for new users as it currently stands.
can you attach the emerge log, please?
Err, unless emerge automaticall keeps logs, no I cannot provide you with the bad build log file as it was overwritten by the final good one. I can tell you that the sandbox problem error messages were for /root/.kde and a couple of subdirs below that. Hope that helps a bit more
"Final good one" - you mean it succeeded in emerging when you tried again? Or what? The errors about stuff in ~/.qt and ~/.kde not being writeable are always there, but they don't make the build process abort. Did they become "real" sanbodx errors for you, i.e. with red-colored output etc? Normally they're just messages from the build system, not from the sandbox itself.
Created attachment 3911 [details] Sandbox log generated by 'emerge kdebase' When building the system from scratch, I emerged kdebase. It repeatedly displayed red output saying it was unable to create /root/.kde. It was only after I searched the forum that I tried emerging kdebase with the sandbox disabled (export SANDBOX_DISABLED=1; emerge kdebase;). Only with the sandbox disabled was kdebase built to completion, by which I mean that 'startkde' existed at the end. To help a bit more, I have found the sandbox log from the first time I tried emerging kdebase. So I made /root/.kde and the build them complained about /root/.kde/share.
I too am seeing this error. I'm also getting it when I try to emerge Quanta. Are the two related?
This bug is really annoying. People have been reporting it on and off for months (only a very few people though). I and everyone else get the access denied _warnings_ from the app that tries to access .kde, but these people get access denied _errors_ from the sandbox. And I've no idea what the difference in our setups is. Ideas anyone? Maybe you're using some rare filesystem or portage version or something?...
This occurred when I was installing on my brand new laptop. I followed the install instructions from a stage-1 install. I use the vanilla kernel which is highly customised. I like a nice, tight kernel, force of habit over many years of using Linux. File system is ext3. From my view point, it looks like something in the build of kdebase is looking for something like $HOME/.kde. Could an env var which I have contribute to the build failing? Once again, my root login is tight but customised to my needs. If my login profile has compromised the build of kdebase, but it's OK for other people generally, this would indicate something in my profile affects the build, doesn't it? So I would start looking at anything in the build that used $LOGNAME, or $USER as I used sudo from my standard login shell and they're the only two variables in my environment that have root mentioned in them. As much as I can, I will help sniff the problem out, so keep asking the questions and I'll keep answering as best as I can.
*** Bug 7980 has been marked as a duplicate of this bug. ***
OK, finally a fix to test! :-) Part 1: the fix: I'm about to attach a new kde.eclass, replace the one in /usr/portage/eclass with it and try again. What it does is mkdir -p $T/fakehome/.kde; export HOME=$T/fakehome. That means the build process can now access a homedir that's writeable under the sandbox (T=/var/tmp/portage/<package>/temp, the temp dir). That should get rid of the errors no matter what their source is. I've just now though of & implemented it, so haven't tested it myself, but it shouldn't break anything AFAICS. Yes I know I could have done this long ago; it took mjc who suggested a good explanation for why this is is happening only for certain people to get me going.
Created attachment 4403 [details] New kde.eclass setting HOME=$T/fakehome. Please test this. It replaces /usr/portage/eclass/kde.eclass.
Part 2: now for mjc's explanation: Whatever is generating these errors checks if it has write permissions to ~/.kde before trying to write. Because emerge is run as root, the build process always sees HOME=/root. If the user really is root (like me and mostly everyone since emerge requires root perms), he does have write permissions there and so the build process tries to write there and the sandbox errors out. If the user isn't root but has root permissions (therefore probably not using su but something different?), he doesn't have write perms to /root and so the build process prints its own warning of "access denied", but doesn't try to write there. Now I know this theory isn't very correct. For one thing, it predicts that _I_ should haev sandbox errors rather than other people. But it's something at least and sounds like a promising lead :-) Credit goes to mjc (thanks!) and to my possible misunderstanding of his words...
Created attachment 4409 [details] Replacement kde.eclass New version: add support for ccache by making fakehome/.ccache a symlink pointing to the real $HOME/.ccache.
*** Bug 9255 has been marked as a duplicate of this bug. ***
*** Bug 9320 has been marked as a duplicate of this bug. ***
*** Bug 10391 has been marked as a duplicate of this bug. ***
The fix has been in portage for some time now. If noone objects I will close this bug.
Still getting sandbox violations on emerging kdebase-3.1_rc6, these being multiple lines of the form [...] mkdir: /root/.kde mkdir: /root/.kde mkdir: /root/.kde [...] (pretty much the sandbox log already attached to this bug) There was indeed a /var/tmp/portage/kdebase-3.1_rc6/temp/fakehome/ directory, with a empty .kde subdirectory, and a .qt subirectory containing 'qt_plugins_3.1rc' and '.qt_plugins_3.1rc.lock'. At the time of install, there were no other kde packages emerged, and further until this point there was a -kde in the USE variable. Would posting anything else be useful?
I noticed that my comment is pretty much the same as bug 11664 - sorry for the dupe!
Are you using sudo like the poster from #11664? If so please try using su, that should work if it's the same issue as 11664.
Fixed AFAIK. For the separate sudo issue see bug #11664.
