Description of problem: The shell function buildfontlist() has a logical flaw. In the "for d in $()" loop, the variable REGEN_FONTS_DIR is reset each time to "no" and set to "yes" if that particular directory needs to be regenerated. fc-cache is run afterwards if _any_ directory was regenerated. But what happens if the very first iteration of the loop regenerated the directory, but all subsequent ones didn't? The test [ $REGEN_FONTS_DIR" = "yes" ] will not trigger because the later iteration of the loop reset the variable to "no". Version-Release number of selected component (if applicable): All from RH9 through the latest Actual results: fc-cache is only run if the last iteration of the loop encountered a directory that needs to be regenerated. Expected results: Any regenerated directory should trigger fc-cache Additional info: See attached patch.
Created attachment 104242 [details] Fix for this problem
Actually, it might be cleaner to change the above patch to have the "REGEN_ANY=yes" be in only one place: after if [ "$REGEN_FONTS_DIR" = "yes" ]; then This way, it should be easier to maintain
Created attachment 111826 [details] Patch This patch is an attempt at fixing both 133451 an 133453, plus generally speeding up the xfs initscript. What it does is - Always run fc-cache whether or not anything changed. If the fontconfig cache is already uptodate, fc-cache is very fast - basically it only stat()s the directories and the fonts.cache files, so no point trying to be clever. - Check the mtime of font directories and the fonts.dir files, and only regenerate the fonts.* files in that case. - Whenever we do generate the fonts.dir file, set the mtime of fonts.cache-*, fonts.dir and the font directory to the same value. A cheesy hack to make sure the various metadata generators don't step on each other's toes. This should fix both bugs, and avoid the find/grep/ls statting every font file on startup. Note that the shell "-nt" test returns true both if mtime is newer and if the second file does not exist.
I believe this patch also fixes bug 74398. (Also, I realized that it probably isn't going to make any real performance difference since find/ls/grep is not actually stat()ing the individual files - it only reads the directories).
Me and Soeren discussed this bug, and his proposed patch today for a while, and ran through different scenarios. I decided to simplify the initscript as much as possible, to reduce complexity without changing operation extensively, and at the same time trying to avoid introducing new regressions or other issues. This basically removes all of the REGEN_FONTS_DIR stuff by putting that logic directly in the if statement which was the main use. We now run fc-cache always, since it runs very fast anyway, and fonts may have been added/removed/changed in fontconfig configured directories which are not even configured in xfs. fc-cache internally searches the directories fontconfig is configured to use, rather than the dirs xfs is configure to use, which is what we were attempting to do before. For dirs fontconfig is configured to use, fc-cache will regen the fonts.cache* files only if necessary, which achieves what we really were wanting to begin with, but in a more sensible manner. A couple of other cleanups I made should speed up xfs initscript a slight bit also in some cases. The end result, should be that this bug is no longer present, fc-cache is now ran to ensure all fontconfig configured font directories have their cache files updated, wether or not mkfontdir et al. were ran, and this will have more likelyhood of improving the performance of client side fonts as well. I have not committed the new initscript to CVS yet, as I'd like you to test it with your setup first: ftp://people.redhat.com/mharris/xfs.init Please test that, and update the bug report to indicate if you see any regressions or other problems. Thanks in advance. Setting status to "NEEDINFO", awaiting test results.
Feedback from the Fedora community indicates this issue seems to be resolved. Setting status to RAWHIDE.
From User-Agent: XML-RPC xorg-x11-6.8.2-1.FC3.45 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.