Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 323689 - x11-drivers/nvidia-drivers-195.36.24 emerge with FEATURES=userpriv fails due to missing privileges
Summary: x11-drivers/nvidia-drivers-195.36.24 emerge with FEATURES=userpriv fails due ...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Doug Goldstein (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-12 16:03 UTC by Andrej Kacian
Modified: 2010-07-13 21:52 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
nvidia-drivers build log (x11-drivers:nvidia-drivers-195.36.24:20100612-155402.log,4.37 KB, text/plain)
2010-06-12 16:03 UTC, Andrej Kacian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrej Kacian 2010-06-12 16:03:37 UTC
The conftest.sh (in nvidia's usr/src/nv dir) is trying to determine valid kernel includes path by #including few header files from <linux/...>, but fails with userpriv feature, because it is running as user without read access to those headers (they are installed as root:root with 640 permission) - therefore the test compilation fails, as does the entire make process.

Note that when running the exact make command manually in the correct dir inside PORTAGE_TMPDIR as root works just fine.
Comment 1 Andrej Kacian 2010-06-12 16:03:54 UTC
Created attachment 235089 [details]
nvidia-drivers build log
Comment 2 Andrej Kacian 2010-06-12 16:11:43 UTC
This applies to all recent ebuilds, even those which worked with pre-2.6.33 kernels (I can't recall the exact ebuild version).
Comment 3 Doug Goldstein (RETIRED) gentoo-dev 2010-07-13 05:02:22 UTC
I don't believe any out of tree (kernel tree that is) kernel module ebuild works with userpriv. Have to double check though.
Comment 4 Doug Goldstein (RETIRED) gentoo-dev 2010-07-13 05:27:16 UTC
Actually that was dumb of me.... I use userpriv! Of course it works. However, I don't have a single kernel that doesn't have its sources without 644. That's how Portage installs them.

I would double check how you install your kernels.
Comment 5 Andrej Kacian 2010-07-13 21:52:15 UTC
Actually, it seems to be the .config file that is being created with 640 permissions, probably due to my root's 027 umask. Thinking about it, this is probably out of scope for a package maintainer - it would have to be made world-readable in kernel Makefile, right after finishing "make (whatever)config".