+++ 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): fonts-chinese-3.03-4 How reproducible: Sometimes. 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 Actual results: - rpm_inst_log shows fc-cache had been run. - fc-list_out doesn't show all installed fonts: ShanHeiSun, ZenKai. Expected results: - rpm_inst_log shows fc-cache had been run. - fc-list_out shows all installed fonts: ShanHeiSun, ZenKai. Additional info:
Cai Qian, 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 RHEL5-Client-20070208.0/tree-i386/Client/fonts-chinese-3.02-9.6.el5.noarch.rpm. 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: http://porkchop.devel.redhat.com/brewroot/packages/fonts-chinese/3.02/9.9.el5/noarch/fonts-chinese-3.02-9.9.el5.noarch.rpm Cheers, Caius.
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 chance.
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 .
test case: 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 created properly. 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 high-prio bug. 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