| Summary: | =games-simulation/firestorm-bin-6.3.2-r2::lmiphay ebuild causes media-video/mpv::gentoo to fail with sandbox violation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sophie Hamilton <gentoo-bugs> |
| Component: | Overlays | Assignee: | Paul Healy <lmiphay> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log for media-video/mpv::gentoo | ||
|
Description
Sophie Hamilton
2020-03-14 23:09:12 UTC
Created attachment 619278 [details]
build.log for media-video/mpv::gentoo
Sorry, I must have been tired when filing this bug. Obviously step 2 in my steps to reproduce is wrong. The steps to reproduce are: Steps to Reproduce: 1. emerge -av =games-simulation/firestorm-bin-6.3.2-r2::lmiphay 2. emerge -av media-video/mpv::gentoo Hi, I can't reproduce this here - installing mpv-0.31.0-r1 with firestorm-bin-6.3.2-r2 already installed works as expected. Also uninstalling firestorm-bin, reinstalling it, and immediately installing mpv also works as expected. fc-list isn't present in the mpv tarball, nor in any eclass in /usr/portage/eclass - do you have anything relevant in /etc/portage/bashrc, or is fc-list mentioned anywhere under /etc/portage? ( grep -r fc-list /etc/portage/ ) Thanks, Paul I don't even *have* a /etc/portage/bashrc, and "grep -r fc-list /etc/portage" turns up nothing. (looking for "fc-" turns up some unrelated matches in /etc/portage/savedconfig/sys-kernel/linux-firmware-20200302, matching filenames like "s5p-mfc-v6.fw", but nothing else).
I tried compiling with MAKEOPTS="-j1" in order to see which step was actually triggering the sandbox violation. It turns out to be this step:
> [429/430] Compiling DOCS/man/mpv.rst
> 20:01:50 runner ' /usr/bin/rst2pdf -c -b 1 --repeat-table-rows ../DOCS/man/mpv.rst -o DOCS/man/mpv.pdf '
> * ACCESS DENIED: mkostemp: /usr/share/fonts/truetype/.uuid.TMP-XXXXXX
> * ACCESS DENIED: mkostemp: /usr/share/fonts/truetype/kochi/.uuid.TMP-XXXXXX
This would explain why there's no matches - because it's not a Portage thing, but something triggered by rst2pdf. After some investigation, it looks like rst2pdf (a Python application) uses the matplotlib library, which is what is actually calling fc-list and causing the error.
Judging from these results, I imagine the 'bug', such that it is, lies somewhere in fc-list itself. I don't understand why you're not getting the same problem, though. I wonder if fc-list is making some sort of cache somewhere, and you already have that cache and so aren't seeing this error?
I'll try doing this on a new Gentoo chroot and report back on whether this still happens. If so, that's probably the best way to see it in action.
We are still missing something. I didn't have rst2pdf installed. I installed it, and merging mpv still works as expected here (no sandbox violation). I then added the extra sandbox features you have in FEATURES and mpv still installs as expected (I added "ipc-sandbox sandbox usersandbox" - some of these are enabled by default). Finally using exactly your FEATURE settings also allows mpv to be installed. Other ideas welcome... Paul Oh, that's valuable information - if you didn't have rst2pdf installed then that would suggest you don't have the "doc" USE flag for media-video/mpv enabled, and I do. Give that a go? I'll try it on my chroot as well. (It installed fine on the chroot, but I didn't have the doc USE flag enabled. I'll let you know what happens.) Okay, I tried enabling the "doc" USE flag for media-video/mpv in my fresh chroot, but it still successfully installed. Hmm. Something doesn't add up here. I didn't have doc use flag on - I enabled that, and I am still able to install mpv. Also confirmed that rst2pdf is called as part of the build: [211/213] Compiling DOCS/man/mpv.rst 21:06:14 runner ' /usr/bin/rst2html.py ../DOCS/man/mpv.rst DOCS/man/mpv.html ' [212/213] Compiling DOCS/man/mpv.rst 21:06:16 runner ' /usr/bin/rst2man.py --strip-elements-with-class=contents ../DOCS/man/mpv.rst DOCS/man/mpv.1 ' [213/213] Compiling DOCS/man/mpv.rst 21:06:18 runner ' /usr/bin/rst2pdf -c -b 1 --repeat-table-rows ../DOCS/man/mpv.rst -o DOCS/man/mpv.pdf ' So I copied my make.conf, package.accept_keywords, package.license and package.use wholesale from my host system into the chroot, and no matter what I do, I couldn't reproduce the sandbox violation error in the chroot. Going off of my idea that this might be a fontconfig cache issue, I first tried using "fc-cache -rfv" to reconstruct the fontconfig cache in the chroot, and that didn't change anything. Then I wondered if this might be a problem with *my* fontconfig cache somehow, so I took a backup of my /var/cache/fontconfig directory and ran "fc-cache -rfv" on the host. This ended up resolving the issue, and I can now emerge mpv successfully. I'm not altogether sure how my fontconfig cache got into a state where it needed reconstruction like this, but it appears to have done the trick. It seems like Portage should take care of something like that though. Is there a way you can signal in the ebuild that Portage should update the fontconfig cache after emerging firestorm-bin? In any case, thanks for your help in diagnosing! I'm not sure what you'd like me to do with this bug, but I do still have my backup fontconfig cache directory if we need to investigate this more. Okay, I investigated a little and it looks like the easiest way to solve this is by including "inherit font" in the ebuild. The font eclass rebuilds the cache in font_pkg_postinst unconditionally, so I believe this should be all you need to do. mpv is irrelevant, firestorm-bin does not handle global fontcache properly. mpv was incidental as it turned out, yes, but I had filed this bug against the ebuild in the 'lmiphay' repository, using the Overlays component to do so. My suggestion to do 'inherit font' to rebuild the font cache after merge was intended for the firestorm-bin ebuild, not mpv. As far as I know there isn't another place for me to file bugs against the 'lmiphay' repository, and I thought this was the correct place to do so in that case. Should I file another bug without mentioning mpv this time, now that we know the cause? If not, what can/should I do? So I tried & failed to recreate this both with: 1. emerge -C =firestorm-bin-6.3.2-r2 fc-cache -rfv emerge =firestorm-bin-6.3.2-r2 emerge mpv and 2. emerge -C =firestorm-bin-6.3.2-r2 cd /var/cache && mv fontconfig fontconfig.orig && mkdir fontconfig fc-cache -rfv emerge =firestorm-bin-6.3.2-r2 emerge mpv In both cases mpv built and installed without a sandbox violation. Since it seems reasonable and doesn't appear to break anything else, I have added an inherit font to rev -3 and pushed that as: https://cgit.gentoo.org/user/lmiphay.git/commit/?id=99c0de2ebab9a047a2ed2d499b4c0335a533d8f6 Confirm that you see as part of the merge output: "* Updating global fontcache ..." Thanks! Paul |
