Description of problem:I transfered my .bashrc from mga5 (where it had worked for the past year and more) to mga6. When I tried to log in on sddm I got a little error window Cannot start D-Bus. Have you called qdbus? which is of no help whatsoever. After 5 hours of trying to track down the problem, it turned out that I had a PATH= statement in my .bashrc which did not include the previous path, which it turned out to have about 10 extra path elements, one of whic hmust have been crucial for the booting into X. This suggests that there are some programs crucial to the X boot process which are not using full paths, which is a bug in itself. The system should not die if the Path set in .bashrc is not exactly right. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1.Put PATH=~/bin:/usr/local/bin:/usr/bin:/usr/sbin into .bashrc Try to log in from the sddm 2.Fix: use PATH=$PATH:~/bin:/usr/local/bin:/usr/bin:/usr/sbin I simply would not expect that the Path would be so heavily and crucially populated before .bashrc is called-- It never has been in the past.
Logging into Plasma as root from SDDM gives the same error, so that's interesting to hear that it could be a PATH issue.
Assignee: bugsquad => kdeSummary: A long list of elements of PATH are delivered to .bashrc, which if not used crashes X with an idiotic error message => Plasma won't start when logging in from SDDM if PATH is overridden in .bashrcSource RPM: bash? sddm? => (none)
I suspect it is the /usr/lib64/qt{4,5}/bin entries put in by /etc/profile.d/60qt{4,5}.sh What they would have to do with D-bus I have no idea.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19154
Seems to be /usr/lib64/kde4/libexec/kdeeject that is the problem-- the line qdbus org.kde.kdesktop /Desktop refreshIcons That should have an explicit path to qdbus /usr/lib64/qt5/bin/qdbus or /usr/lib64/qt4/bin/qdbus (Not sure which is needed although my PATH has 4 first) Although MGA5 also has this, and it does not seem to suffer the same problem.
if you don't have /usr/lib64/qt4/bin or /usr/lib64/qt5/bin in the path this does not seems a bug for me but "normal". btw there is an issues as root does not have them.
CC: (none) => mageia
Actually it is probable the calls to qdbus in startkde that is the problem. That script should add /lib64/qt5/bin to PATH. to make sure it is there for startkde programs. Note that I do not understand bindir=`echo "$0" | sed -n 's,^\(/.*\)/[^/][^/]*$,\1,p'` if [ -n "$bindir" ]; then qbindir=`qtpaths --binaries-dir` qdbus=$qbindir/qdbus case $PATH in $bindir|$bindir:*|*:$bindir|*:$bindir:*) ;; *) PATH=$bindir:$PATH; export PATH;; esac else qdbus=qdbus fi in startkde. Since qtpath is in the same directory as qdbus, if it cannot find qdbus,it cannot find qtpaths. And besides this does not test if /lib64/qt5/bin is in the path.
Created attachment 8819 [details] Suggested patch for startkde. This patch adds errors if qtpaths or qdbus do not work, and adds I hope more informative error messages.
Note this would also require that qtpaths be in a more accessible place (eg /usr/bin/qtpaths). One would need to put a link to /usr/lib{,64)/qt5/bin/qtpaths as part of the qttools package.
Arch Linux solves the problem by installing all of the qttools into /usr/bin /usr/bin will always be in the PATH of any user. /usr/lib{,64}/qt5/bin will not necessarily be there. But this does not change that startkde as written really makes no sense.
(In reply to w unruh from comment #9) > Arch Linux solves the problem by installing all of the qttools into /usr/bin > /usr/bin will always be in the PATH of any user. Using that logic might not work on Mageia. Looking through /etc/profile.d/*qt* might suggest that an update to qt4 package might overwrite qt5 files in /usr/bin if rpm installs into /usr/bin :( > /usr/lib{,64}/qt5/bin will > not necessarily be there. But this does not change that startkde as written > really makes no sense. It makes sense if you know that applications depend on PATH or environment variables have to be set prior to invocation. Code should not have to defend its self against a screwed up environment. Your patch does not address the problem and in fact makes it more obscure than the current message. The problem is status code return 127 tells you nothing that I know of. I wrote a c program using strerror to convert error number to text and get 127 = Key has expired That is nowhere near the problem of command not found. If you want startkde provide better errors, do not send error to /dev/null and print the error results. If so, you would have received something like bash: qtpaths: command not found
CC: (none) => bittwister2
I do not advise that ALL qt programs be installed in /usr bin, and arch oes not do that AFAIK. Just qttools. Anyway qtpaths is pretty useless if it is installed into the same directory one is looking for by using qtpaths. Even putting in a link in /usr/bin to /lib{64,}/qt5/bin/qtpaths would probably be OK.
(In reply to w unruh from comment #11) > I do not advise that ALL qt programs be installed in /usr bin, and arch oes > not > do that AFAIK. Just qttools. > Anyway qtpaths is pretty useless if it is installed into the same directory > one is looking for by using qtpaths. > Even putting in a link in /usr/bin to /lib{64,}/qt5/bin/qtpaths would > probably be OK. will be done for mga7. we will workaround for mga6
Please test next qttools5
Status: NEW => RESOLVEDResolution: (none) => FIXED
Is it already in the mirrors? The whole logic of startkde needs to be looked at in the section I pointed out. It makes no sense to me.
please open a bugreport upstream for startkde, so it will be used by all distributions.