GitLab

Was causing duplicate signal emissions on the bus.

Conflicts:
	libnm-glib/Makefile.am
	src/system-settings/nm-sysconfig-settings.c
	system-settings/plugins/ifcfg-rh/plugin.c

It uses malloc(), which you can't do from a signal handler.

Which isn't a problem, since we already require glib-2.16 which
includes gio.  Thus, we can remove all the gfilemonitor compat
stuff.

The driver is on the grandparent, not the parent.

Work around a PPP bug (#1732) which causes many mobile broadband
providers to return 10.11.12.13 and 10.11.12.14 for the DNS servers.
Apparently fixed in ppp-2.4.5 but we've had some reports that this is
not the case.

http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=2e09ef6886bbf00bc5a9a641110f801e372ffde6
http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=f8191bf07df374f119a07910a79217c7618f113e

With the addition of IPv6, both v4 and v6 configuration are run in
parallel, and when both have finished, then activation can proceed.
Unfortunately, two of the 3 users of PPP (PPPoE and 3G) ran PPP at
stage2, and when the PPP IPv4 config was received, jumped directly
to activation stage4.  That caused the IPv6 code never to run, and
thus we hung at stage4 waiting for it to complete when nothing had
started it in the first place.

Instead, move PPP to stage3 so that
nm_device_activate_stage3_ip_config_start() can kick off both v4
and v6 IP code and we can successfully complete IP configuration
in all cases.  PPP previously being in stage2 was an artifact of
the more simplistic pre-IPv6 configuration code where it didn't
matter if you skipped stage3.

The counter wasn't getting reset, so the second time the connection was
activated, secrets would be requested even though they weren't needed.

NMExportedConnection implements these already, and we want the functionality
that it provides, so we don't need to override them here.

Ensure that updating the connection really sends out the updated signal, and
that trying to update/delete a read-only connection over D-Bus returns an
error.

instead of an NMSettingsConnectionInterface, because we won't always have an
object that implements NMSettingsConnectionInterface.  Plus, since NMConnection
is a prerequisite of NMSettingsConnectionInterface, the NMConnection will
always be there anyway.

Give them time to get their settings from the remote settings service
first, then let subclasses/users/whatever know about them.

Since NMSettingsConnectionInterface already has NM_TYPE_CONNECTION as a prerequisite,
which already implements these properties, it's pointless to have them on
NMSettingsConnectionInterface too.