Description of problem: There are new chinese fonts available, hence the ttf files are not included into anaconda stage 2. Version-Release number of selected component (if applicable): How reproducible: everytime Steps to Reproduce: 1. boot into anaconda using chinese 2. and go to shell and ls -la /usr/share/fonts Actual results: 1. The fonts are using japanese glyphs 2. /usr/share/fonts/chinese/* is not available Expected results: 1. Using chinese glyphs 2. /usr/share/fonts/chinese/* is available Additional info: the fonts are in fonts-chinese package files are /usr/share/fonts/chinese/TrueType/u{kai,ming}*.ttf
Do these two fonts replace /usr/share/fonts/chinese/TrueType/{bsmi001p,gbsn001p.ttf} or are they in addition to those?
These fonts are significantly larger which is going to have a negative impact on the size of the installer second stage :/ But added
Apologies, we should only need to include uming.ttf because both Simplified and Traditional Chinese glyphs are in that font for Sans face. This should help on the second stage size. Thanks Tagoh-san for the reminder. In short, uming replaces {bsmi001p,gbsn001p}.ttf
Changed the list we include to just be uming*
Hmm, having uming* makes it so that when we load the chinese fonts, we segfault. Bind mounting an empty dir makes it go away -- any clue what might cause this? Otherwise, we might need to pull the font for test1
Backtrace looks something like #0 FcFreeTypeCharIndex #1 pango_fc_font_create_metrics_for_context #2 pango_fc_font_get_glyph ....
More details.. #0 FcFreeTypeCharindex(face=0x0, ucs4=31616) at fcfreetype.c:2311 #1 pango_fc_font_real_get_glyph at pangofc-font.c:514 #2 pango_fc_font_get_glyph at pangofc-font.c:623 Not sure why pango_fc_font_lock_face is returning NULL.
I just ran anaconda with --test --method_nfs://... but it looks good to me. how can I reproduce this?
ok, I can now reproduce this on stage2.img chroot'ed. and it also appears on Japanese as well.
ok, I got a workaround for this now. it works fine after run fc-cache on chroot.
We're already running fc-cache on the root so I'm not sure how this is changing anything. How are the font caches different?
running it when stage2.img was built? hmm, it's hard to check how are their different since the cache file became the binary file.
Yeah, we run 'chroot $DESTGR /usr/bin/fc-cache' when we create the second stage and there's no errors in the tree log to make me think there's anything wrong. Also, if there were, the fonts.cache files wouldn't be there as they're not shipped in the package.
how about the timestamp? I just noticed that all files timestamp was 1970-01-01 00:00:00. is it the same as when the second stage image was being built? I'm not sure if it's really related to this though. and I don't see anything else difference between the second stage and the installed environment. actually this problem won't happens on the installed environment since all gtk2 apps works fine without any exceptions.
cramfs actually doesn't store timestamps and sets all the times just to 0 when requested. That does sound like a plausible though, though
Sounds like it would have the potential to screw up cache uptodate checks, etc
Aha, I see what it is. The font is 20 megs. cramfs has a max file size of 16 megs. Any way we can get this font smaller? ;)
Okay, for test1 I'm just not going to include the new font. For test2, I'm going to see if we can move to squashfs (which involves bribing davej with tacos...)
We've moved to squashfs, so the new font has gone back in. Please test and let us know if it's working.
Checked with anaconda-10.90.21-1, verfied that /usr/share/fonts/chinese/* is now available.