Noticed on ChromeOS when installing a large number of font packages in parallel:
/usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (------r--) to 2440 (r--r-S---) * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase): * failed to fix font files perms The "#new" filename is the hint. Portage uses "#new" suffixes when copying files to the system, and then renames them to their final filenames. This code was executing while another font was in the process of being copied to the system. Font packages should just ensure that they install files with correct permissions to begin with, and all except media-fonts/x11fonts-jmk already use 0644 permissions. media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the previous commit which changes its installed files to 0644. Bug: https://bugs.gentoo.org/187774 Signed-off-by: Matt Turner <matts...@gentoo.org> --- eclass/font.eclass | 6 ------ 1 file changed, 6 deletions(-) diff --git a/eclass/font.eclass b/eclass/font.eclass index 4970c959f7c..0196755ce3e 100644 --- a/eclass/font.eclass +++ b/eclass/font.eclass @@ -186,12 +186,6 @@ font_src_install() { # @DESCRIPTION: # Updates fontcache if !prefix and media-libs/fontconfig installed _update_fontcache() { - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then - # unreadable font files = fontconfig segfaults - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \ - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files perms" - fi - if [[ -z ${ROOT} ]] ; then if has_version media-libs/fontconfig ; then ebegin "Updating global fontcache" -- 2.37.4
