When building x11-drivers/nvidia-drivers using paludis package manager the ebuild is causing sandbox access violations. The fix is trivial. Reproducible: Always Steps to Reproduce: 1. cave resolve -1x nvidia-drivers Actual Results: See attached nvidia-drivers.output Expected Results: nvidia-drivers installed
Created attachment 368630 [details] nvidia-drivers.output
Created attachment 368632 [details, diff] patch that fixes the problem
Comment on attachment 368632 [details, diff] patch that fixes the problem This seems wholly wrong. S is set correctly here, and mkdir $S should not be necessary. Additionally, the error appears to occur in linux-info.eclass and not in the ebuild.
Comment on attachment 368630 [details] nvidia-drivers.output >nvidia-drivers-331.38> * Determining the location of the kernel source code >nvidia-drivers-331.38> * Found kernel source directory: >nvidia-drivers-331.38> * /usr/src/linux >nvidia-drivers-331.38> * Found sources for kernel version: >nvidia-drivers-331.38> * 3.13.0-gentoo-r1 > >nvidia-drivers-331.38> * Gentoo supports kernels which are supported by NVIDIA >nvidia-drivers-331.38> * which are limited to the following kernels: >nvidia-drivers-331.38> * <sys-kernel/gentoo-sources-3.13 >nvidia-drivers-331.38> * <sys-kernel/vanilla-sources-3.13 >nvidia-drivers-331.38> * >nvidia-drivers-331.38> * You are free to utilize epatch_user to provide whatever >nvidia-drivers-331.38> * support you feel is appropriate, but will not receive >nvidia-drivers-331.38> * support as a result of those changes. >nvidia-drivers-331.38> * >nvidia-drivers-331.38> * Do not file a bug report about this. You are using an unsupported kernel. If you would like me to look at the sandbox violations, then try again with a supported kernel, viz. <gentoo-sources-3.13.
It was doing the exact same thing with 3.12. I literally have just uninstalled it and installed 3.13, which why I remembered about this error and decided to submit the bug. If you are willing to look at the errors, I will go ahead and reinstall 3.12. Also, please see my next comment (which I am I/P typing) with some more details about this error.
(In reply to Jeroen Roovers from comment #3) > Comment on attachment 368632 [details, diff] [details, diff] > patch that fixes the problem > > This seems wholly wrong. S is set correctly here, and mkdir $S should not be > necessary. Additionally, the error appears to occur in linux-info.eclass and > not in the ebuild. Jeroen, you are correct the actual error is in linux-info.eclass. See bug # 469210: https://bugs.gentoo.org/show_bug.cgi?id=469210 However, I noticed that other packages, eg. gentoo-sources or networkmanager, which all access /usr/src/linux, don't throw these errors. And the only difference between them and the nvidia-drivers is that the latter changes S to WORKDIR. So, my patch is just a "workaround" rather than a proper "fix". If you are not willing to apply it, that's totally fine, I have the patched in my overlay.
*** This bug has been marked as a duplicate of bug 469210 ***
Jeroen, I submitted a patch against linux-info.eclass, but I don't seem to get much response on that bug. Do you have the power to review/commit/reject the patch? Also, another 2 things I wanted to clarify: 1. Should the get_makefile_extract_function be responsible for checking the phase or should the ebuild calling this function check that? 2. Why is it that setting S=$WORKDIR triggers these violations? While leaving it as-is doesn't? Maybe, this is already accounted for with some sandbox access rules? Sorry, my portage-foo is very minimal, so I am just poking in the dark here.
(In reply to Timothy Jones from comment #8) > Jeroen, I submitted a patch against linux-info.eclass, but I don't seem to > get much response on that bug. Do you have the power to review/commit/reject > the patch? > > Also, another 2 things I wanted to clarify: > > 1. Should the get_makefile_extract_function be responsible for checking the > phase or should the ebuild calling this function check that? > > 2. Why is it that setting S=$WORKDIR triggers these violations? While > leaving it as-is doesn't? Maybe, this is already accounted for with some > sandbox access rules? Sorry, my portage-foo is very minimal, so I am just > poking in the dark here. bump
