https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Bug ID: 1169979 Summary: Some fonts not in fontconfig cache on Fedora 21 live images Product: Fedora Version: 21 Component: fontconfig Assignee: tagoh@redhat.com Reporter: awilliam@redhat.com QA Contact: extras-qa@fedoraproject.org CC: fonts-bugs@lists.fedoraproject.org, i18n-bugs@lists.fedoraproject.org, pnemade@redhat.com, tagoh@redhat.com
We've spotted an issue with Fedora 21 live images where some installed fonts appear to be missing from the fontconfig cache in the live environment. An 'fc-cache -f' fixes this. For instance, on the Fedora 21 Final RC2 Workstation x86_64 live:
[root@localhost liveuser]# fc-list | wc -l 141 [root@localhost liveuser]# fc-cache --force [root@localhost liveuser]# fc-list | wc -l 159
The specific fonts that are missing on that image are:
/usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique /usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book
/usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic
/usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed,Book /usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic /usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book
/usr/share/fonts/google-noto/NotoSansTagalog-Regular.ttf: Noto Sans Tagalog:style=Regular /usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai Viet:style=Regular
/usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf: Liberation Serif:style=Bold Italic /usr/share/fonts/liberation/LiberationSerif-Bold.ttf: Liberation Serif:style=Bold /usr/share/fonts/liberation/LiberationSerif-Italic.ttf: Liberation Serif:style=Italic /usr/share/fonts/liberation/LiberationSerif-Regular.ttf: Liberation Serif:style=Regular
The log of the compose is here:
https://kojipkgs.fedoraproject.org//work/tasks/5463/8275463/root.log
In comparison, the i686 Workstation live is 'missing' only
/usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai Viet:style=Regular
its compose log is here:
https://kojipkgs.fedoraproject.org//work/tasks/5460/8275460/root.log
to me, it appears the affected cases are ones where more than one package contains fonts in the same directory, for packages installed *after* the fontconfig package. The fontconfig package has an 'fc-cache -f' in its %post, so any inconsistencies that exist before it's installed get fixed by that.
My first thesis was 'for any given directory, only fonts from the first package installed after fontconfig will make it to the cache, fonts in the same directory from subsequently-installed packages won't be added'. But it doesn't seem to be that simple, because some fonts in /usr/share/fonts/google-noto *are* added - the first 'noto' package installed is google-noto-sans-lisu-fonts , and after that several more noto packages are installed. The fonts from google-noto-sans-mandaic-fonts, google-noto-sans-meeteimayek-fonts , and google-noto-sans-tai-tham-fonts *do* get added to the cache - but the fonts from google-noto-sans-tagalog-fonts and google-noto-sans-tai-viet-fonts do *not* get added. It's quite odd.
This is a fairly bad bug because of its impact on DejaVu Sans Mono: this is the default monospace font for both Workstation and KDE (and I think the non-blocking spins too). Its absence from the cache results in them using Nimbus Mono L as their monospace fonts, which is a pretty crappy font, ugly and hard to read. The workaround is easy once you know it, but if you don't, you just think we have a really bad font.
There's an easy big hammer workaround we can use for a quick rebuild of the RC2 lives, if we like:
--- a/fedora-live-base.ks +++ b/fedora-live-base.ks @@ -299,6 +299,12 @@ rm -f /core* # convince readahead not to collect # FIXME: for systemd
+# forcibly regenerate fontconfig cache (so long as this live image has +# fontconfig) - see #XXXXXXX +if [ -x /usr/bin/fc-cache ] ; then + fc-cache -f +fi + %end
i.e., just do an fc-cache -f at the end of live generation %post. I've tested that locally, and it works, the generated Workstation image has 159 fonts in fc-list (I also generated an image with the exact same config and build host, but no change to spin-kickstarts, to verify that it reproduced the bug, and it does).
The real fix should likely be in fc-cache, but the spin-kickstarts workaround would solve this problem for F21.
I think fc-cache's behaviour must have changed between F20 and F21, as F20 doesn't appear to be affected by this at all, at least not the x86_64 desktop live. All F21 images I've tested seem to be affected to some extent, though the exact affected fonts vary depending on the package install order that yum decided on.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #1 from Adam Williamson (Red Hat) awilliam@redhat.com --- Created attachment 963917 --> https://bugzilla.redhat.com/attachment.cgi?id=963917&action=edit F21 Workstation with the good font (DejaVu Sans Mono)
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #2 from Adam Williamson (Red Hat) awilliam@redhat.com --- Created attachment 963919 --> https://bugzilla.redhat.com/attachment.cgi?id=963919&action=edit 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).
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Fedora Blocker Bugs Application blockerbugs@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mcatanzaro@gnome.org Blocks| |1043131 | |(F21FinalFreezeException,Fi | |nalFreezeException)
--- Comment #3 from Fedora Blocker Bugs Application blockerbugs@fedoraproject.org --- 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.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1043131 [Bug 1043131] Fedora 21 Final freeze exception bug tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #4 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Adam Williamson (Red Hat) awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |AcceptedFreezeException
--- Comment #5 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Adam Williamson (Red Hat) awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |VERIFIED
--- Comment #6 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Adam Williamson (Red Hat) awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |ASSIGNED Blocks|1043131 | |(F21FinalFreezeException) | Summary|Some fonts not in |fontconfig cache updating |fontconfig cache on Fedora |does not work reliably |21 live images |during live image | |generation Whiteboard|AcceptedFreezeException |
--- Comment #7 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1043131 [Bug 1043131] Fedora 21 Final freeze exception bug tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Rob Foehl rwf@loonybin.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rwf@loonybin.net
--- Comment #8 from Rob Foehl rwf@loonybin.net --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #9 from Adam Williamson (Red Hat) awilliam@redhat.com --- "Is there a fontconfig bug open anywhere for this?"
This is it - this bug is assigned to fontconfig.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #10 from Akira TAGOH tagoh@redhat.com --- it has some workarounds to avoid similar situations but I have no idea why it happened at this moment.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #11 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #12 from Akira TAGOH tagoh@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #13 from Adam Williamson (Red Hat) awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #14 from Rex Dieter rdieter@math.unl.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #15 from Akira TAGOH tagoh@redhat.com --- -f option do as we did for a workaround like the above.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Andrew Clayton andrew@digital-domain.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@digital-domain.net
--- Comment #16 from Andrew Clayton andrew@digital-domain.net --- 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"
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #17 from Andrew Clayton andrew@digital-domain.net --- BTW, re-installing the rpm also fix's it.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Kamil Páral kparal@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1236034
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #18 from awilliam@redhat.com awilliam@redhat.com --- Maybe we can drop the kickstart workaround from rawhide spin-kickstarts and see if it's OK now, if I'm following #1236034 correctly?
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #19 from Akira TAGOH tagoh@redhat.com --- Yes, please.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #20 from Fedora End Of Life endoflife@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
awilliam@redhat.com awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |ON_QA Version|21 |rawhide
--- Comment #21 from awilliam@redhat.com awilliam@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #22 from awilliam@redhat.com awilliam@redhat.com --- https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=db62fb95bbb...
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #24 from Akira TAGOH tagoh@redhat.com --- I guess this can be closed now?
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
--- Comment #25 from Akira TAGOH tagoh@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1169979
Adam Williamson awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Resolution|--- |RAWHIDE Last Closed| |2016-06-10 02:50:04
--- Comment #26 from Adam Williamson awilliam@redhat.com --- 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.
i18n-bugs@lists.fedoraproject.org