When trying to install the package (media-libs/ftgl), it generates a sandbox violation error in the configuration stage when it tries to access /usr/share/fonts when checking for a TrueType font. Reproducible: Always Steps to Reproduce: 1. Execute command `emerge media-libs/ftgl` Actual Results: The package does not install, instead generating a sandbox violation error, as described above. Expected Results: The package should have installed. media-libs/ftgl is a dependency of www-client/firefox in my configuration. `emerge --info` generates urls, which, as a new user, I cannot add. I will add it as an attachment instead, if possible.
Can you attach the full build.log? (Also sandbox.log if it exists) Normally, this is caused by another package not properly updating cache after installing a font. May be able to attach emerge --info instead wrt links, or could mangle them yourself if that's alright.
Created attachment 787691 [details] Build log for media-libs/ftgl
F: mkostemp S: deny P: /usr/share/fonts/encodings/.uuid.TMP-XXXXXX A: /usr/share/fonts/encodings/.uuid.TMP-XXXXXX R: /usr/share/fonts/encodings/.uuid.TMP-XXXXXX C: fc-match -sv serif F: mkostemp S: deny P: /usr/share/fonts/encodings/large/.uuid.TMP-XXXXXX A: /usr/share/fonts/encodings/large/.uuid.TMP-XXXXXX R: /usr/share/fonts/encodings/large/.uuid.TMP-XXXXXX C: fc-match -sv serif
Created attachment 787694 [details] Output of emerge --info
I've seen this before with x11-themes/arc-theme, before it was pre-rendered upstream. We had to add this: addpredict "${BROOT}"/usr/share/inkscape/fonts/.uuid.TMP-XXXXXX I tried to figure out why it happens but wasn't able to.
Run "fc-cache -fs" as root and try again as a workaround And hm.. this one is different than usual, with two way to see it... 1. From a quick look xorg-3.eclass creates these directories without running fc-cache -fs leading to sandbox violation when something tries to generate the missing cache. These are initially empty until a font which do run font_pkg_postinst is installed. ...but 2. ~arch fontconfig-2.14.0-r1 skips these, this only happens if using stable fontconfig-2.13.1-r2, so to reproduce downgrade to stable one, rm /usr/share/fonts/encodings/.uuid, then emerge ftgl Either way it's not a ftgl bug if that wasn't clear, this happens with any packages using fontconfig in some way and the issue always lies elsewhere (so either a xorg-3.eclass fix, or stabilize 2.14.0-r1 I guess).
(In reply to Ionen Wolkens from comment #6) > Run "fc-cache -fs" as root and try again as a workaround > > And hm.. this one is different than usual, with two way to see it... > > 1. From a quick look xorg-3.eclass creates these directories without running > fc-cache -fs leading to sandbox violation when something tries to generate > the missing cache. These are initially empty until a font which do run > font_pkg_postinst is installed. > > ...but > > 2. ~arch fontconfig-2.14.0-r1 skips these, this only happens if using stable > fontconfig-2.13.1-r2, so to reproduce downgrade to stable one, rm > /usr/share/fonts/encodings/.uuid, then emerge ftgl > > Either way it's not a ftgl bug if that wasn't clear, this happens with any > packages using fontconfig in some way and the issue always lies elsewhere > (so either a xorg-3.eclass fix, or stabilize 2.14.0-r1 I guess). It works for me, thanks
(In reply to Ionen Wolkens from comment #6) > Run "fc-cache -fs" as root and try again as a workaround > > And hm.. this one is different than usual, with two way to see it... > > 1. From a quick look xorg-3.eclass creates these directories without running > fc-cache -fs leading to sandbox violation when something tries to generate > the missing cache. These are initially empty until a font which do run > font_pkg_postinst is installed. > > ...but > > 2. ~arch fontconfig-2.14.0-r1 skips these, this only happens if using stable > fontconfig-2.13.1-r2, so to reproduce downgrade to stable one, rm > /usr/share/fonts/encodings/.uuid, then emerge ftgl > > Either way it's not a ftgl bug if that wasn't clear, this happens with any > packages using fontconfig in some way and the issue always lies elsewhere > (so either a xorg-3.eclass fix, or stabilize 2.14.0-r1 I guess). This worked. Thanks for your help.
