If user does "umask 0117" then fontconfig creates ~/.fontconfig for the first time, things become stinky as fontconfig can't read/write any files in that directory. We should: 1) chmod explicitly after every dir and file creation, 2) monitor our stat and open uses and add a "chmod and retry" step where applicable.
In my tree: Created commit 542cc57: Explicitly chmod() directories (bug #18934) 1 files changed, 11 insertions(+), 3 deletions(-)
I believe I've fixed this in 2.7.0. Please reopen otherwise.
This commit breaks several packages that use fc-cache during make install in Gentoo (eg. all xorg ttf and type1 fonts). We build and install into a DESTDIR in a sandboxed environment that prevents all modifications to the host file system. The explicit chmod breaks this sandbox. We already ensure the cache dir has proper permissions when we regenerate the cache ourselves after merging the DESTDIR to the host system, so I'd like to request that fc-cache first check the permissions of the of the cachedir and chmod only if they are not correct.
How is that breaking things if cache files are being made anyway? Got any patch to show?
good question, and one i don't have an answer to. there are deeper issues here. i have breakages in packages that don't even use fc-cache as far as i can tell, such as groff (due to ghostscript) and kdelibs (due to dot). rather than chase them each down and annoy you, I've just reverted this in Gentoo. Thanks.
You reverted the patch in gentoo you mean? That does not sound much better either.
i was going to. but in the end i just added an override to our sandbox to allow changes to /var/cache/fontconfig during installs. it should be harmless. :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.