reassign 296029 libgtk2.0-bin severity 296029 serious tags 296029 = confirmed upstream thank you, wonderful Debian BTS!
Hi,
Michal Politowski <[EMAIL PROTECTED]> writes:
> On Sun, 20 Feb 2005 02:46:11 +0100, Marc 'HE' Brockschmidt wrote:
> [...]
>> OK, something i just noticed: Could you run "gtk-update-icon-cache
>> /usr/share/icons/hicolor/" and try again?
> You hit it. After this perlpanel starts up all right.
> It means it just has to update caches for all the themes it ships in
> postinst, doesn't it?
OK, I've looked at the C code, it's a bug in the icon cache code. I'm
reassigning the bug to libgtk2.0-bin now...
Let's see what happens here:
* Since Gtk 2.6.0, the IconCache exists
* New theme packages call gtk-update-icon-cache in their postinst
* A new package is installed and drops icons in /usr/share/icons/$foo
* It can't find its icons
The reason for that is the flawed logic of the IconCache code... To
prevent the use of old caches that don't reflect what's actually on the
disk, the code checks some timestamps:
cache_filename = g_build_filename (path, "icon-theme.cache", NULL);
[...]
if (g_stat (path, &path_st) < 0)
goto done;
/* Open the file and map it into memory */
fd = g_open (cache_filename, O_RDONLY|_O_BINARY, 0);
[...]
if (fstat (fd, &st) < 0 || st.st_size < 4)
goto done;
/* Verify cache is uptodate */
if (st.st_mtime < path_st.st_mtime)
{
GTK_NOTE (ICONTHEME,
g_print ("cache outdated\n"));
goto done;
}
path is something like "/usr/share/icons/hicolor/". This means that the
code checks if the mtime of $PATH/icon-theme.cache is newer than
$PATH. The mtime for a directory changes whenever something in this
directory is changed. The problem is that mtime stays the same if
something in a *subdir* is changed, which is the case here (as all icons
go to $PATH/$SIZE/$SECTION/).
Look at this little snippet to verify it:
mkdir -p foo/bar; sleep 5; touch foo/bar/baz;
perl -e 'for (qw(foo foo/bar foo/bar/baz)) { printf "\%-12s \%d\n", $_,
(stat($_))[9]}'
The fix would be to check that the icon-theme.cache file's mstamp is
higher than the mstamps of all subdirs of $PATH. My C skills are a bit
rusty, so i can't provide a patch now, but it should be pretty easy to
do.
And someone should probably forward this upstream, I don't have a
bugzilla account.
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,"u"(kcapnu ,""nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa&{gwmclBHIbus}gwmclBHI&{yVGa09mbbus}yVGa09mb&{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # <mailto:[EMAIL PROTECTED]>
pgpI7GZyOlZPq.pgp
Description: PGP signature
