Red Hat Bugzilla – Bug 100589
Stale /usr/share/fonts/fonts.cache-1 blocking fonts caching
Last modified: 2007-04-18 12:56:00 EDT
Description of problem:
If new fonts are added under a new subdirectory under /usr/share/fonts (e.g.
installing bitstream-vera-fonts after Severn is installed), the fonts won't be
available even after running fc-cache unless fonts.cache-1 is removed first.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a new subdir, say 'test' under /usr/share/fonts/test
2. Copy a TTF file into said directory
3. Run 'fc-cache /usr/share/fonts'
cat'ing /usr/share/fonts/fonts.cache-1 does not list new 'test' directory - no
fonts.cache-1 created in 'test' either
/usr/share/fonts/fonts.cache-1 updated, fonts.cache-1 created in test as well,
new font available to fontconfig apps
/usr/share/fonts/fonts.cache-1 needs deletion before running fc-cache, then
Quick check - your system time is reasonable and was reasonable
during the install?
Ah ! Err... guess that's it then. My clock is always NTP'ed, that's why I did
not suspect clock skew. I dual-boot with XP so I could not set system time to UTC.
Now to think of it, there *was* that warning that came up when starting sendmail
saying modification time is in the future.
But wait. My timezone is UTC+7, how did I manage to get future modification
time? Oh, timestamps are stored in UTC time...
Should I file a bug for Anaconda instead, an RFE asking for timezone selection
to be brought forward? A quick hack would be to set the system day back one day
before install, but that's.. ugh.
Hmmm, the installer does have time zone selection, so if your
system clock is set to the right time (or approximately the
right time) then things should be fine.
Maybe you simply forgot to set the timezone during install?
If that was the case, then you'd get timestamps in the future
because I think the default is US/Eastern which is -0400, so
all your timestamps would be 11 hours in the future.
I do not think I forgot the timezone twice in a row - in fact I am fairly
certain I selected it both times. What I reckon happened is that RPMs were
installed before timezone is selected, and say I do the install around 12pm UTC,
that is, 7pm Western Indonesia Time. The system thought my time was UTC because
I have not told it otherwise, so all files are stamped 7pm *UTC*. Then after
install is finished, Linux knows to subtract 7 hours from the reported hardware
time to get UTC time, so the filestamps are 7 hours in the future since in
reality it is still 12pm UTC.
Hope that made sense. Certainly explains why I get that sendmail warning quite
often after new installs - so, Anaconda bug?
Cc'ing Jeremy Katz in case I'm wrong, but I believe the timezone setting
does take effect *before* the files are installed. There are many
reasons why you want timestamps right for package installation.
So, I think something else is going wrong with your install procedure;
perhaps your system clock is simply way off, and you haven't noticed
because you are using NTP?
Rather unlikely; the software clock is saved to hardware when shutting down, and
since I did two installs one day after another, my clock has to be severely
dysfunctional to go off by a few hours in such a time span.
[michel@bushido michel]$ /usr/sbin/hwclock && date
Fri 25 Jul 2003 10:43:10 WIT -0.968829 seconds
Fri Jul 25 10:43:09 WIT 2003
This is rather bizarre indeed...
Closing as NOTABUG since I don't think there will be any more
useful information at this point.