| Summary: | Plasma won't start when logging in from SDDM if PATH is overridden in .bashrc | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | w unruh <unruh> |
| Component: | RPM Packages | Assignee: | KDE maintainers <kde> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | bittwister2, mageia |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.mageia.org/show_bug.cgi?id=19154 | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | Suggested patch for startkde. | ||
|
Description
w unruh
2016-12-22 23:43:30 CET
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 =>
kde 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.
David Walser
2016-12-24 02:51:01 CET
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. 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 =>
RESOLVED 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. |