Well, the title says it all. I’m running Tumbleweed, and for some odd reason, the only timezone KDE can see is UTC. Oddly, I can see all the timezones in YaST, but that doesn’t really help me set my desktop clock. Anyone have any idea why that would be?
Hi and welcome to the forum 
Unfortunately you have posted in the wrong area for ‘Tumbleweed’, will close temporarily and move to the Tumbleweed subforum. For our nntp users please hold off replying until the thread is moved.
Hi
Thread moved and opened for consumption.
Unfortunately, this isn’t completely clear.
For the record, I’m using Plasma 5 with Tumbleweed, but KDE with opensuse 13.2. I do recall having timezone problems once with KDE.
If you go into digital clock settings (with right click on the time in tray), then select “Time Zones”, do you see a list of all timezones?
I do see the list, and only UTC is checked there. At one time, the clock only showed UTC, though it usually shows both UTC and local. In that “Time Zones” screen, near the bottom, there’s a setting for “Clock defaults to local”.
As I recall, when I had a problem, I changed that “Clock defaults to local” to “Clock defaults to UTC”. And then I changed it back. And I have not had any problems since then.
However, I’m not sure if this is the problem you are having.
The list under timezones in the digital clock settings contains only one option, UTC. And no matter which choice it’s set to (Default to UTC or Default to Local), the clock only shows time for the UTC timezone. The same thing is the case if I try to change the time under System Settings; the only timezone in the timezone list is UTC.
I’m not sure where it gets that list, so I’ll guess.
Can you see the files in “/usr/share/zoneinfo” (and its subdirectories). Do those files look readable by you?
I’m guessing that maybe permissions got messed up.
Yes, they’re all there and globally readable.
I have one Tumbleweed installation that is still on KDE (rather than Plasma 5), though I rarely use it. I’ll login and update tomorrow, and see if I have problems there.
Your title says KDE 4.12. As far as I know, it should be KDE 4.14.6 (or maybe 4.14.7) on Tumbleweed. Was that a typo, or do you have something messed up in your repos and/or updating?
Sorry, I thought the latest KDE was 4.12 for some reason. I’m on 4.14.7, the latest version in the regular repository. I’ve tried Plasma 5, but for some reason it’s really unstable on my system (probably because I have a crappy integrated Nvidia video card).
FYI - Using Tumbleweed with KDE Platform Version 4.14.7 and Digital Clock V1.0 - I have the drop down time zone list present and am able to select different zones.
Can you reproduce this on a fresh user account?
What’s the content of ~/.kde4/share/config/ktimezonedrc ?
Is the TimeZone service activated in “Configure Desktop”->“Startup and Shutdown”->Service Management? Is it running?
PS: the above applies for the KDE4 desktop. If you’re using Plasma5, it would be ~/.config/ktimezonedrc, and you would have to check the service in systemsettings5 (“Systemsettings” in the menu) in this case…
I didn’t know if this had anything to do with the problem, but KDED crashes on desktop start every session. It appears that this may be the source of the problem.
I did that update, and am not seeing a problem. I did reboot after the update before checking.
After extensively polling my logs for error messages related to KDED not starting, it appears the ultimate source of this problem is, for some odd reason, KDE can’t connect to DBUS. It’s definitely starting (I’d likely have major trouble getting the system to run if systemd tried to run without it), but KDE can’t seem to find it.
If KDE wouldn’t find DBUS, it wouldn’t even start I think. And you’d definitely would have more severe problems than missing timezones.
Why do you think that KDE can’t connect to DBUS?
Is it because of lines like this in /var/log/kdm.log?
klauncher(1694) kdemain: No DBUS session-bus found. Check if you have started the DBUS server.
kdeinit4: Communication error with launcher. Exiting!
kdmgreet(1630)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: "Not connected to D-Bus server"
That’s “normal”, and those messages actually come from KDM, not the KDE session.
Again, does kded start if you disable all services? Or does it still crash?
I’m just going to go back to 13.2. It seems to work more consistently on my system for some reason. I don’t know why, but I always seem to have problems with Tumbleweed on it.
I can’t believe this…
openSUSE 13.2 is showing the same behavior with KDED than openSUSE Tumbleweed was…
I don’t know what is going on, but every attempt to start KDED leads to it aborting…
Edit: The good news it, I finally managed to get an error trace for whatever is going on!
KCrash: Attempting to start /usr/bin/kded4 from kdeinit
KCrash: Connect sock_file=(Home)/.kde4/socket-cherrl.cherrlnet.com/kdeinit4__0
KCrash: Application ‘kded4’ crashing…
KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit
KCrash: Connect sock_file=(Home)/.kde4/socket-cherrl.cherrlnet.com/kdeinit4__0
kded(2673): Communication problem with “kded” , it probably crashed.
Error message was: “org.freedesktop.DBus.Error.NoReply” : " “Message did not receive a reply (timeout by message bus)” "
Also, the stacktrace for this is really odd. It’s SegFaulting, but before that it jumps from Qt4Core to the loader to Qt5Gui, and I don’t understand why the system would try to load Qt5 for a KDE4 program. Is the loader getting confused here?
Yes, if an application loads both Qt4 and Qt5, it will crash.
Why don’t you post the stack trace?
That would probably tell what is loading Qt5.
Is the loader getting confused here?
I don’t think so. But some kded plugin seems to be built against Qt5 or loads it indirectly by using something else that’s compiled against Qt5.
One guess: phonon-backend-vlc
VLC is built against Qt5 since a few days (it uses Qt for its GUI). If you use phonon-backend-vlc in KDE4 and the qt plugin is not in the plugin cache, VLC will load it on startup and cause a crash whenever any KDE4 application will use Phonon for playing a notification sound e.g. (the same problem existed with Plasma5 until recently, because VLC was Qt4 based)
Workaround: build a complete VLC plugin cache with:
sudo /usr/lib/vlc/vlc-cache-gen -f /usr/lib/vlc/plugins
or for 64bit:
sudo /usr/lib64/vlc/vlc-cache-gen -f /usr/lib64/vlc/plugins
Or switch to phonon-backend-gstreamer, either in KDE’s Multimedia settings or by just uninstalling phonon-backend-vlc.
If that’s really the reason, I’d like to ask where you installed VLC from. The latest openSUSE packages should actually create the cache after installation.
Actually, I haven’t installed phonon-backend-vlc yet.
Here’s the stacktrace:
Application: KDE Daemon (kded4), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[KCrash Handler]
#5 0x00007f2cca9cd9bc in __strcmp_sse2 () at /lib64/libc.so.6
#6 0x00007f2cb8546a9e in QMetaType::registerNormalizedType(QByteArray const&, void (*)(void*), void* (*)(void const*), void (*)(void*), void* (*)(void*, void const*), int, QFlags<QMetaType::TypeFlag>, QMetaObject const*) () at /usr/lib64/libQt5Core.so.5
#7 0x00007f2cb5f82077 in () at /usr/lib64/libQt5Gui.so.5
#8 0x00007f2ccaf1592a in call_init.part () at /lib64/ld-linux-x86-64.so.2
#9 0x00007f2ccaf15a13 in _dl_init_internal () at /lib64/ld-linux-x86-64.so.2
#10 0x00007f2ccaf19b48 in dl_open_worker () at /lib64/ld-linux-x86-64.so.2
#11 0x00007f2ccaf157e4 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2
#12 0x00007f2ccaf1933b in _dl_open () at /lib64/ld-linux-x86-64.so.2
#13 0x00007f2cc7f9902b in dlopen_doit () at /lib64/libdl.so.2
#14 0x00007f2ccaf157e4 in _dl_catch_error () at /lib64/ld-linux-x86-64.so.2
#15 0x00007f2cc7f995dd in _dlerror_run () at /lib64/libdl.so.2
#16 0x00007f2cc7f990c1 in dlopen@@GLIBC_2.2.5 () at /lib64/libdl.so.2
#17 0x00007f2cc94f9518 in () at /usr/lib64/libQtCore.so.4
#18 0x00007f2cc94f449a in () at /usr/lib64/libQtCore.so.4
#19 0x00007f2cc94f4aa3 in () at /usr/lib64/libQtCore.so.4
#20 0x00007f2cc9cf51a8 in KPluginLoader::load() () at /usr/lib64/libkdecore.so.5
#21 0x00007f2cc9cf5448 in KPluginLoader::factory() () at /usr/lib64/libkdecore.so.5
#22 0x00007f2ccacfe304 in () at /usr/lib64/libkdeinit4_kded4.so
#23 0x00007f2ccacfeb89 in () at /usr/lib64/libkdeinit4_kded4.so
#24 0x00007f2ccacff348 in () at /usr/lib64/libkdeinit4_kded4.so
#25 0x00007f2ccacff3b3 in () at /usr/lib64/libkdeinit4_kded4.so
#26 0x00007f2ccad0186d in () at /usr/lib64/libkdeinit4_kded4.so
#27 0x00007f2cca1f1f0a in () at /usr/lib64/libkdeui.so.5
#28 0x00007f2cca1f1f85 in () at /usr/lib64/libkdeui.so.5
#29 0x00007f2cca1f2193 in () at /usr/lib64/libkdeui.so.5
#30 0x00007f2cc9895d4d in () at /usr/lib64/libQtDBus.so.4
#31 0x00007f2cc9896ed9 in () at /usr/lib64/libQtDBus.so.4
#32 0x00007f2cc98979bd in () at /usr/lib64/libQtDBus.so.4
#33 0x00007f2cc9897a8b in () at /usr/lib64/libQtDBus.so.4
#34 0x00007f2cc952059e in QObject::event(QEvent*) () at /usr/lib64/libQtCore.so.4
#35 0x00007f2cc88a6733 in QApplication::event(QEvent*) () at /usr/lib64/libQtGui.so.4
#36 0x00007f2cc88a176c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4
#37 0x00007f2cc88a7cad in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQtGui.so.4
#38 0x00007f2cca1eacea in KApplication::notify(QObject*, QEvent*) () at /usr/lib64/libkdeui.so.5
#39 0x00007f2cc95082ad in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQtCore.so.4
#40 0x00007f2cc950b57d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQtCore.so.4
#41 0x00007f2cc95358fe in () at /usr/lib64/libQtCore.so.4
#42 0x00007f2cc53c4a04 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#43 0x00007f2cc53c4c48 in () at /usr/lib64/libglib-2.0.so.0
#44 0x00007f2cc53c4cec in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#45 0x00007f2cc95350be in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#46 0x00007f2cc893e676 in () at /usr/lib64/libQtGui.so.4
#47 0x00007f2cc9506e6f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#48 0x00007f2cc9507165 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQtCore.so.4
#49 0x00007f2cc950c5b9 in QCoreApplication::exec() () at /usr/lib64/libQtCore.so.4
#50 0x00007f2ccad0032b in kdemain () at /usr/lib64/libkdeinit4_kded4.so
#51 0x00007f2cca96fb05 in __libc_start_main () at /lib64/libc.so.6
#52 0x000000000040075e in _start ()
Ok, that was just an idea, and the first that sprang to mind. Actually I can’t think of any other thing that could pull in Qt5 into kded4 on a 13.2 installation…
Here’s the stacktrace:
Unfortunately this doesn’t tell much either.
It just confirms that some kded plugin is loading Qt5.
It might help if you installed the libqt4-debuginfo, kdelibs4-debuginfo, and libkdecore4-debuginfo packages (enable the debug and debug update repos for that).
But maybe better would be to run “kdebugdialog” and turn on all debug output. Then run kded4 in a terminal window and post the last lines. It should print which plugins it is trying to load, so this should show the one that’s causing the crash.
Other thoughts:
Have you tried a fresh user account or disabling all services in KDE4’s settings?
Maybe post a list of all kded plugins installed, and from which packages they come from:
ls /usr/share/kde4/services/kded/
rpm -qf /usr/share/kde4/services/kded*
Does kded start on login if you rename the folder /usr/share/kde4/services/kded/ and run “kbuildsycoca4 --noincremental”?