GNOME Bugzilla – Bug 528145
weather icon and temperature do not show in panel
Last modified: 2008-04-16 01:55:16 UTC
Please describe the problem: after a recent fedora rawhide update, the clock no longer displays the weather icon or temperature in the panel, depite these options being checked in the preferences. The appropriate weather icon is still displayed in the left-click "> Locations" drop down. Steps to reproduce: 1. Right click the clock applet in the panel 2. Select Preferences 3. Ensure the "Show weather" and "Show temperature" boxes are checked 4. Add the location "Atlanta -> Hartsfield Airport" (any location with weather data will work)" 5. Click "close" Actual results: The clock applet does not show the weather icon or the temperature in the panel Expected results: The weather icon and the temperature should be shown in the panel applet. Does this happen every time? yes Other information: When I check the "Show weather" and "Show temperature" options, I can see the clock scoot over a bit to the right as each option is selected, like it is displaying an invisible, and very narrow icon. There is no icon displayed there, only blank space. Removing and re-adding the clock applet, or a second clock changes nothing. By twiddling with the DPI and Desktop font sizes, I was able to see what I believe is a tiny sliver of the weather icon, but still no temperature. It looks as if the icon and temp just aren't being drawn, only a blank space. Or perhaps it is just that the applet isn't wide enough and the icon and temp are clipped out.
Is Atlanta marked as your current location? Can you post screenshots showing the difference in width of the clock that you talk about in "Other information"?
Created attachment 109303 [details] screenshot showing narrow clock, with temperature and weather display disabled
Created attachment 109304 [details] screenshot showing wide clock; temperature and weather are enabled
Atlanta is not marked as my current location. I seem unable to add a current location. Even if I delete all locations and add only Atlanta to the list, it is never marked as current. Maybe that is the root of the problem.
Jason: in the calendar popup, if you move your mouse over Atlanta, you should see a "Set current" button. Does it work?
No, the "Set current" button does not appear when I hover over Atlanta in the popup.
Jason: hmm, the location is not current but you have no way to set it as the current one? Can you first copy the value of the /apps/panel/applets/clock_screen0/prefs/cities gconf key (where "clock_screen0" is a string that will probably be different on your setup) here? Then, can you try adding another location in another timezone and change your timezone to this location? Does the weather information appear now?
Also make sure the timezone for Atlanta is right (try editing the location in the preferences). There was a bug before that caused locations to have wrong timezones.
Here is the contents of /apps/panel/applets/applet_0/prefs/cities: <location name="Atlanta" timezone="America/New_York" latitude="33.629723" longitude="-84.442223" code="KATL" current="false"/> Earlier, I tried editing this key to change current to "true". I restarted the panel weather was still not shown, however, thereafter when I hover over the location in the popup, I do see a button labelled "Set", which has no effect on the clock applet when clicked, but does trigger an SELinux denial. (attachment of SELinux troubleshooter output will follow) So, do you want me to set the system timezone to one of the other locations? IOW, you want /etc/localtime to match one of those locations timezones, correct? I will attach a screenshot of my clock preferences dialogs so you can verify the Locations settings. Note that when I turn off SELinux enforcement ('setenforce permissive'), I am able to set a home timezone and weather now works. Does this sound like an SELinux policy problem yet?
Created attachment 109314 [details] SELinux troubleshooter ourput for denial when 'Set' button clicked This SELinux troubleshooter output was generated when I clicked the 'Set' button next to a location in the calendar popup.
Created attachment 109315 [details] clock location preferences dialogs shot showing location dialogs to verify that Atlanta is a location and has the proper time zone set.
(In reply to comment #9) > So, do you want me to set the system timezone to one of the other locations? > IOW, you want /etc/localtime to match one of those locations timezones, > correct? I want you to change your current timezone to Moscow with the clock applet. If it works, you should get the weather for Moscow displayed. Then change it back to Atlanta. > I will attach a screenshot of my clock preferences dialogs so you can verify > the Locations settings. > > Note that when I turn off SELinux enforcement ('setenforce permissive'), I am > able to set a home timezone and weather now works. > > Does this sound like an SELinux policy problem yet? I have no idea if it can be SELinux-related. You'd have to ask people who know about this to know :/
Once I turn off SELinux enforcement, I can freely change my time zone using the clock applet and I see the weather and temp in the panel applet just fine. I think it's an SELinux policy problem. gnome-clock-applet-mechanism needs to do something to set the time zone, and SELinux does not allow it to do it. My theory of what happened is, the timezone could not be set by the clock applet, so no location was set as "current", so there was no way to display weather, cause it wasn't clear which weather should be displayed. I will go do some more research to see if there's a Fedora/SELinux bug filed for this and update this bug with the bug numbers from there. Thanks for the help, Vincent. If you want to pursue this further to get more details, we can, but I'll also go dig around in the fedora and selinux big databases as well.
Ok, there's at least one GNOME bug here: if the location is in the current timezone, you should be able to mark it as current without any problem. For the rest of the bug, yes, please see with Fedora people. Thanks!
(In reply to comment #14) > Ok, there's at least one GNOME bug here: if the location is in the current > timezone, you should be able to mark it as current without any problem. Ok, we do have code for this. So there's a real problem :-) Can you look in /etc/sysconfig/clock if ZONE is set to America/New_York?
ok, I filed a fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=442585 /etc/sysconfig/clock appears to be correct: [root@taplop libexec]# cat /etc/sysconfig/clock # The ZONE parameter is only evaluated by system-config-date. # The time zone of the system is defined by the contents of /etc/localtime. ZONE="America/New_York" [root@taplop libexec]# And /etc/localtime is identical to /usr/share/zoneinfo/America/New_York: [root@taplop libexec]# md5sum /etc/localtime /usr/share/zoneinfo/America/New_York e4ca381035a34b7a852184cc0dd89baa /etc/localtime e4ca381035a34b7a852184cc0dd89baa /usr/share/zoneinfo/America/New_York [root@taplop libexec]#
One question relating to the SELinux side of things: The failure we're seeing is when SELinux denies gnome-clock-applet-mechanism the ability to use the ptrace() system call. What is gnome-clock-applet-mechanism using ptrace for? Is that a legitimate syscall we should expect gnome-clock-applet-mechanism to make? (let me know if this is a topic we should take to another bug, or to a mail list or forum, I'll be happy to oblige)
(In reply to comment #17) > One question relating to the SELinux side of things: > > The failure we're seeing is when SELinux denies gnome-clock-applet-mechanism > the ability to use the ptrace() system call. > > What is gnome-clock-applet-mechanism using ptrace for? Is that a legitimate > syscall we should expect gnome-clock-applet-mechanism to make? There's no ptrace() call there. It must be in some library used by this program. No idea which one...
(In reply to comment #13) > Once I turn off SELinux enforcement, I can freely change my time zone using the > clock applet and I see the weather and temp in the panel applet just fine. Hrm, I hadn't seen this part of your previous comment. So that's not the problem I thought. That's really only related to SELinux usage, and I have no way to debug this. I'd recommend taking this to Fedora too. You probably get a SELinux error too when the applet starts?
I don't believe I get an error at applet start. The following will probably sound like gibberish, but I wanted to post my explanation of what's going on here for the benefit of those searching. I noticed that other similar policykit helper programs have an selinux context of system_u:object_r:bin_t:s0, whereas gnome-clock-applet-mechanism has the same context as the other gnome-clock components (system_u:object_r:gnomeclock_exec_t:s0). When I changed the context of gnome-clock-applet-mechanism to that shared by other policykit helpers, the time zone setting problems went away. I have updated the fedora bug with this information. So, either Fedora's system_u:object_r:gnomeclock_exec_t:s0 context needs to have more capabilities added, or their gnome-clock-applet-mechanism needs the same context as the other policykit helpers. So it seems it's entirely an SELinux configuration problem. Thanks for the assistance, Vincent! Appreciate your help.