Line 22 of startkde reads: qbindir=`$bindir/kde4-config --qt-binaries` Since the introduction of qtchooser, Qt binaries are not in /usr/bin anymore, as Qt4 and Qt5 need to be coinstalled. In Debian, as an example, it's in /usr/lib/x86_64-linux-gnu/qt4/bin So path becomes: /usr/lib/x86_64-linux-gnu/qt4/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Thus qtchooser is being skipped. Reproducible: Always Actual Results: Qtchooser is being skipped.
Note that this problem is not at all Debian-specific. Every distribution supporting qt4 and qt5 will have to put the Qt binaries somewhere outside /usr/bin, and put the qtchooser binaries in /usr/bin so that qtchooser can figure out which version of Qt to use. No matter how distributions decide to handle this, the current version of startkde will break their setup and circumvent qtchooser by adding the folders with the Qt4-specific binaries to PATH. Why is the Qt binary path added to PATH in the first place? Is anything in there a run-time dependency of KDE? I thought these were development tools only, and why should KDE force the user to do Qt development only with the version of Qt the currently running session was compiled with?
Just hit this myself
Unfortunately, this is more complicated than I thought: I was about to suggest to just remove the lines from startkde which add the Qt path to the PATH. However, if I do that, logging in to a KDE session fails, complaining about missing/failing qdbus. qdbus fails saying qdbus: could not find a Qt installation of '' Probably, that is because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710773 . After adding a symlink from $HOME/.config/qtchooser/default.conf to /usr/share/qtchooser/qt4-x86_64-linux-gnu.conf, my KDE session works again. Now of course I could change startkde to use the qdbus inside the path given by Qt, but it may very well me that other parts of KDE rely on qdbus being in the PATH. In this case, what would happen if qtchooser uses another qdbus than the one of the Qt version KDE was compiled with? Do they all have the same interface? As the issue I had shows, this makes qtchooser a *very* critical tool, a misconfiguration here will break all KDE sessions.
(In reply to comment #3) [snip] > qdbus: could not find a Qt installation of '' > > Probably, that is because of > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710773 . After adding a > symlink from $HOME/.config/qtchooser/default.conf to > /usr/share/qtchooser/qt4-x86_64-linux-gnu.conf, my KDE session works again. That's because of that, most probably. In Debian we default to qt4 when no option is given, but you have modified your system. > Now of course I could change startkde to use the qdbus inside the path given > by Qt, but it may very well me that other parts of KDE rely on qdbus being > in the PATH. In this case, what would happen if qtchooser uses another qdbus > than the one of the Qt version KDE was compiled with? Do they all have the > same interface? IIRC, upstream never promised so (I could check the mail archives), but so far should work. And yes, it's a problem :-/ > As the issue I had shows, this makes qtchooser a *very* > critical tool, a misconfiguration here will break all KDE sessions. Yes :-/
(In reply to comment #4) > That's because of that, most probably. In Debian we default to qt4 when no > option is given, but you have modified your system. By "modify" you mean "set XDG_CONFIG_DIRS"? That's true, setting this environment variable is needed to get a properly working KDE session running outside /usr. As soon as qtchooser is fixed in that regard (my offer to help still stands, of course), this is gone. I just mentioned this problem to illustrate the issues which could be caused by the proposed change to startkde. > IIRC, upstream never promised so (I could check the mail archives), but so far should work. And yes, it's a problem :-/ There's still the possibility that startkde just uses qdbus to check whether dbus actually runs. Bit it will be very hard to find out... Albert, do you know whom to ask about this? Should I just make a review request with uses $(kde4-config --qt-binaries)/qdbus, and add kde-workspace and kdelibs (hoping these groups exist in reviewboard)?
Can you guys give a try to http://lists.kde.org/?l=kde-core-devel&m=137157602931331&q=p3
Sure, i'll test it ASAP.
I've applied the patch and here I am. Everything seems to work normally. I have so far not setted XDG_CONFIG_DIRS. Ralf: is there anything else I can do to test? Or can you test it with your setup?
The patch is working here, even with a broken qtchooser. Some remarks: - There were hunks when applying the patch, even though I used current upstream as basis. Why that? - IMHO the stderr from calling qdbus should not be sent to /dev/null. Normally there should be no output there, right? So this is useful for diagnosis. - Why do you use the qbindir only if startkde was started with an absolute path? I see no reason for this correlation.
(In reply to comment #9) > The patch is working here, even with a broken qtchooser. > > Some remarks: > - There were hunks when applying the patch, even though I used current > upstream as basis. Why that? My patch is against my installed startkde of 4.10.4 so that may be it > - IMHO the stderr from calling qdbus should not be sent to /dev/null. > Normally there should be no output there, right? So this is useful for > diagnosis. Nothing to do with this bug, you may be right, but that's not what i'm trying to fix > - Why do you use the qbindir only if startkde was started with an absolute > path? I see no reason for this correlation. No clue, but that is what the old code did, so i'm doing the same
I just thought, while we are at it, we can clean up the use of qdbus in there a bit more ;-) But, if you want to keep the patch minimal, I'm fine with what you got right now.
I've pushed the patch and i'll be in 4.10.90
Great, thanks a lot :)