>>> Completed installing media-gfx/imagemagick-7.0.9.8 into /zram/portage/media-gfx/imagemagick-7.0.9.8/image * Final size of build directory: 95600 KiB (93.3 MiB) * Final size of installed tree: 26700 KiB (26.0 MiB) * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- * LOG FILE: "/var/log/sandbox/sandbox-4.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: mkstemp S: deny P: /zram/imagemagick/magick-1163D_E8txXXXXXX A: /zram/imagemagick/magick-1163D_E8txXXXXXX R: /zram/imagemagick/magick-1163D_E8txXXXXXX C: identify -list Configure F: open_wr S: deny P: /zram/imagemagick/magick-1163M_DGtHt1dTfh A: /zram/imagemagick/magick-1163M_DGtHt1dTfh R: /zram/imagemagick/magick-1163M_DGtHt1dTfh C: identify -list Configure F: mkstemp S: deny P: /zram/imagemagick/magick-1480FL13wGXXXXXX A: /zram/imagemagick/magick-1480FL13wGXXXXXX R: /zram/imagemagick/magick-1480FL13wGXXXXXX C: identify -list Configure F: open_wr S: deny P: /zram/imagemagick/magick-1480o0H38BaLz2d8 A: /zram/imagemagick/magick-1480o0H38BaLz2d8 R: /zram/imagemagick/magick-1480o0H38BaLz2d8 C: identify -list Configure F: mkstemp S: deny P: /zram/imagemagick/magick-1535cw4CPqXXXXXX A: /zram/imagemagick/magick-1535cw4CPqXXXXXX R: /zram/imagemagick/magick-1535cw4CPqXXXXXX C: identify -list Configure F: open_wr S: deny P: /zram/imagemagick/magick-15359G7_BDBJ8RHL A: /zram/imagemagick/magick-15359G7_BDBJ8RHL R: /zram/imagemagick/magick-15359G7_BDBJ8RHL C: identify -list Configure * -------------------------------------------------------------------------------- >>> Failed to emerge media-gfx/imagemagick-7.0.9.8,... Reproducible: Always Steps to Reproduce: 1.emerge -1av media-gfx/imagemagick 2. 3. Actual Results: Merge failed. Expected Results: Merge should succeed. Reason ------ The culprit is obviously the command identify -list Configure which seems to be issued at the end of the build process to verify that the installation has succeeded. The problem is, 'identify' uses the configuration of the *existing* installation (i.e. the 'real' one), not one that would fit the sandbox. The existing installation uses /zram/imagemagick as $MAGICK_TMPDIR, which is on a mounted zram RAM disk. So it tries to create a temporary directory and, possibly, create a few temporary files for 'identify' there - this triggers the 'deny' responses from the sandbox. Solution -------- Run the 'identify -list Configure' command with $MAGICK_TMPDIR pointing to a directory *inside* the sandbox, do not just use the value of $MAGICK_TMPDIR from the environment.
Workaround ---------- DID NOT WORK: FEATURES='-sandbox' emerge -1av media-gfx/imagemagick DID NOT WORK: FEATURES='-usersandbox' emerge -1av media-gfx/imagemagick DID NOT WORK: FEATURES='-network-sandbox' emerge -1av media-gfx/imagemagick WORKED: FEATURES='-sandbox -usersandbox -network-sandbox' emerge -1av media-gfx/imagemagick This, of course, defies the purpose of a sandbox...
Thank you for the report. We need to have all information at hand before ticket assignment. That is why I ask you to * attach the logs and * paste the emerge info as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket
Finally, I can report some progress: The reason for this problem is that I use a special $MAGICK_TMPDIR: MAGICK_TMPDIR=/zram/imagemagick /zram is on a compressed RAM disk managed by the zram kernel module. Works like a charm. There are two true solutions here (the rest, like disabling sandbox, are workarounds): either you modify the ebuild to NOT use the value of $MAGICK_TMPDIR, if that value points outside the sandbox (in my case sanbox is inside /zram/portage, so clearly /zram/imagemagick is outside the sandbox), or the user must modify his sandbox to allow write access to $MAGICK_TMPDIR. Here is how to do the latter: Open /etc/sandbox.d/00default and add your $MAGICK_TMPDIR to the SANDBOX_WRITE variable: SANDBOX_WRITE="/usr/tmp/conftest:/usr/lib/conftest:/usr/lib32/conftest:/usr/lib64/conftest:/usr/tmp/cf:/usr/lib/cf:/usr/lib32/cf:/usr/lib64/cf:/full/path/to/your/special/imagemagick/tmpdir" Now, somebody might ask, what is the "right" solution here: modify the ebuild to use a MAGICK_TMPDIR that lies inside the sandbox, or modify the sandbox to allow write access to a MAGICK_TMPDIR outside its usual paths? Very philosophical question - to which I have no answer. Maybe the sandbox gurus can tells us what is the "right" way here...
Sorry but this falls under "then don*t do that"...
