Created attachment 375983 [details] there is Internet access, but the plasmoid never updates Description of problem: kde-plasma-yawp only shows (cache) status with wireless. maybe needs udev support with 0.3.1 Version-Release number of selected component (if applicable): Name : kde-plasma-yawp Arch : i586 Version : 0.2.3 Release : 1.fc11 How reproducible: always Steps to Reproduce: 1.add kde-plasma-yawp 2.reboot with only wireless 3.repeat step 2 Actual results: old data Expected results: accurate weather Additional info:
I doubt that this bug is yawp specific. I don't see any network related code in the source other than KIO jobs. Could you try other plasmoids that access internet (e.g. another weather plasmoid) and see if they work? By the way, it works here with my wireless card.
(In reply to comment #1) > I doubt that this bug is yawp specific. I don't see any network related code in > the source other than KIO jobs. Could you try other plasmoids that access > internet (e.g. another weather plasmoid) and see if they work? > > By the way, it works here with my wireless card. Whatever your doubts, it does not work for me. yaWP Settings. "City name:", Find - no search results. That with a functional net on the desktop.
okay but > Could you try other plasmoids that access > internet (e.g. another weather plasmoid) and see if they work?
Sorry, I am not sure if I understand the problem correctly. Let's start from the beginning. The way the bug was opened, it feels like the yawp does not work when you are using wireless, but it would work when you are wired. Is that the case? If not, what is the "wireless" for?
(In reply to comment #4) > Sorry, I am not sure if I understand the problem correctly. Let's start from > the beginning. No, I'm sorry that I didn't know more from the start. The problem is deeper than yawp, as weather and opendesktop also cannot be changed to any point requiring Internet access. Even konqueror finds no servers *if* it is started as part of the user profile. I'll research to see if other bugs already address this problem.
This bug https://bugs.kde.org/show_bug.cgi?id=135230 has a similar ring to it. In my case, visually anyway, the problem seems related to the timing with which NetworkManager Applet establishes network access. With wireless the network access is established later in the desktop startup, and the plasmoids never are active, sometimes konquerer gets "Unknown host" too. With wired access, as I've done right now on System eth0, all is well - yawp, weather, and opendesktop connected and displayed the expected things. The konqueror sessions active on login also started normally.
This finally happened to me too, after changing my connection type from dhcp to static IP. This is a wired connection though. And I have NetworkManager disabled.
Further testing indicates to me that the underlying problem is not specific to any desktop, so I've re-assigned this to NetworkMangler. Though it is possible that the problem is really with all desktops... I can reproduce similar behaviour in Gnome with the Invest and Weather Report applets. 1. Right click on Gnome desktop panel, add Invest and Weather Report. 2. For my case, I switch the network to wireless, *and* disable the routing obtained by the wired connection. 3. On login, wireless connects and is available, but Invest and Weather Report do not have accurate updates until their respective "refresh" time occurs. Naturally, everything else - firefox, etc. - works fine. NetworkManager-0.7.2-1.fc11.src.rpm
kde/solid (as well as other nm-aware apps) has the ability to detect whether a network is active or not. From what I can tell, it's pretty much up to individual apps to enable/use that functionality (ie, to know whether or not to attempt a network connection or not).
(In reply to comment #9) > kde/solid (as well as other nm-aware apps) has the ability to detect whether a > network is active or not. From what I can tell, it's pretty much up to > individual apps to enable/use that functionality (ie, to know whether or not to > attempt a network connection or not). That seems like a reasonable position. So begins the task of bug assignment where apps, generally speaking, don't work with nm as expected, or don't work with nm at all. From what you say, kde/solid is in the former case, so I've reassigned this one to kdelibs. Beyond that, the applet(s) could also have incorrect or non-existent ties to solid, I suppose?
It's not kdelibs, it's the individual apps that try to access the network before any active connection is present.
(In reply to comment #11) > It's not kdelibs, it's the individual apps that try to access the network > before any active connection is present. Perhaps that's true, but one could argue, with 99% certainty that a network connection of *some* kind is forthcoming, that it is the fault of the desktop for starting the applications too soon.
I respectfully disagree with that assertion (I seriously doubt DE's would accept the job/responsibility of handling startup prerequisites like that).
(In reply to comment #13) > I respectfully disagree with that assertion (I seriously doubt DE's would > accept the job/responsibility of handling startup prerequisites like that). Fair enough. I'll begin the task of opening bugs. Shall I clone this one for each, or create new bugs with a more abbreviated description?
(In reply to comment #1) > I doubt that this bug is yawp specific. I don't see any network related code in > the source other than KIO jobs. Could you try other plasmoids that access > internet (e.g. another weather plasmoid) and see if they work? It seems this is yawp specific, so assigned back to it.
It's specific to each app/plasmoid lacking this desirable feature. To be clear, this is more of an RFE than a bug.
Why is this assigned back to me? yawp doesn't even have network related code other than where it just asks for a kio job at one place to download the weather report. Is there really something I can do about this?
yawp can add the 'feature' of listening to solid for an active network or not, that's what this is about. Probably best to submit such a request upstream though... (if you're not able or intested in implementing it yourself).
Thank you for taking the time to report this issue to us. This is an issue which is best addressed by the upstream developers. Please file a report at bugs.kde.org , and when done at the upstream report info to this report. We will continue to track the issue in the centralized upstream bug tracker, and will review any bug fixes that become available for consideration in future updates. Thank you for the bug report. This bug has been triaged Steven M. Parrish KDE & Packagekit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
A few things ... o Note I've changed the summary as I'm better able to re-create the problem. o Yawp (v 0.2.2 and up) does support Solid - an easy test is to disconnect/re-connect the network - Yawp notices both, but does not refresh the weather info. o Yawp is from kde-look.org and I see no way of filing bug reports against it.
(In reply to comment #20) > o Yawp is from kde-look.org and I see no way of filing bug reports against it. Actually, you go to the yawp page in kde-look. There is a comments section on the bottom which serves the purpose of a bug reporting mechanism, and upstream is very responsive to comments and bugs reported there.
(In reply to comment #21) > Actually, you go to the yawp page in kde-look. There is a comments section on > the bottom which serves the purpose of a bug reporting mechanism, and upstream > is very responsive to comments and bugs reported there. I've added a comment regarding this issue.
The problem went away after several updates were applied. One of which was NM, so I'll file this under it.
It's back again. Plasmoids have no love. 23:12:50.050 Warning AccuWeatherIon::image_slotJobFinis (Line 918): . "Unknown host sirocco.accuweather.com" Apps are fine, for example firefox, konqueror, krdc. Weird. useradd a test account and it behaves the same. I suspect older hw - Dell D600, and the multitasking at login can't handle it.
Created attachment 390449 [details] desktop w/ net, but not for plasme note that net (wireless) is fine.
Please file bugs against the individual apps/plasma-applets/etc (see also comment #16 and comment #18 saying the same thing). Lumping all apps' issues together here isn't productive. So, by my count we have: kde-plasma-yawp anything else?
(In reply to comment #26) > Please file bugs against the individual apps/plasma-applets/etc (see also > comment #16 and comment #18 saying the same thing). > > Lumping all apps' issues together here isn't productive. > > So, by my count we have: > kde-plasma-yawp > > anything else? Yes, please. Some time for me to research it, but ideally, some help to troubleshoot it. What I know: 1. My problem is on FC11, and with my $HOME that's been in place for awhile, maybe since FC10. 2. I have two (2) $HOME, jerry.good and jerry.bad, with the "good" one just a standard /etc/skel, then logged into KDE, setup wireless and plasma apps. What I think: 1. It's not SELinux. 2. It's not app specific. All comments above aside, the fact I can narrow it down to the difference between to $HOME directory makes it tough to suspect each app/plasmoid. More to come...
Fiddlesticks. I fixed the "bad" $HOME by copying files from the good one, but forgot to save the console tty session in such a way to see what was actually copied over. I believe they were all just network related files under $HOME/.gconf - I can still reproduce it with a third $HOME that I'd saved, but now have to go through the process of elimination again. grrr.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. 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 Fedora version prior to Fedora 11'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 Fedora 11 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 Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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 Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
The "Weather Forecast" widget still elicits this behaviour.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. 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 Fedora version prior to Fedora 13'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 Fedora 13 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 Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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 Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.