Re: morning update, using smart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gene Heskett writes:

In /etc/fonts/conf.avail, a directory created on Nov 9, all the files are 1 Oct dated.

In /etc/fonts.conf.d a directory created on Jan 26, 2007, all the files are much older, with the newest ones being made on Nov 9th 2006.

The rest of the files in /etc/fonts:
-rwxrwxrwx 1 root root  8637 Dec 21  2004 Fontmap
-rwxrwxrwx 1 root root 11489 Jan  5  2005 fonts.conf
-rwxrwxrwx 1 root root  5840 Jan  5  2005 fonts.dtd
-rwxrwxrwx 1 root root  1070 Sep 27  2004 local.conf
are much older than that.

That was me that set all the perms wide open of course.

So, I still have the problem, and so far none of these 'clues' (now there is another oxymoron if ever there was such a thing) do not seem to be meaning much to this particular wannabe Sherlock Holmes.

Help!

At this point, what I would ordinarily do now is fire up gdb, and step through the stupid thing to see exactly what it's doing. But, if you knew how to do this, I'd think you would've done it already, I presume, so that's not going to work. Time to try a different approach.

It looks to me like that there's a corrupted file somewhere that the stupid thing is trying to read, and when it can't make heads or tails of it, it blows up.

Looking at fonts.conf, it looks like that in addition to /var/cache/fontconfig, it also pokes in $HOME/.fontconfig, so if root has this subdirectory, try nuking its contents too, temporarily. I checked, and my box's root account does not have a .fontconfig, but a non-root account does. There's also a /var/gdm/.fontconfig. That's worth exploring.

Then, in addition to /usr/share/fonts, it also looks at the .fonts directory in your home directory. On my box, no account has a .fonts subdirectory.

Finally, in /usr/share/fonts, and in /usr/share/X11/fonts I see a fonts.cache-1 file in every directory and subdirectory.

Try something like "ls -lt `find /usr/share/fonts -name 'fonts.cache*'`" (note the carefully-placed apostrophes and backticks, and repeat for /usr/share/X11/fonts), to identify recently-touched fonts.cache-1 files. See if temporarily nuking the ones with the most recent timestamps will fix it.

The next step is to see if "rpm -V fontconfig" finds a corrupted file in the fontconfig package. Then, you'll need to identify each rpm that install fonts. "rpm -q -a | grep '*fonts*'" would be a good start. Then run rpm -V for each, looking for something that would pop out in front of you.

Finally, I would look for files in /usr/share/fonts, and /usr/share/X11/fonts, that are not claimed by any package. Something like:

cd /usr/share/fonts
find . -type f -print | xargs rpm -q -f | grep 'not owned'

That's rather crude, but it'll work. On my box, besides fonts.cache-1 I also see a bunch of fonts.scale and fonts.dir files, all over the place.

Attachment: pgpIeq3sqQpBv.pgp
Description: PGP signature


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux