Description of problem: If you modify the time zone in drakclock, the time is well modify in drakclock but not in the clock of KDE. To get the correct time in the clock of KDE, you have to modify also manually the time zone in the preferences of KDE. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1.Use KDE with an initial time zone. Check the time in the KDE clock 2.Open drakclock and modify your time zone. Check that the time of drakclock is well modify 3.Save the new setting of drakclock and close it. 4.Check that the KDE clock is the same as before the change. 5.Modify the KDE time zone by clicking right on (maybe the translation is not exactly the one that I give) the widget "Digital clock" > Configure "Digital clock" > Time zone. And finally, check the box corresponding to the correct time zone. Reproducible: Steps to Reproduce:
we alter system settings => this is a KDE issue Btw Colin is there a systemd command for that?
CC: (none) => mageia, thierry.vignaudSource RPM: drakclock => kdebase
Yup, there are various systemd calls that can be used now. http://www.freedesktop.org/wiki/Software/systemd/timedated and $ timedatectl --help timedatectl [OPTIONS...] COMMAND ... Query or change system time and date settings. -h --help Show this help --version Show package version --adjust-system-clock Adjust system clock when changing local RTC mode --no-pager Do not pipe output into a pager --no-ask-password Do not prompt for password -H --host=[USER@]HOST Operate on remote host Commands: status Show current time settings set-time TIME Set system time set-timezone ZONE Set system timezone list-timezones Show known timezones set-local-rtc BOOL Control whether RTC is in local time set-ntp BOOL Control whether NTP is enabled So longer term, IMO, we should use the dbus interface in the draktools and (hopefully) deprecated /etc/sysconfig/clock
Hi, thanks for reporting this bug. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it)
Keywords: (none) => TriagedCC: (none) => stormiAssignee: bugsquad => nicolas.lecureuil
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Version: 2 => 3
The "problem" seems to be still present in Mga3 so I changed the version.
CC: (none) => luigiwalser
I just tested it in Mageia 4 and it appears to be hit and miss. I think it did work when I also had NTP checked, and didn't when I didn't.
Colin, could this bug related to the problem we found today? I mean the hard copy of /etc/localtime? If kde relies to systemd it probably gets the same result we had using timedatectl and the cockpit example for that.
CC: (none) => anaselli
kde seems to show correctly the timezone if a link is used instead
Whether it relies directly on systemd-timedated or just replies on reading the symlink itself, it certainly won't rely on the values on /etc/sysconfig/clock, so yeah, I'd say that ensuring drak* stuff stops parsing/relying on/writing ZONE= there, and starts using symlinks (perhaps with a nice transition for a one off upgrade) then things will be better!
A first transition could be on drakclock that could "unlink" old zone setting and "symlink" new one. That should work. If Thierry agrees i could provide an easy patch for that... Of course who is not going to use drakclock, or set the time during the system upgrade will not fix the problem. So a one shot transition procedure should be thought anyway... As a personal note it should not be very hard moving manaclock to systemd dbus access for reading and setting system clock, thing that should simplify polkit stuff. What i have to check and clarify to myself yet is the ntp management.
Also see the update-localtime script in the timezone package, which it runs as a %post. It sets up the copy for /etc/localtime.
That probably is the right place where to do first change :)
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD