Bug#227538: kdelibs: mixed results on 3.2.2
Chris Cheney writes: On Sat, Jun 26, 2004 at 04:20:12AM +0200, Dominique Devriese wrote: -snip patch- I haven't heard anything about this bug in a while. Does this patch work? I'm pretty sure it fixes the problem, yes. Has been applied to packages that have been released? It's committed in pkg-kde/kdelibs, but apparently it's still not in any uploaded kdelibs version. Chris must have missed this simple patch... Its not committed in the main tree afaict, where is it? Right, I didn't commit it yet, I misinterpreted an empty svn up output.. Guess I'm still too used to the old CVS way :) I will add it to the next upload if it seems to help. I think someone told me before what changing this patch does but it doesn't seem to be in the bug log. Yeah, I seem to remember eplaining it to you once.. The way it currently is seems to work for me, what bug do you see with this exactly? calc-amd64:~# kde-config --path config /root/.kde/share/config/:/etc/kde3/ Well, the problem is that what's currently there happens to work in some cases, but doesn't work in other cases, like the one that the bug report was about. I'll try to explain it again: It's all about the string comparison: If somestring is a variable of type char*, then 'somestring == something' in C++ and C is not a string comparison, but a pointer comparison. It checks that the variable somestring points to the same region of memory that something is put in. Now, the C++ standard leaves some behaviour wrt. string storage undefined, but what g++ does, is that if it finds two string literals containing the same thing, it stores them only once, if the two strings are in the same compile unit or link unit or whatever unit it takes for this. Anyway, what happens in your case ( where it works properly ) is that, the first time that the function is called with something as an argument, it is by chance one of the identical strings in the same compile unit, and the check happens to succeed. The function then caches the result it just calculated, and all further invocations of the function give the correct result. However, if the first invocation of the function happens to be a string from another compile unit, then the pointer comparison fails, the function calculates the wrong result, and this result is cached for all further invocations. I debugged the bug that was described in this bug report, and this is in fact the case. Anyway, I'll be committing the patch now, if you don't mind, with the above explanation in the commit log... cheers domi
Bug#227538: kdelibs: mixed results on 3.2.2
On Sat, Jun 26, 2004 at 03:55:54PM +0200, Dominique Devriese wrote: Well, the problem is that what's currently there happens to work in some cases, but doesn't work in other cases, like the one that the bug report was about. I'll try to explain it again: It's all about the string comparison: If somestring is a variable of type char*, then 'somestring == something' in C++ and C is not a string comparison, but a pointer comparison. It checks that the variable somestring points to the same region of memory that something is put in. Now, the C++ standard leaves some behaviour wrt. string storage undefined, but what g++ does, is that if it finds two string literals containing the same thing, it stores them only once, if the two strings are in the same compile unit or link unit or whatever unit it takes for this. Anyway, what happens in your case ( where it works properly ) is that, the first time that the function is called with something as an argument, it is by chance one of the identical strings in the same compile unit, and the check happens to succeed. The function then caches the result it just calculated, and all further invocations of the function give the correct result. However, if the first invocation of the function happens to be a string from another compile unit, then the pointer comparison fails, the function calculates the wrong result, and this result is cached for all further invocations. I debugged the bug that was described in this bug report, and this is in fact the case. Anyway, I'll be committing the patch now, if you don't mind, with the above explanation in the commit log... I understand now. :) Thanks, Chris signature.asc Description: Digital signature
Bug#227538: kdelibs: mixed results on 3.2.2
=== --- debian/patches/10_kstandarddirs.diff(revision 125) +++ debian/patches/10_kstandarddirs.diff(working copy) @@ -6,7 +6,7 @@ candidates-append(path); } +// UGLY HACK - Chris Cheney -+if (local (config == type)) ++if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); +// local = false; What does that do exactly? It would seem to append /etc/kde3 to all types other than config? Or did I misunderstand what I was doing in that patch? Chris I haven't heard anything about this bug in a while. Does this patch work? Has been applied to packages that have been released? -- Itai Itai Seggev, University of Chicago, Department of Physics Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel) In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes: === --- debian/patches/10_kstandarddirs.diff (revision 125) +++ debian/patches/10_kstandarddirs.diff (working copy) @@ -6,7 +6,7 @@ candidates-append(path); } + // UGLY HACK - Chris Cheney -+ if (local (config == type)) ++ if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); + // local = false; What does that do exactly? It would seem to append /etc/kde3 to all types other than config? Or did I misunderstand what I was doing in that patch? Chris I haven't heard anything about this bug in a while. Does this patch work? I'm pretty sure it fixes the problem, yes. Has been applied to packages that have been released? It's committed in pkg-kde/kdelibs, but apparently it's still not in any uploaded kdelibs version. Chris must have missed this simple patch... cheers domi
Bug#227538: kdelibs: mixed results on 3.2.2
package kdelibs tags 227538 +patch thanks Chris Cheney writes: On Tue, May 04, 2004 at 04:19:00PM -0700, Itai Seggev wrote: The problem bug is a real bug and not a result of upgrading. I a fresh install with the new sarge installer beta 4, and the problem persisted. I also have discovered why this problem manifested in 3.1.4-3. The binary packages search /etc/qt3/ and /usr/share/config for config files. Up to (and including) 3.1.4-2, /usr/share/config was a symlink to /etc/kde3; hence, it could find the config files. In 3.1.4-3, this symlink was removed. This also explains why installing from debian source over the binary package also fixed the problem permanently: the source install installed the config files into /usr/share/config, so any later binary package could find the config files. Thus, there are 3 solutions to this (and presumably other, related) bugs: Domi could you look into this a bit more? I can reproduce the problem now that I used the symlink, which indicates that kthemestyle isn't using the proper config file lookup mechanism, but I am not sure how it does the config file lookup. It sounds like it is hardcoding paths in its lookup instead of using the kde wide functions that are meant to be used! 8( The problem is probably in kthemebase.cpp somewhere. kdelibs/kstyles/kthemestyle/kthemebase.cpp kdelibs/kstyles/utils/installtheme/main.cpp Chris, it's all your fault ;p Ok to commit ? cheers domi Index: debian/patches/10_kstandarddirs.diff === --- debian/patches/10_kstandarddirs.diff(revision 125) +++ debian/patches/10_kstandarddirs.diff(working copy) @@ -6,7 +6,7 @@ candidates-append(path); } +// UGLY HACK - Chris Cheney -+if (local (config == type)) ++if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); +// local = false;
Bug#227538: kdelibs: mixed results on 3.2.2
On Wed, May 05, 2004 at 05:49:31PM +0200, Dominique Devriese wrote: Chris, it's all your fault ;p Ok to commit ? Index: debian/patches/10_kstandarddirs.diff === --- debian/patches/10_kstandarddirs.diff (revision 125) +++ debian/patches/10_kstandarddirs.diff (working copy) @@ -6,7 +6,7 @@ candidates-append(path); } +// UGLY HACK - Chris Cheney -+if (local (config == type)) ++if (local (!strcmp(config, type))) + candidates-append(/etc/kde3/); +// local = false; What does that do exactly? It would seem to append /etc/kde3 to all types other than config? Or did I misunderstand what I was doing in that patch? Chris signature.asc Description: Digital signature
Bug#227538: kdelibs: mixed results on 3.2.2
The problem bug is a real bug and not a result of upgrading. I a fresh install with the new sarge installer beta 4, and the problem persisted. I also have discovered why this problem manifested in 3.1.4-3. The binary packages search /etc/qt3/ and /usr/share/config for config files. Up to (and including) 3.1.4-2, /usr/share/config was a symlink to /etc/kde3; hence, it could find the config files. In 3.1.4-3, this symlink was removed. This also explains why installing from debian source over the binary package also fixed the problem permanently: the source install installed the config files into /usr/share/config, so any later binary package could find the config files. Thus, there are 3 solutions to this (and presumably other, related) bugs: 1) Recompile the packages to add /etc/kde3 to the config file search path. 2) Turn /usr/shar/config back into a symlink to /etc/kde3 3) move all the files in /etc/kde3 to /etc/qt3 or /usr/share/config I don't know how these options interact with the debian policy. Presumably you guys do. :) Let me know what you decide. -- Itai Itai Seggev, University of Chicago, Department of Physics Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel) In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
On Tue, May 04, 2004 at 04:19:00PM -0700, Itai Seggev wrote: The problem bug is a real bug and not a result of upgrading. I a fresh install with the new sarge installer beta 4, and the problem persisted. I also have discovered why this problem manifested in 3.1.4-3. The binary packages search /etc/qt3/ and /usr/share/config for config files. Up to (and including) 3.1.4-2, /usr/share/config was a symlink to /etc/kde3; hence, it could find the config files. In 3.1.4-3, this symlink was removed. This also explains why installing from debian source over the binary package also fixed the problem permanently: the source install installed the config files into /usr/share/config, so any later binary package could find the config files. Thus, there are 3 solutions to this (and presumably other, related) bugs: 1) Recompile the packages to add /etc/kde3 to the config file search path. Its already in the config file search path. I modified the source directly to look in both /etc/kde3 and /usr/local/share/config. I suppose there could be some sort of bug in the code of the thing that is using libkdecore. kde-config --path config /root/.kde/share/config/:/etc/kde3/:/usr/local/share/config/:/usr/share/config/ 2) Turn /usr/share/config back into a symlink to /etc/kde3 This should not be needed for the above reason... 3) move all the files in /etc/kde3 to /etc/qt3 or /usr/share/config This should not be needed either... and is in fact a violation of Debian policy so can't be done. I don't know how these options interact with the debian policy. Presumably you guys do. :) Let me know what you decide. I will try adding the symlink to see if it helps me see the themes. If so then I guess there is a bug somewhere in that something isn't using the paths that kde-config knows about. Thanks, Chris signature.asc Description: Digital signature
Bug#227538: kdelibs: mixed results on 3.2.2
On Tue, May 04, 2004 at 04:19:00PM -0700, Itai Seggev wrote: The problem bug is a real bug and not a result of upgrading. I a fresh install with the new sarge installer beta 4, and the problem persisted. I also have discovered why this problem manifested in 3.1.4-3. The binary packages search /etc/qt3/ and /usr/share/config for config files. Up to (and including) 3.1.4-2, /usr/share/config was a symlink to /etc/kde3; hence, it could find the config files. In 3.1.4-3, this symlink was removed. This also explains why installing from debian source over the binary package also fixed the problem permanently: the source install installed the config files into /usr/share/config, so any later binary package could find the config files. Thus, there are 3 solutions to this (and presumably other, related) bugs: Domi could you look into this a bit more? I can reproduce the problem now that I used the symlink, which indicates that kthemestyle isn't using the proper config file lookup mechanism, but I am not sure how it does the config file lookup. It sounds like it is hardcoding paths in its lookup instead of using the kde wide functions that are meant to be used! 8( The problem is probably in kthemebase.cpp somewhere. kdelibs/kstyles/kthemestyle/kthemebase.cpp kdelibs/kstyles/utils/installtheme/main.cpp Thanks, Chris signature.asc Description: Digital signature
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes:
On Sat, Apr 17, 2004 at 10:52:27PM +0200, Dominique Devriese wrote:
Itai Seggev writes:
OK, so this is the only place in the source where the error
message appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys; bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok); if
( !ok )
qWarning( KThemeStyle cache seems corrupt!\n );
//Too
bad one can't i18n this :-(
return keys;
}
For reference: this code comes from
kdelibs/kstyles/kthemestyle/kthemestyle.cpp.
This code is the same in both debian and pristine sources (which
I guess makes sense, given the recompiling the debian sources
fixes the problem). It's not entirely clear to me how this code
actually ever works, but apparently it does.
Why wouldn't it work ?
I didn't say it wouldn't, I just said I don't understand how it
works. I did locate kthemestyle/themes and got null output, so I
guess that string is some sort of key and not a physical
directory. However, I don't really know the internals of KDE.
What happens there is a QSettings class is created, the current config
resource dirs are added to its search path. Then, QSettings is told
to get the config entry /kthemestyle/themes which it is supposed to
get from a file kthemestylerc in its search path. I can't see why
that fails for you. I'd like to debug this, but I can't since I don't
get the error.
However, I'm no closer to figuring out why I'm getting this
message.
Can you send us the output of the command locate kthemestylerc
and the contents of the file /etc/kde3/kthemestylerc ? Possibly,
152:cavy:/usr/share/apps/kstyle/themes locate kthemestylerc
/etc/kde3/.kthemestylerc.lock /etc/kde3/kthemestylerc
/usr/local/kde/share/config/kthemestylerc
/usr/local/kde/share/config/.kthemestylerc.lock
/usr/local/src/kde/kdelibs/kstyles/themes/kthemestylerc
All three copies of the file are identical:
153:cavy:/usr/share/apps/kstyle/themes cat /etc/kde3/kthemestylerc
[General] themes=marble^eriscos^esystem^esystemalt^e
[marble] file=marble.themerc
[riscos] file=riscos.themerc
[system] file=system.themerc
[systemalt] file=systemalt.themerc
Right. It means you have installed a local version of KDE, right ?
Do you happen to have set KDEDIRS to something or have done other
uncommon things ? Can you check if the problem goes away if you
remove those settings ?
thanks
domi
Bug#227538: kdelibs: mixed results on 3.2.2
On Mon, Apr 19, 2004 at 12:46:38PM -0700, Itai Seggev wrote: On Mon, Apr 19, 2004 at 01:24:29PM +0200, Dominique Devriese wrote: The reason System, along with Marble, System-Alt, and RiscOS went missing is that KDE is failing to to find the config files. I've attached and strace of open and closing kedit on both the work and non-working machines. On the non-working machine (i.e., the one with the binary debian packages of 3.2.2-1 installed), the relevant lines are 117:gr-visitor:/home/iseggev grep kthemestylerc kedit_strace_broken access(/etc/qt3/kthemestylerc, F_OK) = -1 ENOENT (No such file or directory) access(/home/iseggev/.kde/share/config//kthemestylerc, F_OK) = -1 ENOENT (No such file or directory) access(/home/iseggev/.qt/kthemestylerc, F_OK) = -1 ENOENT (No such file or directory) After failing to find the config file or any approriate library of the System style, it prints out the error message KThemeStyle cache seems corrupt. On the working machine (i.e., the one in which I have the Copying /etc/kde3/kthemestylerc to /etc/qt3/kthemestylerc does indeed fix the problem, so at least now there is a work around which doesn't involve recompilation. :) This does seem, though, like a problem which should be fixed. -- Itai Itai Seggev, University of Chicago, Department of Physics Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel) In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
On Sat, Apr 17, 2004 at 10:52:27PM +0200, Dominique Devriese wrote:
Itai Seggev writes:
OK, so this is the only place in the source where the error message
appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys; bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok); if (
!ok )
qWarning( KThemeStyle cache seems corrupt!\n ); //Too
bad one can't i18n this :-(
return keys;
}
For reference: this code comes from
kdelibs/kstyles/kthemestyle/kthemestyle.cpp.
This code is the same in both debian and pristine sources (which I
guess makes sense, given the recompiling the debian sources fixes
the problem). It's not entirely clear to me how this code actually
ever works, but apparently it does.
Why wouldn't it work ?
I didn't say it wouldn't, I just said I don't understand how it
works. I did locate kthemestyle/themes and got null output, so I
guess that string is some sort of key and not a physical
directory. However, I don't really know the internals of KDE.
However, I'm no closer to figuring out why I'm getting this
message.
Can you send us the output of the command locate kthemestylerc and
the contents of the file /etc/kde3/kthemestylerc ? Possibly,
152:cavy:/usr/share/apps/kstyle/themes locate kthemestylerc
/etc/kde3/.kthemestylerc.lock
/etc/kde3/kthemestylerc
/usr/local/kde/share/config/kthemestylerc
/usr/local/kde/share/config/.kthemestylerc.lock
/usr/local/src/kde/kdelibs/kstyles/themes/kthemestylerc
All three copies of the file are identical:
153:cavy:/usr/share/apps/kstyle/themes cat /etc/kde3/kthemestylerc
[General]
themes=marble^eriscos^esystem^esystemalt^e
[marble]
file=marble.themerc
[riscos]
file=riscos.themerc
[system]
file=system.themerc
[systemalt]
file=systemalt.themerc
--
Itai
Itai Seggev, University of Chicago, Department of Physics
Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel)
In 1997 a group of programmers started writing a desktop environment
to fix a travesty they didn't create. Their program promptly found
its way onto un*x systems everywhere. Today, still opposed by a
software monopolist, they survive as soldiers of fortune. If you share
their vision, if you know you can help, and if you can connect to
internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
On Fri, Apr 16, 2004 at 06:20:17PM -0500, Chris Cheney wrote: On the system that it works I bet you have some old libraries laying around somewhere. As far as I can tell the problem is that basicstyle was removed long ago and so the themes that are missing shouldn't exist at all. Can you check your system to see if the file basicstyle.la exists on it somewhere? Neither machine has basicstyle.la anywhere on it. Also, don't forget that the machine on which it works, it didn't work until I compiled the debian sources and installed them over the binary packaged. I'm not sure why you claim the styles should exist at all. Certainly, when I've compiled from pristince sources (and I have a user whose KDEDIRS and other variables are set up to use the result), those styles have all been present. -- Itai Itai Seggev, University of Chicago, Department of Physics Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel) In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
OK, so this is the only place in the source where the error message
appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys;
bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok);
if ( !ok )
qWarning( KThemeStyle cache seems corrupt!\n ); //Too
bad one can
't i18n this :-(
return keys;
}
This code is the same in both debian and pristine sources (which I
guess makes sense, given the recompiling the debian sources fixes the
problem). It's not entirely clear to me how this code actually ever
works, but apparently it does. However, I'm no closer to figuring out
why I'm getting this message. (Perhaps this is only the result of an
upgrade? If I get the chance, I'll try install the pacakges on a
pristine partition and see what happens).
--
Itai
Itai Seggev, University of Chicago, Department of Physics
Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel)
In 1997 a group of programmers started writing a desktop environment
to fix a travesty they didn't create. Their program promptly found
its way onto un*x systems everywhere. Today, still opposed by a
software monopolist, they survive as soldiers of fortune. If you share
their vision, if you know you can help, and if you can connect to
internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
Itai Seggev writes:
OK, so this is the only place in the source where the error message
appears:
QStringList keys() const
{
QSettings cfg;
KStyleDirs::dirs()-addToSearch( config, cfg );
QStringList keys; bool ok;
keys = cfg.readListEntry( /kthemestyle/themes, ok); if (
!ok )
qWarning( KThemeStyle cache seems corrupt!\n ); //Too
bad one can't i18n this :-(
return keys;
}
For reference: this code comes from
kdelibs/kstyles/kthemestyle/kthemestyle.cpp.
This code is the same in both debian and pristine sources (which I
guess makes sense, given the recompiling the debian sources fixes
the problem). It's not entirely clear to me how this code actually
ever works, but apparently it does.
Why wouldn't it work ?
However, I'm no closer to figuring out why I'm getting this
message.
Can you send us the output of the command locate kthemestylerc and
the contents of the file /etc/kde3/kthemestylerc ? Possibly,
something strange has happened to that file, or you have a file by
that name from some other location.
(Perhaps this is only the result of an upgrade? If I get
the chance, I'll try install the pacakges on a pristine partition
and see what happens).
k
thanks
domi
Bug#227538: kdelibs: mixed results on 3.2.2
OK, so I upgraded the machine on which I had installed the debian sources over the binary package from 3.2.1-1 to 3.2.2-1. The bug did not reappear. Buoyed by this result, I upgraded my other machine, which had been held back to 3.1.4-2 (the last version in the bug was not observed), to 3.2.2-1, but it does suffer from the bug! I'm also getting an error message KThemestyle cache seems corrupt each time I start a K app. Thoughts? -- Itai Itai Seggev, University of Chicago, Department of Physics Co-coordinator, Carmel Project (http://linbrew.sourceforge.net/carmel) In 1997 a group of programmers started writing a desktop environment to fix a travesty they didn't create. Their program promptly found its way onto un*x systems everywhere. Today, still opposed by a software monopolist, they survive as soldiers of fortune. If you share their vision, if you know you can help, and if you can connect to internet, maybe you can join... the K-Team.
Bug#227538: kdelibs: mixed results on 3.2.2
On Fri, Apr 16, 2004 at 02:55:30PM -0700, Itai Seggev wrote: OK, so I upgraded the machine on which I had installed the debian sources over the binary package from 3.2.1-1 to 3.2.2-1. The bug did not reappear. Buoyed by this result, I upgraded my other machine, which had been held back to 3.1.4-2 (the last version in the bug was not observed), to 3.2.2-1, but it does suffer from the bug! I'm also getting an error message KThemestyle cache seems corrupt each time I start a K app. On the system that it works I bet you have some old libraries laying around somewhere. As far as I can tell the problem is that basicstyle was removed long ago and so the themes that are missing shouldn't exist at all. Can you check your system to see if the file basicstyle.la exists on it somewhere? Thanks, Chris signature.asc Description: Digital signature
