Red Hat Bugzilla – Bug 249646
fc-cache does not cache newly installed fonts if /usr/share/fonts has newer modtime
Last modified: 2013-04-12 15:16:03 EDT
+++ This bug was initially created as a clone of Bug #249644 +++
Description of problem:
fc-cache is not always caching newly installed fonts in fonts-chinese.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Fresh install RHEL 5 without Chinese support.
2.Install fonts-chinese: rpm -ivvh fonts-chinese*.rpm > rpm_inst_log
3.fc-list | sort > fc-list_out
- rpm_inst_log shows fc-cache had been run.
- fc-list_out doesn't show all installed fonts: ShanHeiSun, ZenKai.
- rpm_inst_log shows fc-cache had been run.
- fc-list_out shows all installed fonts: ShanHeiSun, ZenKai.
Please let us know how did you meet the problem.
Well, I have done a fresh install of RHEL 5 without Chinese support, then I have
figured out that I need to install fonts-chinese package to browser Chinese
website in GNOME. Therefore, I have mounted mohe:/data, and installed
Unfortunately, even after rebooted the machine, fc-list did not show any Chinese
fonts been registered. To fix my problem, I have to run "fc-cache -fr" manually
within chinese font directory.
Hi Cai Qian, could you please kindly test it again using:
It looks like have fixed the problem. I have verified it by removing
fonts-chinese, and run "fc-cache -f". Then, fc-list did not show any Chinese
fonts anymore. After installed the new package, fc-list shows them immediately.
Hi Cai, would you be possible to check how reproducible is the bug? Does it
happen ONLY from fresh installed RHEL5, or it may also happens sometimes along
series of 'installation and removal' steps? - Cheers, Caius.
After some further experiments, both 3.02-9.6.el5 and 3.02-9.9.el5 work
following instructions in comment #4. Therefore, the bug does probably only
happen from fresh installed RHEL5. I'll try to reproduce soon if I have had a
I might go test with fresh installed RHEL5 with VM.
I finally have had to change to test it today. I have tried both fonts-chinese
versions after fresh installation, fc-list does not show any chinese fonts.
After run "fc-cache -f" manually, fonts correctly show in the list. Please see
attachment for the log during package installation.
Created attachment 160882 [details]
rpm upgrade log
I have analyzed a similar bug. It is because of changing of system-time. please
refer to bug 223178 .
1. Fresh installed system, i.e. f8.
2. Set the clock at pasted time: `system-config-time`.
3. Install fonts-chinese: `rpm -i fonts-chinese-3.03-13.fc8.noarch.rpm`.
4. Check: `fc-list | grep uming`.
Bug is reproduced followed comment# 11.
So probably it helps to give the path of the actual font directory to fc-cache
rather than the generic /usr/share/fonts.
I suppose that fc-cache should give a return value to indicate the update
status, and then we could check it in rpm script. If we found no folders are
updated, we should use -f argument to run it again.
At least fc-cache on the newly installed font directories should not fail
since the timestamp will not be affected by clock-skew.
But it will not update the cache file for /usr/share/fonts. This cache file
stores how many and which subfolders in /usr/share/fonts. If this cache is
outdated, I think it would cause some problems.
I thought out a simple way to fix this problem.
step 1: run fc-cache
step 2: use fc-cat /usr/share/fonts/chinese to check whether the cache have been
step 3: if not, run fc-cache -f to recreate all cache files.
(In reply to comment #17)
> I thought out a simple way to fix this problem.
> step 1: run fc-cache
> step 2: use fc-cat /usr/share/fonts/chinese to check whether the cache have been
> created properly.
> step 3: if not, run fc-cache -f to recreate all cache files.
The actual work under fc-cache is not that simple as the above step. if that's
the case, just fc-cache -f would be much simpler. I'd like to have a solution
not to run fc-cache with -f, though.
However it's probably impossible without a fix of fontconfig IMHO. we may want
to think about more how fontconfig helps us in this case.
This is not really a fonts-chinese specific bug at all so reassigning
to fontconfig for comments.
*** Bug 223178 has been marked as a duplicate of this bug. ***
How about we store fontdirs' timestamps in cache files and consider a cache is
invalidate when fontdir's timestamps is not equal to stored timestamps in cache?
I think even if the system is incorrect, it is impossible that fontdir's
timestamps are not changed when the directory is being changed.
If you have any suggestions, I appreciate it if you bring it up on the
fontconfig mailing list. I agree that it can be improved, but don't see it as a
Alternatively, we can use fc-cache -f unconditionally in all font packages, but
that's not optimal.
Created attachment 245101 [details]
store directory's mtime in cache file
This problem has been fixed in upstream. I get this patch from upstream's
source repository. But It is base on 2.4.2. We should update our version from
2.4.1 to 2.4.2.
Created attachment 245121 [details]
Add sparc64 architecture string.
If we want to patch store_mtime_in_cache.patch on 2.4.1, we must patch this
patch at first. It can resolve a conflict in fc-arch/fcarch.tmpl.h .
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. This request will
be reviewed for a future Red Hat Enterprise Linux release.
I dunno if this would require a version rebase -
anyway looks pretty unlikely to me.
Closing given that it is an internally reported bug