emerging media-plugins/kipi-plugins-3.2.0 fails right after the source configure phase with a sandbox access violation in /dev/dri/card0
Created attachment 350546 [details] build log
Created attachment 350548 [details] sandbox log
Created attachment 350550 [details] emerge --info
Which version of media-gfx/imagemagick do you have? What use-flags are set on imagemagick?
media-gfx/imagemagick-6.8.5.4 USE="X bzip2 corefonts cxx djvu fontconfig graphviz jpeg jpeg2k lcms opencl openmp pango perl png postscript svg tiff truetype wmf xml zlib -autotrace -fftw -fpx -hdri -jbig -lqr -lzma -openexr -q32 -q64 -q8 -raw -static-libs {-test} -webp"
(In reply to Jason Lamb from comment #5) > media-gfx/imagemagick-6.8.5.4 USE="X bzip2 corefonts cxx djvu fontconfig > graphviz jpeg jpeg2k lcms opencl openmp pango perl png postscript svg tiff > truetype wmf xml zlib -autotrace -fftw -fpx -hdri -jbig -lqr -lzma -openexr > -q32 -q64 -q8 -raw -static-libs {-test} -webp" OK right as I suspected, opencl. This will be fun. No idea yet how to handle it. Could you please also add the output of "eselect opencl list" ?
eselect opencl list Available OpenCL implementations: [1] mesa * FWIW, I only added opencl support to my system because of the work devs had been doing to bring it to the open source radeon driver. Even though I only have one opencl app, bfgminer, (that I'm aware of), that can even work on my system, I thought it would be fun to experiment with. I guess I don't know how likely you are to see this combination again, anytime soon.. Thanks..
Created attachment 350904 [details] imagemagick-6.8.5.4 build log Including here because it's likely related. When attempting to emerge media-gfx/imagemagick-6.8.5.4 using the opencl flags also generates a sandbox violation by 'identify -list Configure' during the install phase in /dev/dri/card0
Created attachment 350906 [details] imagemagick-6.8.5.4 sandbox log
imagemagick[opencl] behaves very strange... Trying to upgrade from media-gfx/imagemagick-6.8.6.8 to media-gfx/imagemagick-6.8.6.8-r1 failed for me with the same sandbox violations as Jason Lamb has posted. But even USE=-opencl emerge -1 imagemagick failed! But unmerging the currently installed USE=opencl version and then emerging 6.8.6.8-r1 even with USE=opencl set did work! It seems imagemagick is wrongly running the 'identify' tool from the currently installed version and that causes theses sandbox problems. Note: I'm using media-libs/mesa-9.2.0 as my opencl provider. I have a radeon card and am only using its open source drivers. fglrx was never installed on that system.
*** Bug 485422 has been marked as a duplicate of this bug. ***
I guess I'll apply this hack in imagemagick's ebuild, but it doesn't solve the problem elsewhere than in imagemagick build: shopt -s nullglob cards=$(echo -n /dev/dri/card* | sed 's/ /:/g') if test -n "${cards}"; then addpredict "${cards}" fi shopt -u nullglob
Same here
How about to put opencl in use.mask for media-gfx/imagemagick?
(In reply to Johannes Huber from comment #14) > How about to put opencl in use.mask for media-gfx/imagemagick? but the problem is opencl implementation specific, I, for example, don't have the problem with nvidia drivers how wide spread you think the problem is? i've seen /usr/bin/mogrify triggering it. i don't think use of mogrify in build systems is that common so either apply the workaround from Comment #12 to the package using mogrify during build or, move the workaround from Comment #12 to an opencl.eclass and call it a sandbox_disable_dri() or whatever or provide complete solution that stops the mesa from trying to access the card's dri during the build? this used to not be a problem, what changed?
(In reply to Johannes Huber from comment #14) > How about to put opencl in use.mask for media-gfx/imagemagick? base/ + 19 Mar 2014; Samuli Suominen <ssuominen@gentoo.org> package.use.stable.mask: + Mask USE="opencl" for stable users of media-gfx/imagemagick wrt #472766 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/profiles/base/package.use.stable.mask?r1=1.3&r2=1.4
Is masking not a little too invasive? What happens if you "addpredict /dev/dri/card0"?
(In reply to Chí-Thanh Christopher Nguyễn from comment #17) > Is masking not a little too invasive? What happens if you "addpredict > /dev/dri/card0"? that's what Comment #12 is about -- addpredict works, but you have to add it per package so while eg. this bug was filed against kipi-plugins, i don't see the solution in kipi-plugins ebuild yet, and kipi-plugins is not the only package using mogrify (or some other executable) from imagemagick that triggers the same problem so propably use this bug as a Tracker if the wanted solution is to apply the workaround to every affected package
It's kinda pointless to add an openca-whatever eclass to any ebuild that uses imagemagick (or something else) as (indirect) dependency... :( This is something that calls for a more global solution, like portage functionality (afaik sandbox is not in the scope of PMS, correct me if I'm wrong). I.e. define a file that generates addpredicts based on useflag settings. Then again, this defines the purpose of the sandbox.
See-Also: bug #472688, bug #485422, bug #490457
Does this work for you guys? /etc/sandbox.d/99imagemagick file with content of: SANDBOX_PREDICT="/dev/dri/card*" The main question here is that, I don't know if * wildcards are supported in the file format
*** Bug 490457 has been marked as a duplicate of this bug. ***
*** Bug 472688 has been marked as a duplicate of this bug. ***
It's "/dev/dri/card" and rest is filled up automatically by sandbox. Should be fixed (well, workarounded) by version 6.8.8.10 in Portage now: $ cat /etc/sandbox.d/99imagemagick SANDBOX_PREDICT="/dev/dri/card" $ qfile -b 99imagemagick media-gfx/imagemagick (/etc/sandbox.d/99imagemagick) the file is installed only with USE=opencl please test :)
I think it would be better to create a tracker bug instead of marking the other opencl sandbox violation bugs as duplicates of this one. Google reveals that imagemagick can be prevented from using opencl by setting MAGICK_OCL_DEVICE=OFF per http://www.imagemagick.org/script/opencl.php
(In reply to Chí-Thanh Christopher Nguyễn from comment #25) > I think it would be better to create a tracker bug instead of marking the > other opencl sandbox violation bugs as duplicates of this one. To add duplicate solution to every package that happens to call imagemagick binaries, or other binaries that link to imagemagick's libraries? That's propably hundreds of packages in the end. I don't like that idea, nor think it's the correct solution here. > > Google reveals that imagemagick can be prevented from using opencl by > setting MAGICK_OCL_DEVICE=OFF per > http://www.imagemagick.org/script/opencl.php That'd mean shipping a env.d file in ImageMagick that sets that, and then, it would affect also packages outside of Portage :/
/dev/card/dri* in SANDBOX_PREDICT is highly unsafe - it is quite easy to get root access using 3D driver holes. The environment variable could be set in make.globals or /etc/portage/env.
(In reply to Radoslaw Szkodzinski from comment #27) > /dev/card/dri* in SANDBOX_PREDICT is highly unsafe - it is quite easy to get > root access using 3D driver holes. > > The environment variable could be set in make.globals or /etc/portage/env. make.globals is for Portage's own settings, shipped with Portage itself and /etc/portage/env is user-defined settings and /dev/dri/card* is owned by root:video, so you'd have to be in the video group, and if you are in the video group, then you have access to the video device anyway, and sandbox doesn't increase the problem from that any futher
and it's 'addpredict', not 'addwrite', that's used here
Ah, right, sorry about the spam then.
should also contain: /dev/nvidiactl when using nvidia opencl library. stumbled upon this just yesterday
(In reply to Wojtek Arabczyk from comment #31) > should also contain: > > /dev/nvidiactl when using nvidia opencl library. > > stumbled upon this just yesterday I've extended the workaround to /dev/nvidiactl in imagemagick-6.8.9.7's ebuild and up
*** Bug 482976 has been marked as a duplicate of this bug. ***
*** Bug 505490 has been marked as a duplicate of this bug. ***
I see that 'media-gfx/imagemagick opencl' is now stable across the board at 6.9.4.6, and yet remains in /usr/portage/profiles/base/package.use.stable.mask. Has this issue not been addressed since media-gfx/imagemagick-6.8.5.4, or is it now time to remove the package.use.stable.mask entry? Removing the mask on my machine and recompiling seems to go smoothly.
