From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E0A80158020 for ; Tue, 8 Nov 2022 20:30:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D029CE09F3; Tue, 8 Nov 2022 20:29:57 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8CC8EE09E3 for ; Tue, 8 Nov 2022 20:29:57 +0000 (UTC) Received: by mail-pl1-f172.google.com with SMTP id j12so15184507plj.5 for ; Tue, 08 Nov 2022 12:29:56 -0800 (PST) X-Gm-Message-State: ANoB5plh03LhHFV2eluCWtYtRnSXKW1zb4dfM0vkSqAyqVGc9Y8toY4I Ze8k/Oe3zjv+dZzbCcr5nKf2+J3eoXvlhQbvLFU= X-Google-Smtp-Source: AA0mqf762RCwMg1ozJk20F5AlDXdCQnD3TOSBZiixCV3G1/13pAn7psR3jGFn0JVfdJWV5H4T31PEMr7u6RdJvS0lDk= X-Received: by 2002:a17:902:788f:b0:188:641b:5372 with SMTP id q15-20020a170902788f00b00188641b5372mr25768460pll.159.1667939395171; Tue, 08 Nov 2022 12:29:55 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20221108011008.61823-1-mattst88@gentoo.org> <20221108011008.61823-2-mattst88@gentoo.org> <568F0AB7-82C2-4E35-828B-7617AF31B04D@gentoo.org> In-Reply-To: <568F0AB7-82C2-4E35-828B-7617AF31B04D@gentoo.org> From: Matt Turner Date: Tue, 8 Nov 2022 15:29:43 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code To: Sam James Cc: gentoo-dev@lists.gentoo.org, fonts@gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 74fae28d-08f6-4ab3-a679-b44f20d4b008 X-Archives-Hash: f5b2c5981d5741157644994e55faef32 On Mon, Nov 7, 2022 at 11:11 PM Sam James wrote: > > > > > On 8 Nov 2022, at 01:10, Matt Turner wrote: > > > > 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 > > --- > > 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" > > -- > > Can we put an fperms call in src_install just in case (like the eclass originally had > before moved to pkg_postinst)? We can if you think it's necessary, but to be honest I think that the original bug should have been WONTFIX. The user was manually installing fonts into their system and then complained that things didn't work when they configured the fonts with the wrong permissions. I don't think fonts getting installed with unreadable permissions is a real problem.