GNOME Bugzilla – Bug 680310
Sorting of access points by strengh not working
Last modified: 2013-02-12 04:23:52 UTC
1. I have a wireless connection, but the statusicon still shows disconnected. The menu itself also doesn't have the bullet next to the connected ap. I see lots of access point? JS LOG: An active wireless connection, in infrastructure mode, involves no in the logs - may be related ? 2. The sorting of aps by strength seems to have been lost again. Sorting is random, here 3. Activating a vpn connection fails with JS ERROR: !!! error while reading VPN plugin output keyfile JS ERROR: !!! message = '"Cannot convert string to array of 'utf8'"' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/networkAgent.js"' JS ERROR: !!! lineNumber = '536' JS ERROR: !!! stack = '"()@/usr/share/gnome-shell/js/ui/networkAgent.js:536 wrapper()@/usr/share/gjs-1.0/lang.js:204
1) Needs to see iwconfig / dmesg to debug. Could be duplicate of bug 679942 or (more likely) bug 676345. Or it could be another GAsyncInitable fallout, if libnm-glib fails to construct the NMAccessPoint (but there should be a critical somewhere) 3) It's a introspection problem. g_key_file_load_from_data is mistakenly marked to take an array of utf8 (char**) instead of an array of uint8 (char*), or a string like it used to do when this code was last tested.
Created attachment 219318 [details] iwconfig output
Created attachment 219319 [details] dmesg output
Do we have a fix for the introspection problem in 3) ?
Created attachment 219322 [details] some log output while reconnecting - it ended up with the ... in the status, while the connection works fine
Ok, so 1) is dup of bug 676345 - you're Not-Associated, according to iwconfig (which directly polls the kernel), but kernel logs shows that are actually associated. And gnome-shell doesn't like wireless connections without an access point. The interesting line is (from syslog) Jul 20 08:05:47 golem NetworkManager[4141]: <info> (wlan0): roamed from BSSID 98:FC:11:67:0C:91 (clasen_home) to (none) ((none)) For 3), I'll prepare a patch. Do you prefer a new bug against glib?
Putting the patch here is fine
Created attachment 219328 [details] [review] GKeyFile: fix introspection annotation (array) on an argument of type gchar* without (element-type) makes an array of strings, not an array of characters. Fix it to be an array of bytes, like originally intended.
Review of attachment 219328 [details] [review]: I think we should just go back to what we had before. Changing it to an array of bytes is a change from how it was originally exposed was as utf8.
Created attachment 219330 [details] [review] Revert unintential IAPI break for g_key_file_load_from_data() The old (length) annotation actually wasn't being read. Changing it to an array was telling g-i that it was an array of utf8, which is clearly not true. We *could* add (element-type guint8), but that would change it to a byte array, as opposed to the original utf8 version. Just removing the annotation should bring us back to where we were, which was fine.
It's pretty clear the intention of the person adding the annotation was to make it a bytestring, but... Oh hah, we're in a cycle. Run: git log -p glib/gkeyfile.c This turns up: https://bugzilla.gnome.org/show_bug.cgi?id=658484
And it looks like then Jasper changed it in: https://bugzilla.gnome.org/show_bug.cgi?id=675309
I guess I'll just stop looking at annotation patches...
(In reply to comment #12) > And it looks like then Jasper changed it in: > https://bugzilla.gnome.org/show_bug.cgi?id=675309 Wow, seriously? I don't remember why I needed that at all.
Review of attachment 219328 [details] [review]: .
Review of attachment 219330 [details] [review]: committed this one
If we accept that 1) is a kernel issue, then the only issue left here now is the sorting by strength
Review of attachment 219330 [details] [review]: "unintential"?
its working now, so I'll close this