> After installing kile GNOME is not able to find the kile icon. The kile entry in
> the Application/Office menu shows no icon.
> This problem can be solved by deleting /usr/share/icons/hicolor/icon-theme.cache
> and executing "gtk-update-icon-cache /usr/share/icons/hicolor". Without the
> deletion gtk-update-icon-cache doesn't update the cache file.
> Version-Release number of selected component (if applicable):
Since I think this has come up a few times occasionally, to me it still
sounds like GNOME brokeness. What kind of icon caching concept is
this? If the cache file gets out-of-date and an icon is not found within
the cache, the desktop system doesn't search the file system? Huh? Or
maybe this is configurable in some place? Why should a KDE application
maintain a GTK icon theme cache file?
Michael Schwendt <mschwendt(a)users.sf.net>
Fedora Core release 4 (Rawhide) - Linux 2.6.13-1.1600_FC5
loadavg: 1.00 1.09 1.37
Type 1 outline OpenType fonts work very well through fontconfig, but it
seems that they do not print. Evolution will just leave the space blank,
Firefox will substitute (seems to pick a generic font - IE my monospace
sans-serif font is substituted with a variable serif font when firefox
AbiWord won't even load the font (apparently intentionally) so that you
don't pick a font you can't print.
Virtually all Adobe fonts are now only available in this format, and
many other foundries are at least headed that direction (though often
makey type1 and/or ttf available as well).
I can use fontforge to change them to a format that does print (though
I'm not sure if the licenses that forbid decompiling would like that) so
its not a huge issue, but I'm curious as to what work (if any) is going
on in the Fedora/Gnome world to bring proper type1 otf printing support
The ttf outline opentype fonts (which seem to have a .ttf extension)
such as Palatino Linotype seem to work just fine. It's only the .otf
fonts that don't print (but look absolutely gorgeous on screen).
Eric Sandeen wrote:
> Jeremy Katz wrote:
>> Yes, but it's a hack that was added at the explicit request of the XFS
>> developers with a "this will fix the problems". And having to
>> constantly change it because they don't want to have the same semantics
>> as all of the other filesystems which are even pseudo-supported is a
>> waste of time.
> Jeremy, I do apologize for the previous workaround which ... didn't work.
> But I have to take issue with the "semantics" you mentioned. Nothing in
> the linux kernel guarantees that the block device address space will be
> coherent with the filesystem address space - so what grub is trying to
> do here (write through the filesystem, read back via the block device
> with fs still mounted) is fundamentally broken.
> ext2 seems less prone to problems, I'm not sure why. But there is no
> guarantee or mechanism in the kernel to make what grub is doing
> bulletproof. (last I looked there were lots of wishful "syncs" in the
> grub code, along with comments that did not inspire confidence!)
So, if as Eric says, the previous workaround doesn't work, can we have
the remount workaround (that works) instead?
On Thu, 2005-10-06 at 17:24 +0100, James Pearson wrote:
> There has been an on going issue with installing grub on an XFS
> partition - anaconda will hang at the installing boot loader stage as
> grub 'spins'.
> The attached patch for 'booty' works round this problem by remounting
> the XFS file system that contains /boot as read-only and then as
> read-write before running the grub install command.
> This patch replaces the current XFS freeze/thaw work round that fails to
> work (a lot) more often than not.
This feels like a hack for the fact that xfs_freeze doesn't work as it
was designed to -- it is specifically for things which need the contents
on disk to actually be what the kernel thinks is there. And the
continued need of random hacks like this make me more and more inclined
to just disallow the use of XFS as a bootable filesystem.
I have rebuilt Mike Harris' experimental modular xorg-x11 RPMs on a
base FC4 system. The following issues surfaced during the build (not
restricted to FC4, they apply to "rawhide" as well):
1. Conflicting files "/usr/include/GL/glx.h" for "mesa-GL-devel"
2. Conflicting files "/usr/include/GL/glu.h" for "mesa-GLU-devel" and
2. Wrong requirement "xorg-x11-server" when the right package name
was "xorg-x11-server-Xorg", applies to "xorg-x11-server-Xvfb" and
"xorg-x11-server-Xnest" spec files
3. drv packages do not build because 'pkg-config xorg-x11-server
--variable=driverdir' and 'pkg-config xorg-x11-server
--variable=inputdir' are nil whereas 'pkg-config xorg-x11-server
--variable=moduledir' yields "/usr/lib/xorg/modules". "moduledir"
and "inputdir" are apparently undefined. A workaround is to set
"driverdir" and "inputdir" in the spec file to "%(moduledir)/drivers"
and "%(moduledir)/input" respectively.
4. xorg-x11-drv-mouse: "/usr/shar/man/man4/mouse.4.gz" conflicts with
file from package "man-pages".
> Upgrading this today broke networking on my machine.
Too late. My loopback activating loops endless....
Sorry, I ask me really how that can be? Its a error where the system do
not more boot here. Do the maintainer(s) not testing this before
uploading their new package to rawhide?