Created attachment 610376 [details] emerge --info Gimp 2.10.14 failes to build on my system. The most obvious problem seems to be: * ACCESS DENIED: mkostemp: /usr/share/fonts/custom/.uuid.TMP-XXXXXX
Created attachment 610378 [details] media-gfx:gimp-2.10.14:20200201-092621.log.gz Gzipped due to size limitation
Could you please provide the information what package of portage tree installs into "/usr/share/custom" directory? This info could be obtained e.g. by command equery b /usr/share/custom where equery is a tool of package "app-portage/gentoolkit".
This issue looks similar to https://bugs.gentoo.org/698526 https://bugs.gentoo.org/705502
I was able to fix this myself. There was a directory '/usr/share/fonts/custom' with three ttf files, but no '.uuid' file. The directory seemed to be orphaned, no package was claiming it. Removed it, now Gimp builds fine. But the question is, should a package build fail because of that? Would be better to just ignore invalid contents.
(In reply to Maxxim from comment #4) > I was able to fix this myself. There was a directory > '/usr/share/fonts/custom' with three ttf files, but no '.uuid' file. The > directory seemed to be orphaned, no package was claiming it. Removed it, now > Gimp builds fine. > > But the question is, should a package build fail because of that? Would be > better to just ignore invalid contents. This is common sandbox issue (as I see that): some packages like gimp during install try to use font cache and if some font directory is't in cache for some reason then sandbox fails. Maybe the related font doesn't update cache during install and then during removing.
Could I then close this issue?
(In reply to Sergey Torokhov from comment #6) > Could I then close this issue? Well, that depends. I think this should be addressed somehow. It would be much better if packages that access the font cache ignore invalid contents. There should at least be an error message that tells users what the problem is (font cache) and how to fix this. * ACCESS DENIED: mkostemp: /usr/share/fonts/custom/.uuid.TMP-XXXXXX is not really something people can work with...
(In reply to Maxxim from comment #7) > (In reply to Sergey Torokhov from comment #6) > > Could I then close this issue? > > Well, that depends. I think this should be addressed somehow. It would be > much better if packages that access the font cache ignore invalid contents. I suppose that ignoring unavailable content isn't good way as sandbox doesn't know the reason why this content is invalid. Therefore sandbox can't advise the solution. It just report access error for content (fontcache, ccache items etc.). > There should at least be an error message that tells users what the problem > is (font cache) and how to fix this. > > * ACCESS DENIED: mkostemp: /usr/share/fonts/custom/.uuid.TMP-XXXXXX > > is not really something people can work with... As the initial reason of fontcache error couldn't be determined (it's hard to reproduce also) and the ebuild of this font is absent in portage tree anymore, I close the bug as "Invalid". If the font ebuild was presented in portage tree then it can be repaired.
