Both files do very similar things, with "nm-sleep-monitor-upower.c"
being suboptimal, for example by creating the proxy synchronously.
Clean that up in the next steps. Just basic merging for now.
(cherry picked from commit c76eb3e8f7)
The lifetime of the proxy is not necesarily the same as the lifetime
of the NMSleepMonitor instance. Disconnect the signals during dispose().
(cherry picked from commit a09a5f7fc1)
The daemon does not run with a particular locale of a user. Localizing
makes no sense (at least, we don't do it usually and it would make
logging localized).
(cherry picked from commit 753f727af5)
As we don't take a reference on @self during the asynchronous
request, we must properly support cancelling in case of early
destruction.
I think, it's gdbus' responsibility not to leak any file descriptors
when cancelling a D-Bus request that returns file descriptors. Thus,
our usual pattern works here too.
(cherry picked from commit 2e3ff56cdc)
$ nmcli connection up my-connection
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/42)
$ nmcli connection modify my-connection connection.id other-name
$ nmcli -f connection.id connection show other-name
connection.id: other-name
$ nmcli -f GENERAL.CONNECTION device show enp0s25
GENERAL.CONNECTION: my-connection
$ nmcli connection down other-name
Error: 'other-name' is not an active connection.
Error: no active connection provided.
$ nmcli connection down my-connection
Connection 'my-connection' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/13)
When modifying a connection, NMActiveConnection must update the D-Bus
properties that belong to the settings-connection.
(cherry picked from commit 18019d55a1)
This is mostly interesting of NMPolicy, which no longer needs to
subscribe to two almost identical signals (where the by-user signal
was always invoked together with the plain "updated" signal).
(cherry picked from commit 3164c026a2)
Instead of connecting to two similar signals, combine them into one
and pass "by_user" argument.
We still need to keep the original NM_SETTINGS_CONNECTION_UPDATED signal,
because it is exposed on D-Bus.
(cherry picked from commit 65c55e2a78)
I want to combine NM_SETTINGS_CONNECTION_UPDATED and NM_SETTINGS_CONNECTION_UPDATED_BY_USER
into one signal. Thus, they must have same behavior with respect as to whether they are
scheduled on idle.
Emit NM_SETTINGS_CONNECTION_UPDATED right away.
The "Updated" signal is exposed via D-Bus on the settings object.
Removing the idle handling has no bad consequences there.
Apart from that, the signal has only the listener NMSettings::connection_updated().
connection_updated() first emits NM_SETTINGS_SIGNAL_CONNECTION_UPDATED, which only
has listener: NMPolicy::connection_updated(), which already delegates to
an idle handler.
Second, NMSettings::connection_updated() emits
NM_CP_SIGNAL_CONNECTION_UPDATED which has the following listeners:
- NMBluezDevice::cp_connection_updated(), which can cause the
connection to be tracked/untracked. Any further changes are
already delayed on an idle handler (check_emit_usable_schedule()).
- NMDevice::cp_connection_added_or_updated(), which causes the
connection to be tracked by the device. It also emits
"notify::available-connections", which however is only relevant
for the D-Bus bindings.
At last, it does available_connections_check_delete_unrealized()
which also is on an idle handler already.
(cherry picked from commit a4f1a1794f)
Currently, NM_CP_SIGNAL_CONNECTION_UPDATED signal will be invoked on an
idle handler. I want to change that, so to be save, delay actions that
matter on an idle handler.
(cherry picked from commit 640ef67cd7)
schedule_activate_all() needs to iterate over all devices and is thus
relatively costly (and scales O(n^2)).
By scheduling the action on an idle handler we delay and combine
multiple redundant requests.
Another reason is that NM_SETTINGS_CONNECTION_UPDATED is currently
executed on an idle handler which first leads to
NM_SETTINGS_SIGNAL_CONNECTION_UPDATED signal and eventually calls
schedule_activate_all().
I want to change that to emit the connection update signal immediately,
thus to preserve the delay, we delay handling in NMPolicy.
(cherry picked from commit 920054d8aa)
Due to a bug, NMManager would connect to "notify::connections"
and might miss an important notification when NMSettings declares
startup-complete.
Fixes: b067ca7034
(cherry picked from commit c57e5a6b66)
When one of the configuration snippet is malformed, NM doesn't tell
which file caused the error:
$ NetworkManager --print-config
Failed to read configuration: Key file does not start with a group
Fix this.
$ NetworkManager --print-config
Failed to read configuration: /usr/lib/NetworkManager/conf.d/test.conf: Key file does not start with a group
(cherry picked from commit 57c001200d)
As explained in the function comment, a NULL value for @val is
acceptable. Otherwise:
$ nmcli connection edit
(process:2276): nmcli-CRITICAL **: check_valid_name: assertion 'val' failed
Fixes: fb8fe1d8cb
(cherry picked from commit 73221a809d)
VPN plugins are often not installed or they might be legacy-only.
In both cases we should show a better error message about the
failure reason.
(cherry picked from commit d0f01aa2c2)
Instead of using (only) a hard-coded list of VPN types,
prefer lookup the VPN settings from the .name files.
Still, fallback to a hard-coded list if the plugin cannot
be found, because for connection-add we currently don't
actually need the plugin installed.
(cherry picked from commit 41976e3069)
Otherwise building fails with:
nm-sleep-monitor-upower.c:132:45: error: expected declaration specifiers or '...' before 'nm_sleep_monitor_get'
nm-sleep-monitor-upower.c:132:67: error: expected declaration specifiers or '...' before '(' token
https://mail.gnome.org/archives/networkmanager-list/2016-May/msg00053.html
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
https://bugzilla.redhat.com/show_bug.cgi?id=1265239
(cherry picked from commit 9b7f9af077)
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
(cherry picked from commit c84fd50287)
No need to require the caller to initialize the optional out-argument.
Otherwise we get:
(nm-connection-editor:2471): libnm-CRITICAL **: nm_utils_file_is_private_key: assertion 'out_encrypted == NULL || *out_encrypted == FALSE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=763578
Fixes: 1c4f41c610
(cherry picked from commit 81499355b0)
