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.