We don't use the default dnsmasq directory because packages often drop files
there that don't take account of NM's specific use-case and end up conflicting
with the specific local caching nameserver functionality that NM uses dnsmasq
for. NM's private dnsmasq is orthogonal to whatever global dnsmasq
daemon may be running, and with that daemons configuration.
(dcbw: change directory to private one)
If bluez is started by systemd but for some reason is not set to
be D-Bus activated (as seems to be the case on Fedora 16 and later),
then don't emit a warning.
NM was requiring that bond slaves have either no IP config or an
explicit "none"/"disabled" config. But the system scripts just ignore
any IP config that is present on a slave, so change NM to do that too
(but warn about it).
https://bugzilla.redhat.com/show_bug.cgi?id=838907
Unbreak 'make -j' by declaring the dependency that exists between the
two generated vapi files (forcing building of the second one to wait
until after the first one has been built).
https://bugzilla.gnome.org/show_bug.cgi?id=680374
If a class implements init_async, it should implement init_finish too,
rather than assuming the default implementation will do the right
thing (which it briefly didn't in glib 2.33).
The whole callout is pure dbus, not dbus-glib, so there's really no need
for glib code there. Even so, DBUS_LIBS contains dbus-glib and gobject,
so we're still linking to glib/gobject.
The DNS change frequency reduction patches mistakenly changed the signature
of the VpnStateChanged signal. Fix that, since we try really really
hard not to break the D-Bus API in stable branches. My bad...
Core D-Bus VpnStateChanged signal changed. In order to receive the signal,
the parameters was fixed. This commit also adjusts libnm-glib's vpn-state-changed
signal to match the D-Bus one.
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
Move ra_flags modifications to a dedicated function that
logs the change (if any). Also improve device_set_state()
so that both functions return TRUE if the value actually
changes.
