I am trying to open links in Konversation 1.6, the first KF5-based application I will use. Within KRun::KRunPrivate::init, d->m_externalBrowser is empty despite KDE 4 being configured to use an external browser (Chromium). But that's not the main bug: More problematically, it goes on all the way to KRun::scanFile and from there proceeds to KIO. End result is an immediate "Host not found" dialog for any link. #0 KRun::scanFile (this=0x8bfbe08) at /var/tmp/portage/kde-frameworks/kio-5.21.0/work/kio-5.21.0/src/widgets/krun.cpp:1083 #1 0x487ee3ec in KRun::init (this=0x8bfbe08) at /var/tmp/portage/kde-frameworks/kio-5.21.0/work/kio-5.21.0/src/widgets/krun.cpp:950 #2 0x487ef3ec in KRun::slotTimeout (this=0x8bfbe08) at /var/tmp/portage/kde-frameworks/kio-5.21.0/work/kio-5.21.0/src/widgets/krun.cpp:1101 Qt 5 applications have no problem opening links. Reproducible: Always
I hacked Konversation to use QDesktopServices instead of KRun, and it works great (even the filetype-based program selection works; eg, Gwenview for images). Maybe KDE should be using QDesktopServices for KRun, and hooking it on the other side when KDE 5 is the desktop environment?
But why does KIO5 say "host not found"? Could it be that no kioslave is found because the env vars are not correct? KRun can't use QDesktopServices, given that KRun has 1000 times more features.
More precisely, you need XDG_DATA_DIRS to point to the KF5 install prefix. If this doesn't fix the issue, please provide stderr output from konversation.
$ echo $XDG_DATA_DIRS /usr/share:/usr/local/share:/usr/share Package installs /usr/lib/qt5/plugins/kf5/kio/http.so
Does QT_PLUGIN_PATH include /usr/lib/qt5/plugins? Or `qmake -query | grep PLUGINS` (with the qt5 qmake)? I wonder though, because "host not found" is not "protocol not found". Could it be that you use a proxy, and it's not configured for KF5? Does `kioclient5 cat ~/.bashrc` work? What about `kioclient5 cat http://www.kde.org` ?
$ echo $QT_PLUGIN_PATH /usr/lib/kde4/plugins:/home/luke-jr/.kde4/lib/kde4/plugins/:/usr/lib/kde4/plugins/ $ QT_SELECT=5 qmake -query | grep PLUGINS QT_INSTALL_PLUGINS:/usr/lib/qt5/plugins $ kioclient5 cat ~/.bashrc bash: kioclient5: command not found $ kioclient --version # which is installed by kde-apps/kioclient-15.12.3 Qt: 4.8.6 KDE Development Platform: 4.14.16 KIO Client: 2.0 kioclient works with both the local URI and kde.org
Built kioclient5 from git. ~/.bashrc works with the warnings about XDG_RUNTIME_DIR, while kde.org gets: $ kioclient/kioclient5 cat http://www.kde.org QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-luke-jr' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-luke-jr' "Unknown host www.kde.org: Host not found" I wonder if the XDG_RUNTIME_DIR thing is related? I see it's specified in a freedesktop.org standard in 2010, but I can't seem to figure out what's supposed to set it on a normal (ie, non-systemd) system. (I'm fine with the default /tmp/runtime-luke-jr, if that's not a problem...)
killall kdeinit5 seems to have fixed it for now...
I think I have a related issue with version 5.38.0, Fedora 26; $ kioclient5 cat http://www.kde.org "Unknown host www.kde.org: Host not found" $ host www.kde.org www.kde.org is an alias for olios.kde.org. olios.kde.org has address 91.189.93.5 I logged in weeks ago but faced this issue only yesterday.
The host lookup is done by a kioslave forked from kdeinit, so this might be very well related to the glibc bug I've been experiencing for 4 years and debugging for 2 weeks now. I'll test this command next time the issue happens.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!