The team API was backported to nm-1-10 branch.
It will be released both as 1.12.0 and 1.10.2.
To ensure the upgrade path from 1.10.2+ to 1.12+ works, the symbols
in libnm must be present on both versions.
Usually, we would duplicate the symbols on master via
NM_BACKPORT_SYMBOL() macro.
However, as we are sure that we will release 1.10.2 before 1.12.0,
we can just update the linker version of these symbols. So, although
the symbols will be first released on major release 1.12.0, their linker
version tag is libnm_1_10_2, to ease upgrade and to avoid duplicating the
symbols.
Team allows to specify multiple link watchers for each link.
Define a link watcher object in order to allow to specify multiple ones
for each Team configuration.
The update2 API was backported to nm-1-10 branch, with commit
ad7f1d18a0. It will be released
both as 1.12.0 and 1.10.2.
To ensure the upgrade path from 1.10.2+ to 1.12+ works, the symbols
in libnm must be present on both versions.
Usually, we would duplicate the symbols on master via
NM_BACKPORT_SYMBOL() macro.
However, as we are sure that we will release 1.10.2 before 1.12.0,
we can just update the linker version of these symbols. So, although
they are first released on major release 1.12.0, their linker version
tag is libnm_1_10_2, to ease upgrade and to avoid duplicating the
symbol.
- only add an async version. I think sync requests are fundamentally flawed
because they mess up the order of D-Bus messages. Hence, also don't
call the function *_async(), like we do for other functions. As there
is only the async form, it doesn't have a suffix.
- Don't accept a NMConnection as @settings argument, but a GVariant.
In general, keep the libnm API closer to the D-Bus API and don't hide
the underlying function with a less powerful form. The user still can
conveniently call the function with
nm_remote_connection_update2 (connection,
nm_connection_to_dbus (NM_CONNECTION (connection),
NM_CONNECTION_SERIALIZE_ALL),
save_to_disk
? NM_SETTINGS_UPDATE2_FLAG_TO_DISK
: NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY,
NULL,
cancellable,
callback,
user_data);
I believe the parts of libnm that invoke D-Bus methods, should be
close to the D-Bus API. Not like nm_remote_connection_commit_changes()
which has no corresponding D-Bus method.
We already have Update(), UpdateUnsaved() and Save(), which serve
similar purposes. We will need a form of update with another argument.
Most notably, to block autoconnect while doing the update.
Other use cases could be to prevent reapplying connection.zone and
connection.metered, to to reapply all changes.
Instead of adding a specific update function that only serves that
new use-case, add a extensible Update2() function. It can be extended
to cope with future variants of update.
It's rather limiting that the only API to access *all* keys
is nm_setting_vpn_foreach_data_item() and nm_setting_vpn_foreach_secret().
API like nm_setting_vpn_get_num_secrets() is not useful, at least as
long as you cannot access the item by index.
We also do this for libnm and libnm-core, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
GHashTable optimizes a NULL equality function to use direct pointer
comparison. That saves the overhead of calling g_direct_equal().
This is also documented behavior for g_hash_table_new().
While at it, also don't pass g_direct_hash() but use the default
of %NULL. The behavior is the same, but consistently don't use
g_direct_hash().
Register empty "NMClient" and "NetworkManager" GIR modules as soon as libnm is
loaded witch gnome-introspection. This prevents the real modules from being
loaded because they would in turn load libnm-glib and abort() and crash.
In particular this prevents the GNOME shell from crashing with
libnm-glib abort and allows gracefully disabling the extensions which
use the obsolete library.
Test:
$ cat test.js
const NM = imports.gi.NM;
print (NM.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
const NMClient = imports.gi.NMClient;
print (NMClient.SecretAgentGetSecretsFlags.ALLOW_INTERACTION);
Before:
$ gjs test.js
1
(gjs:16253): libnm-util-ERROR **: libnm symbols detected; Mixing libnm with libnm-util/libnm-glib is not supported
Trace/breakpoint trap (core dumped)
$
After:
$ gjs test.js
1
Gjs-Message: JS WARNING: [test.js 5]: reference to undefined property "SecretAgentGetSecretsFlags"
(gjs:16228): Gjs-WARNING **: JS ERROR: TypeError: NMClient.SecretAgentGetSecretsFlags is undefined
@test.js:5:1
JS_EvaluateScript() failed
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
There is no API to get all settings. You can only ask for
settings explicitly, but that requires you to probe for them
and know which ones may exist.
The alternative API might be nm_connection_for_each_setting_value(),
but that only iterates over settings' properties. If a setting has no
properties, it is ignored.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
