morning update, using smart

[Gene Heskett]

On Sunday 18 March 2007, Michael Schwendt wrote:
>On 18/03/07, Gene Heskett wrote:
>> root at 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 at 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.