Re: ANN: Release of NetworkManager 0.8.996 (0.9.0-beta2)

[Dan Williams <dcbw redhat com>]

On Fri, 2011-03-11 at 11:25 -0600, Dan Williams wrote:
> On Fri, 2011-03-11 at 17:21 +0300, Mikhail Efremov wrote:
> > On Fri, 11 Mar 2011 14:58:09 +0100 Michael Biebl wrote:
> > > Am 11.03.2011 14:26, schrieb Mikhail Efremov:
> > > > On Fri, 11 Mar 2011 10:28:58 +0100 Michael Biebl wrote:
> > > >> Am 11.03.2011 09:49, schrieb Michael Biebl:
> > > >>>
> > > >>> Been testing the 0.8.996 packages. Looking quite ok so far.
> > > >>>
> > > >>> Some impressions:
> > > >>>
> > > >>
> > > >> The online/offline (D-Bus) API seems to be broken.
> > > >> firefox always starts in offline mode now when using
> > > >> toolkit.networkmanager.disable false
> > > > 
> > > > Values of NM states have been changed. See commits ec115ed4 and
> > > > 11a68133. So all applications which uses that API should be rebuilded.
> > > > But firefox uses its own hardcoded constants (see
> > > > toolkit/system/dbus/nsNetworkManagerListener.cpp).
> > > 
> > > I don't think NM should break that specific D-Bus API and be backwards compatible.
> > 
> > Yes, I agree with you. I see no reasons to change these values, except
> > for cosmetic. But maybe Dan will explain why this was done.
> 
> Patches have been submitted for most of the affected programs that I
> could find (including Firefox).  For any others, the changes are quite
> minimal and the patch is able to preserve backwards compatibility in the
> same code.  That's only possible because the old states are all < 10,
> which is one reason the new states are numbered the way they are.
> 
> States are renumbered since there are now 3 connected states (LOCAL,
> SITE, GLOBAL) depending on the network connectivity.  There's also a new
> DISCONNECTING state that will eventually facilitate Debian's
> long-standing request for a "pre-down" event.  There's also space
> between the states in case in the future we want to add more without
> breaking API.

I assume that most KDE apps would be using whatever abstraction Plasma
provides over top of NM and other network daemons.  Perhaps that's
completely wrong.  The actual KDE plasma networkmanagement story is
being hashed out right now.

But anyway, that leaves desktop-agnostic apps and GNOME apps:

empathy: https://bugzilla.gnome.org/show_bug.cgi?id=644412
geoclue: http://cgit.freedesktop.org/geoclue/commit/?id=f2f988bfdda6a347a8190612af1501466b64d76b
krb5-auth-dialog: http://git.gnome.org/browse/krb5-auth-dialog/commit/?id=3deb396641e2e28a6637d3f57af27aebfd7882a8
libsocialweb: http://git.gnome.org/browse/libsocialweb/commit/?id=da899278ae076972cd1fa15142b8a79a6be3000f
liferea: http://sourceforge.net/tracker/?func=detail&aid=3203121&group_id=87005&atid=581684
tracker: http://git.gnome.org/browse/tracker/commit/?id=6a73ff3929f87d734abfdb21c8a20bab5a9c2cc1
evolution: http://git.gnome.org/browse/evolution/commit/?id=8a81ec271ed0ab05b8fdfb5cbf374867b3906352
firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=639959

Packages that simply install dispatcher scripts likely don't need
changes because they probably don't do that much with NM.

What other apps are out there that  might be using libnm-glib or talking
to NM via D-Bus for network state?

Dan