Description of problem: Attempting to set the timezone from System Settings widget in KDE gives an error message. Version-Release number of selected component (if applicable): kde-settings-4.9-16.fc18.1.noarch How reproducible: 100% Steps to Reproduce: 1.Visit System Settings->System Administration->Date & Time 2.Click on the Time Zone tab 3.Select a timezone different from the default (UTC in my case) and hit Apply. Actual results: Popup error saying "Error setting new time zone." Expected results: Changed system time zone. Additional info: Same applies when right-clicking on the calendar panel widget and selecting Adjust Date & Time. Problem is independent of SELinux settings. It's noticeable that no authentication password is requested after hitting Apply.
/usr/share/polkit-1/rules.d/11-fedora-kde-policy.rule // kde-settings authorizations/policy for the wheel group. // // DO NOT EDIT THIS FILE, it will be overwritten on update. // // Allow users in the wheel group to do set the clock in kcm_clock without being // interrupted by a password dialog polkit.addRule(function(action, subject) { if (action.id == "org.kde.kcontrol.kcmclock.save" && subject.isInGroup("wheel") && subject.active) { return polkit.Result.YES; } }); in short, means admin/wheel users aren't prompted for root auth. Now, why it's not working is indeed a bug, probably time (pun!) to adapt to using systemd method(s) for setting timezone at least.
(In reply to comment #1) > /usr/share/polkit-1/rules.d/11-fedora-kde-policy.rule > > // kde-settings authorizations/policy for the wheel group. > // > // DO NOT EDIT THIS FILE, it will be overwritten on update. > // > // Allow users in the wheel group to do set the clock in kcm_clock without > being > // interrupted by a password dialog > > polkit.addRule(function(action, subject) { > if (action.id == "org.kde.kcontrol.kcmclock.save" && > subject.isInGroup("wheel") && subject.active) { > return polkit.Result.YES; > } > }); > > in short, means admin/wheel users aren't prompted for root auth. OK, I am in the wheel group so that part is fine. > Now, why it's not working is indeed a bug, probably time (pun!) to adapt to > using systemd method(s) for setting timezone at least. Could be. I'm surprised no-one has reported this before now but I guess changing the timezone after installation isn't a common operation.
The offending code is here: https://projects.kde.org/projects/kde/kde-workspace/repository/entry/kcontrol/dateandtime/helper.cpp?rev=KDE%2F4.9#L173 So this tries invoking "zic" if it's found, otherwise it tries deleting "/etc/localtime" and copying "/usr/share/zoneinfo/" + selected_zone to "/etc/localtime". An error can only be flagged if zic doesn't exist and the operation on /etc/localtime fails, there's no error checking at all in the zic case. glibc-common ships /usr/sbin/zic: http://koji.fedoraproject.org/koji/rpminfo?rpmID=3568832 so why would that not be found?
Can anybody else reproduce this? If so, I wonder whether changing "zic" to "/usr/sbin/zic" (i.e. hardcoding the path) would fix it.
By the way, hwclock is also in /usr/sbin, so invoking hwclock likely also fails if invoking zic fails, which unfortunately does not report an error, but fail silently. :-( (That would explain why people have been reporting lately that the hardware clock isn't getting updated anymore yet again, grrr…)
(In reply to comment #3) > The offending code is here: > https://projects.kde.org/projects/kde/kde-workspace/repository/entry/ > kcontrol/dateandtime/helper.cpp?rev=KDE%2F4.9#L173 > > So this tries invoking "zic" if it's found, otherwise it tries deleting > "/etc/localtime" and copying "/usr/share/zoneinfo/" + selected_zone to > "/etc/localtime". An error can only be flagged if zic doesn't exist and the > operation on /etc/localtime fails, there's no error checking at all in the > zic case. glibc-common ships /usr/sbin/zic: > http://koji.fedoraproject.org/koji/rpminfo?rpmID=3568832 so why would that > not be found? I tried running zic from the Shell: $ zic /usr/share/zoneinfo/America/Caracas "/usr/share/zoneinfo/America/Caracas", line 1: line too long $ zic /usr/share/zoneinfo/America/New_York "/usr/share/zoneinfo/America/New_York", line 1: line too long $ zic /usr/share/zoneinfo/America/Chicago "/usr/share/zoneinfo/America/Chicago", line 1: line too long so it looks like the problem is with the zoneinfo files. I tried reinstalling tzdata (tzdata-2012j-1.fc18.noarch) but it made no difference. There isn't a more recent version of tzdata even on koji. However I'm confused by something here. Doesn't zic take a textual description of zone info and produce a binary zoneinfo file? The reason I ask is that the contents of /usr/share/zoneinfo are binary files, presumably the output of zic rather than the input to it.
So, the bad news is that this has been broken since AT LEAST Fedora 16 (!). What changed is that F18 apparently doesn't install an /etc/localtime anymore for UTC, so deleting the file fails (at least I think that's what's going on), which uncovers the whole fiasco. Ouch! We should fix this in all supported Fedora releases, this is all the more important for hwclock. (I wonder if and how the hwclock-invoking code ever worked.)
Re comment #6, zic should be invoked as: zic -l America/Caracas and that's how kcm_clock invokes it if it finds it.
I think I have a fix, there should be a build which fixes this in a few hours.
Oh, and please DON'T run zic manually before testing the fix, you might not be able to reproduce (the user-visible part of) the bug if you do. (FYI, I THINK the condition for the error message to show up is that /etc/localtime doesn't exist.)
Can you please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=4923179 ?
(In reply to comment #11) > Can you please test: > http://koji.fedoraproject.org/koji/taskinfo?taskID=4923179 > ? Nearly but not quite. The changes now execute without error (checked by running 'date' from a Shell while the dialogue is still open), but when I exit the dialoque it asks if I want to Apply or Discard the change. Hitting Apply causes the change to revert to UTC. I didn't check what Discard does.
Hmmm, can you please check what time zone is selected in the dialog after you select your timezone and click Apply, but before you exit the dialog? I suspect it is jumping back to UTC, which in turn makes it ask you whether to apply or discard the change which reverts the timezone to UTC (i.e. Discard is actually what you want then). If I'm right and that's what happening, then the problem must be when the dialog reloads the time information using Dtime::load(). That function uses KSystemTimeZones::local() to determine the current time zone, somehow that must be returning wrong or outdated information.
This is another bug, in ktimezoned: https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/ktimezoned/ktimezoned.cpp#L337 It will only watch for changes to /etc/localtime if the file already existed. So if the file was not there and it gets created, nothing happens.
See bug #906972 for the new issue.
Thanks Kevin! Longer term, looks like systemd may actually bring a lot of simplifications our way. I'll look into implementing support for timedatectl too sometime soon (hopefully). $ 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
(In reply to comment #13) > Hmmm, can you please check what time zone is selected in the dialog after > you select your timezone and click Apply, but before you exit the dialog? I > suspect it is jumping back to UTC, which in turn makes it ask you whether to > apply or discard the change which reverts the timezone to UTC (i.e. Discard > is actually what you want then). > > If I'm right and that's what happening, then the problem must be when the > dialog reloads the time information using Dtime::load(). That function uses > KSystemTimeZones::local() to determine the current time zone, somehow that > must be returning wrong or outdated information. Well spotted, that's exactly what is happening. After selecting the new timezone the dialogue box whites out and when it comes back I find UTC is still selected, even though 'date' shows the new timezone.
(In reply to comment #16) > Thanks Kevin! > > Longer term, looks like systemd may actually bring a lot of simplifications > our way. I'll look into implementing support for timedatectl too sometime > soon (hopefully). > > $ 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 When I use timedatectl to set the timezone, the Settings dialogue still thinks it's UTC. This is liable to cause problems down the road.
sure, I believe your findings are part of bug #906972 (kde not properly noticing/detecting the currently configured time zone)
The patch for this bug passed upstream review: https://git.reviewboard.kde.org/r/108711/ I'm committing it to upstream master now, and the upstream 4.10 branch as soon as the tagging freeze is lifted. (I don't think a longstanding bug like this qualifies for a freeze exemption.)
Actually, seeing upstream's kde-workspace git history, I'm probably supposed to commit to 4.10 first and then merge 4.10 into master, so I'll rather do it that way, after the freeze is lifted.
Re using timedatectl: ltinkl looked into that at some point (well, actually the underlying D-Bus API), and found the API to be lacking. In particular, there is no one API to set everything (NTP, time zone, time), so you end up getting prompted for PolicyKit authentication 3 times!
Oh, and of course, it'd be possible to work around it by running timedatectl (or using the D-Bus API) as root, but then we still need the KAuth helper and we just add one more code path to it, which ltinkl didn't see as a win.
libkscreen-0.0.71-2.fc18, kscreen-0.0.71-3.fc18, kde-settings-4.9-19.fc18, kde-workspace-4.9.5-7.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-1183/kde-settings-4.9-19.fc18,kde-workspace-4.9.5-7.fc18,libkscreen-0.0.71-2.fc18,kscreen-0.0.71-3.fc18
libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2013-1248/kde-settings-4.8-24.fc17,kde-workspace-4.9.5-7.fc17,kscreen-0.0.71-3.fc17,libkscreen-0.0.71-2.fc17
kde-workspace-4.8.5-3.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kde-workspace-4.8.5-3.fc16
Package libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libkscreen-0.0.71-2.fc17 kscreen-0.0.71-3.fc17 kde-settings-4.8-24.fc17 kde-workspace-4.9.5-7.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1248/kde-settings-4.8-24.fc17,kde-workspace-4.9.5-7.fc17,kscreen-0.0.71-3.fc17,libkscreen-0.0.71-2.fc17 then log in and leave karma (feedback).
libkscreen-0.0.71-2.fc18, kscreen-0.0.71-3.fc18, kde-settings-4.9-19.fc18, kde-workspace-4.9.5-7.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
libkscreen-0.0.71-2.fc17, kscreen-0.0.71-3.fc17, kde-settings-4.8-24.fc17, kde-workspace-4.9.5-7.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
kde-workspace-4.8.5-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.