Description of problem: Whenever the laptop goes between WiFi and Ethernet, Gwibber stops updating and must be restarted. Version-Release number of selected component (if applicable): gwibber-1.2.0-3.349bzr.fc12.noarch How reproducible: 100% Steps to Reproduce: 1. Run gwibber 2. ifdown eth0 3. ifup wlan0 Actual results: Gwibber must be restarted to work Expected results: Gwibber continuting to work Additional info: This failure usually happens when an application holds onto a socket, although I did not run strace on Gwibbler. Sockets must be opened anew before each RPC to Twitter, do not cache them.
try the gwibber in updates-testing, it is much more robust about that as a result of design model changes.
Oh GOD Updating: gwibber noarch 1:2.30.0.1-1.fc12 updates-testing 441 k Installing for dependencies: couchdb x86_64 0.10.0-2.fc12 fedora 513 k desktopcouch noarch 0.6.3-3.fc12 updates 22 k erlang x86_64 R13B-04.4.fc12 updates-testing 34 M js x86_64 1.70-8.fc12 fedora 340 k libicu-devel x86_64 4.2.1-7.fc12 updates 616 k python-couchdb noarch 0.6.1-2.fc12 updates 83 k python-desktopcouch noarch 0.6.3-3.fc12 updates 64 k python-desktopcouch-records noarch 0.6.3-3.fc12 updates 78 k python-distutils-extra noarch 2.15-1.fc12 updates 41 k python-httplib2 noarch 0.4.0-4.fc12 fedora 31 k python-oauth noarch 1.0.1-1.fc12 fedora 17 k python-twisted-core x86_64 8.2.0-6.fc12 updates-testing 2.0 M python-zope-filesystem x86_64 1-4.fc12 fedora 5.2 k python-zope-interface x86_64 3.5.2-2.fc12 fedora 103 k tcl x86_64 1:8.5.7-5.fc12 updates 1.9 M tk x86_64 1:8.5.7-3.fc12 updates 1.4 M unixODBC x86_64 2.2.14-9.fc12 updates 378 k wxGTK-gl x86_64 2.8.10-7.fc12 updates 31 k Seriously though... erlang, tcl, tk for gwibber?
gwibber-2.30.0.1-1.fc12.noarch seems to work
Yeah. I know. We're looking at a way to try to not depend on desktopcloud, but we're not there yet.