Gimp 2.9.4 fails compilation on Nvidia systems due to GEGL 0.3 requiring access to Nvidia's UVM device node. Please see the attached build logs for details. Adding "addwrite /dev/nvidia-uvm" to src_compile() solves the immediate issue. Additionally, I'm not sure if something is configured wrong on my system, but at least with nvidia-drivers-361.28 and despite the uvm USE flag, /dev/nvidia-uvm does not exist after simply booting up. In that case, GEGL fails to run with "NVIDIA: failed to execute `/usr/bin/nvidia-modprobe -u -c=0`: Permission denied." as the sandbox prohibits initializing the module. The build continues despite that warning message but I'm not sure if it produces erroneous results (e.g. running Filters/Map/G Fractal Trace displays an error dialog if compilation showed that warning, although it still works). If I run nvidia-modprobe -u -c=0 once after reboot, before compilation, the warning at compile time disappears. Running nvidia-modprobe is not required after compilation for running GIMP as non-sandboxed users can apparently trigger creation by just using an application requiring it (at least with Gimp/GEGL). Overview of attached files: * gimp-full-sandbox-build.log contains the initial state with current portage ebuild * gimp-sandbox-write-build.log shows the log if nvidia-modprobe -u -c=0 is run without lifting sandbox restrictions (write protection still in effect) * gimp-device-node-missing-build.log shows the log if it's the other way around: ebuild now tells sandbox to allow write access to the still non-existant device node; the build succeeds with possibly broken results due to GEGL still throwing warnings despite not aborting the build This issue is only in part related to 572496 - I didn't check 2.9.2 if it has the same errors and I already have nvidia-drivers[uvm]. 572496 only deals with uvm not being required, this issue deals with the effects of uvm not being accessible although the module is installed. Reproducible: Always Steps to Reproduce: 1. emerge gimp 2.9.4 on a Nvidia system using nvidia-drivers[uvm] Actual Results: Sandbox violations like: F: __xmknod S: deny P: /dev/nvidia-uvm A: /dev/nvidia-uvm R: /dev/nvidia-uvm C: /usr/bin/gegl-0.3 ../../icons/Symbolic/64/gimp-wilber-outline.png -o 64/gimp-wilber-outline.png -- gegl:invert-gamma Expected Results: A working build without sandbox violations.
Created attachment 443250 [details] gimp-full-sandbox-build.log.gz
Created attachment 443252 [details] gimp-sandbox-write-build.log.gz
Created attachment 443254 [details] gimp-device-node-missing-build.log.gz
Hello Daniel, thanks for the report! While somewhat related to bug #572496, it doesn't seem /blocked/ by that to me, so I removed the blocker. "addwrite /dev/nvidia-uvm" is now in place, please re-open if needed. commit cebb4006884cb28884bb78483ce02c92961fe02a Author: Sebastian Pipping <sping@g.o> Date: Sun Aug 14 00:26:14 2016 +0200 media-gfx/gimp: Graphics device access (bug #591214) Package-Manager: portage-2.2.28 media-gfx/gimp/gimp-2.9.2-r2.ebuild | 1 + media-gfx/gimp/gimp-2.9.4.ebuild | 1 + media-gfx/gimp/gimp-9999.ebuild | 1 + 3 files changed, 3 insertions(+) https://github.com/gentoo/gentoo/commit/cebb4006884cb28884bb78483ce02c92961fe02a
Wow, that was fast. :) What about the issue that not only write permission is needed but the device node cannot be successfully initialized from within the sandbox if it hasn't been created by another program prior to running emerge? Is that just an issue on my local system or is it reproducible elsewhere? To reproduce, check that /dev/nvidia-uvm hasn't been created after a reboot and attempt to build GIMP - you will likely get the same warnings I got while it calls GEGL, compilation finishes but (at least for me) GIMP may throw non-fatal errors when using GEGL at runtime. At least I suspect it has to do with that warning, but being a development build, it may just be a coincidence.
Hello again, if there is a way to fix things from within src_compile, adding something like if has_version 'x11-drivers/nvidia-drivers[uvm]'; then .............. fi may work for everyone. If /dev/nvidia-uvm cannot be put to work from inside the sandbox.... What do you suggest we do? Btw shouldn't /dev/nvidia-uvm be created by some udev rule? Maybe the x11-drivers/nvidia-drivers package is missing udev rules?
I don't know how uvm works or why it is needed during GIMP compilation but from what I understand, it allows the video cards VRAM to be accessed directly from user space. This might be needed for some sort of shader compilation or something like that but I thought such compilation would work "offline" without requiring access to an actual video card and in particular direct access to GFX memory? Might as well be an error in GEGL or maybe GIMP doesn't call it correctly during compilation? To just fix the issue of the device node not being present when GEGL is called, maybe nvidia-modprobe could be called beforehand outside the sandbox if nvidia-drivers[uvm] is installed and /dev/nvidia-uvm cannot be found? However, I'm not sure if it's okay to simply initialize it on behalf of the user or if it's better to just display a warning and abort compilation? Especially since the -c=0 parameter (as run by GEGL) "manually" defines a minor number. The manpage reads like nvidia-modprobe should indeed have been called earlier by some process (udev), but isn't. Not sure why. According to the manual it just modprobes nvidia (no actual need to call it) and creates all device nodes (that's more important) whereas it appears to be missing creating the node for uvm on my system, if it's ever called. -u parameter needs to be given to achieve that, apparently. So it might be an issue with nvidia-drivers ebuild as well.
I have taken that to a new bug #591286 against x11-drivers/nvidia-drivers now. Please join me over there for more on /dev/nvidia-uvm creation.
1. Is gegl so inflexible as to fail when it cannot use the nvidia-uvm path, instead of using an alternative as and when that happens? 2. Do you expect the portage (or indeed any) user to have access to /dev/nvidia-uvm by default?
(In reply to Jeroen Roovers from comment #9) > 1. Is gegl so inflexible as to fail when it cannot use the nvidia-uvm path, > instead of using an alternative as and when that happens? It seems so, yes. > 2. Do you expect the portage (or indeed any) user to have access to > /dev/nvidia-uvm by default? I don't expect them to but I /wonder/ if that would be a sane expectation, yes. If it's not, I guess we can either just accept Gimp compilation to fail without it or add tricky checks to help the user understand the problem... and still have compilation failing the first time. I'm basically just looking to understand how to best improve the current situation, if possible. If you have ideas how to, I'm all ears.
Hi all - For what it is worth, I had a similar issue - I have a dual card setup with /dev/nvidia0 and /dev/nvidia1. When I ran emerge - it wanted to use /dev/nvidia1, which wasn't in the addwrite list. I made a copy of the ebuild in may local overlay and added "addwrite /dev/nvidia1" and it worked fine. Not sure it matters, but hope that helps as another data point. Thanks!
(In reply to Collin Day from comment #11) > For what it is worth, I had a similar issue - I have a dual card setup with > /dev/nvidia0 and /dev/nvidia1. When I ran emerge - it wanted to use > /dev/nvidia1, which wasn't in the addwrite list. I made a copy of the > ebuild in may local overlay and added "addwrite /dev/nvidia1" and it worked > fine. Not sure it matters, but hope that helps as another data point. Should be gone now, please report back if it persists. https://github.com/gentoo/gentoo/commit/16590b479febfc3deb69ca3b688d965f9e5feb94
(In reply to Sebastian Pipping from comment #12) > (In reply to Collin Day from comment #11) > > For what it is worth, I had a similar issue - I have a dual card setup with > > /dev/nvidia0 and /dev/nvidia1. When I ran emerge - it wanted to use > > /dev/nvidia1, which wasn't in the addwrite list. I made a copy of the > > ebuild in may local overlay and added "addwrite /dev/nvidia1" and it worked > > fine. Not sure it matters, but hope that helps as another data point. > > Should be gone now, please report back if it persists. > > https://github.com/gentoo/gentoo/commit/ > 16590b479febfc3deb69ca3b688d965f9e5feb94 This seems to cause the following error: * Messages for package media-gfx/gimp-2.9.4: * ERROR: media-gfx/gimp-2.9.4::gentoo failed (compile phase): * Usage: addwrite <colon-delimited list of paths> * * Call stack: * ebuild.sh, line 133: Called src_compile * environment, line 4634: Called addwrite '/dev/nvidia0' '/dev/nvidia1' '/dev/nvidia2' '/dev/nvidia3' '/dev/nvid ia4' '/dev/nvidia5' '/dev/nvidia6' '/dev/nvidia7' * ebuild.sh, line 163: Called __sb_append_var 'WRITE' '/dev/nvidia0' '/dev/nvidia1' '/dev/nvidia2' '/dev/nvid ia3' '/dev/nvidia4' '/dev/nvidia5' '/dev/nvidia6' '/dev/nvidia7' * ebuild.sh, line 156: Called die * The specific snippet of code: * [[ -z $1 || -n $2 ]] && die "Usage: add$(LC_ALL=C tr "[:upper:]" "[:lower:]" <<< "${_v}") <colon-delimited l ist of paths>" * (I have slightly outdated Portage on this system but looking at ebuild.sh in git, this shouldn't matter).
(In reply to SN (Enlik) from comment #13) That's not related to UVM but a bug too and fixed by https://github.com/gentoo/gentoo/commit/88cfe3aff7ddd01e66272436bb1eee86280c8ef0 now.
*** This bug has been marked as a duplicate of bug 572496 ***
