Bug 1169979
| Summary: | fontconfig cache updating does not work reliably during live image generation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||||
| Component: | fontconfig | Assignee: | Akira TAGOH <tagoh> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 24 | CC: | andrew, fonts-bugs, i18n-bugs, massi.ergosum, mcatanzaro+wrong-account-do-not-cc, mfabian, pnemade, rdieter, rwf, tagoh | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-06-10 06:50:04 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Adam Williamson
2014-12-02 21:57:48 UTC
Created attachment 963917 [details]
F21 Workstation with the good font (DejaVu Sans Mono)
Created attachment 963919 [details]
F21 Workstation with the bad font (Nimbus Mono L)
To give an idea of the practical impact of this bug on Fedora 21 Final RC2, see these screenshots - one with the font that ought to be used (DejaVu Sans Mono), one with the font that winds up getting used (Nimbus Mono L).
Proposed as a Freeze Exception for 21-final by Fedora user catanzaro using the blocker tracking app because: Would be sweet to use the big hammer workaround proposed in comment #0; that seems safe enough for this stage in the game and would. I was actually angling to just ninja this one in as all it requires is a spin-kickstarts change, but +1 FE. We do have the option of firing a complete RC3 for the spin-kickstarts fix (even though non-lives would not be affected at all) and then we can decide what to do with rc2 and rc3 on Thursday. I just tested a Workstation network install, as it seems plausible that regular installs could suffer from this too. It was fine. I suspect perhaps the time taken to download packages helps, if we're figuring this is some kinda timing issue with fc-cache. live image creation retrieves all the packages first; network installation downloads packages one at a time during the install process. So, perhaps a network install over a local network might hit it. I'm gonna count this from rdieter as a +1 FE: <rdieter> oh my bad, sorry. use big hammer, yes <rdieter> go forth, and hammer like youve never hammered before <rdieter> make thor proud also from roshi: <roshi> I'm for respinning the lives so let's call this AcceptedFreezeException at this point. I grabbed RC4 Workstation x64 and verified the fc-list count doesn't change with an `fc-cache -f`. And Terminal uses the correct font. This is verified addressed via the spin-kickstarts workaround in F21 Final, however, the underlying bug in font-config and possibly scriptlets must still be there. So I'm dropping the FE status markers and setting bug to ASSIGNED. (In reply to Adam Williamson (Red Hat) from comment #4) > I just tested a Workstation network install, as it seems plausible that > regular installs could suffer from this too. It was fine. I suspect perhaps > the time taken to download packages helps, if we're figuring this is some > kinda timing issue with fc-cache. live image creation retrieves all the > packages first; network installation downloads packages one at a time during > the install process. So, perhaps a network install over a local network > might hit it. I just ran into this issue with one of two desktops that were built up from minimal network installs and an "add just the stuff I need" script: after installing the @fonts group (among other things), one had Nimbus Mono L as the only available monospace font, before manually running fc-cache -f. The other system was fine, which seems to confirm your suspicion above. Is there a fontconfig bug open anywhere for this? I've been using this same basic process for (re)installs since FC3, and was blissfully unaware of the fontconfig cache until now... -Rob "Is there a fontconfig bug open anywhere for this?" This is it - this bug is assigned to fontconfig. it has some workarounds to avoid similar situations but I have no idea why it happened at this moment. Akira: I can at least say that it seems definitely to have changed somehow between 20 and 21. I test booted several F20 Final, Alpha and Beta live images and none of them displayed the problem. (In reply to Adam Williamson (Red Hat) from comment #11) > Akira: I can at least say that it seems definitely to have changed somehow > between 20 and 21. I test booted several F20 Final, Alpha and Beta live > images and none of them displayed the problem. not really. 2.11.0 also had that issue. it just happened to work for f20 fortunately or unfortunately. I find that hard to believe, the chances would be astronomical. *Every* F21 live compose I checked, going back to Beta, had the bug. *Every* F20 live compose I checked did not. I can believe the F20 version had some issues in this area, but I don't believe it had the specific issue that affects the live compose scenario. Akira, is there some way to force cache invalidation for a folder, set, or particular font? If so, we could use that technique in our font-related rpm scriptlets to make this more reliable. -f option do as we did for a workaround like the above. This (or something very similar) seems to be affecting Fedora 22 also (netinst install) $ rpm -qa dejavu-sans-mono-fonts dejavu-sans-mono-fonts-2.35-1.fc22.noarch $ fc-match monospace n022003l.pfb: "Nimbus Mono L" "Regular" $ sudo fc-cache -f $ fc-match monospace DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book" BTW, re-installing the rpm also fix's it. Maybe we can drop the kickstart workaround from rawhide spin-kickstarts and see if it's OK now, if I'm following #1236034 correctly? Yes, please. This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. OK, I'm gonna bump this to Rawhide and drop the workaround from Rawhide spin-kickstarts, and we can close it if things still look good after that. This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase I guess this can be closed now? that would be nice to test on f24 and rawhide as well because there has been made some changes in that area between f24's and rawhide's. I haven't noticed any such issues on F24 yet, I think closing for now is fine. Will re-open or file a new bug if problems show up again. |