On Sunday 18 March 2007, Michael Schwendt wrote: >On 18/03/07, Gene Heskett wrote: >> root@coyote ~]# rpm -V fontconfig >> SM5....T c /etc/fonts/fonts.conf >> SM5....T /etc/fonts/fonts.dtd >> .M...... /usr/share/fonts >> >> But whats that lowercase 'c' trying to tell me? > >It is 'c' as in 'config file'. > >> Is there a single >> file that's dated the day of the install? > >Most reliable: > > rpm -qa --last | tail Thu 09 Nov 2006 08:24:54 AM EST So that would have been the morning I installed FC6. And the first time I saw this error was when I installed msttcorefonts from an rpm. [root@coyote fonts]# rpm -qa --last | grep msttcorefonts msttcorefonts-2.0-1 Thu 25 Jan 2007 02:12:07 AM EST Which gives me a date, and I posted to this list under the subject of: msttcorefonts install breaks FC6 printing, help! On that date. There were a total of 7 msgs, with only Craig White replying at that time before it petered out. AIR, the fix was an selinux=0 on the kernel command line, where its been carried forward to this day. I don't recall that this fc-cache error went away with that, only that printing resumed, and still works right now. You'll recall if you have a really good memory, that I also complained at the time and over the ensuing weeks from Nov 9th, about other weird missing files that anaconda should have installed at the time of the install, such as a legit crontab file? I had to create that one by hand once I'd figured it out that it was missing. There were at least 2 other instances of missing stuff that when I commented about them were dismissed as pebkec. And I eventually got tired of being called a liar, so I've since then asked a question or two, but otherwise have stfu about such things. WRT the crontab file, a 'yum whatprovides crontab' says its installed from a noarch rpm. But the file itself was missing. Now I wonder if this could have been an artifact of the filesystem bug they finally found that was trashing torrent downloads unless the torrent was restarted several times until it didn't find any more middle of the file holes to repair? ISTR that condition and bug existed from at least the 2.6.15 kernel to the middle of the rc's for 2.6.19, with the final being held up by Linus for nearly 2 weeks while half the coders on the planet looked for, and finally found it. And a kernel with that bug is on the FC6 dvd's. I probably downloaded that image with a bum kernel since I was also doing my own kernels on the FC2 install I was running last fall. The last kernel I was running there was 2.6.19-rc5. Draw your own conclusions, but the sha1sum of the image was correct, I checked before I burnt it. And after. I guess this is one of the reasons I'll update at some point, maybe even to BLAG or MINT, but probably to Fedora 7, precisely because there is so much raw talent available on this list compared to most of the others. I see questions go unanswered on the kubuntu list that would have been answered here in an hour or so. Generally, that makes a pretty ready supply of bandaids in case this bleeding edge fedora thing actually does bleed, as it is, right here and now with this fc-cache problem that seems to be un-repairable by conventional troubleshooting means. But I'm not giving up just yet, so if anyone has any ideas, I'm all ears. Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Everyone can be taught to sculpt: Michelangelo would have had to be taught how ___not to. So it is with the great programmers.
