The functions nm_remote_connection_save(), nm_remote_connection_commit_changes(),
and nm_remote_connection_commit_changes_unsaved() indicate in the documentation,
that they allow omitting the callback argument. Remove invalid checks
for callback.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Most of these warnings are things libnm-glib can't do anything
about, and they are pretty annoying when running nmcli or nmtui,
and libraries usually shouldn't print random warnings anyway.
So downgrade them to debug messages that can be enabled if we
need to see them.
Utility function, to search the list of connections for a connection
with a matching id/name. Returns the first match.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Note that this will cause the nm_device_wifi_get_access_points() to
return hidden-SSID access point objects immediately, which it
previously did not do until added/removed signals were sent by
NetworkManager for a hidden SSID AP. Some clients may not handle
this correctly, but given that they would have crashed when the
first hidden SSID AP was found anyway, they should just be fixed.
With the addition of D-Bus properties for object-array properties in
NetworkManager core, libnm-glib can use these properties instead of
the pseudo-property stuff. However, we need to maintain API and
provide individual added/removed signals for these properties, and
that requires diff-ing the new and old object arrays. Add the
infrastructure for doing that.
This commit adds two new functions for introspection users to get nameservers:
guint32 nm_ip6_config_get_num_nameservers (NMIP6Config *config)
const struct in6_addr *nm_ip6_config_get_nameserver (NMIP6Config *config, guint32 idx)
The existing function can't be used due to GObject introspection limitations:
const GSList *nm_ip6_config_get_nameservers (NMIP6Config *config);
https://bugzilla.redhat.com/show_bug.cgi?id=1056146
result_cb invokes a function pointer provided by the user. Nothing prevents
the user from destroying the NMRemoteConnection in the callback, which leads
to a crash. Take an additional ref of NMRemoteConnection to keep it
alive.
This probably caused a crash for nm-applet:
https://bugzilla.redhat.com/show_bug.cgi?id=1030403
Signed-off-by: Thomas Haller <thaller@redhat.com>
deferred_notify_cb() needs to take a ref on the object around emitting
its deferred signals, since otherwise if a notify:: handler drops the
last reference on an object, a following g_object_notify() call would
crash.
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
When connecting to a hidden SSID, the Access Point object that NetworkManager
creates will have no frequency, because the frequency is unknown until the
connection succeeds. The warning has no use; if the AP doesn't have a
frequency then it even match a connection with a specified frequency.
We have to check if 'client' is valid when calling _nm_object_ensure_inited().
Creation of NMClient object can fail, because its parent NMObject's
constructor() returns NULL for D-Bus errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1010288
gtk-doc recognizes that #NMFoos is the plural of #NMFoo now, so you
don't need to put an empty comment between the type name and the "s"
to make it work. (Unfortunately, it's not smart enough to realize that
"NMIP4Addresses" is the plural of "NMIP4Address".)
Also, add some missing "#"s noticed along the way.
Running `make check` on systems without running dbus failed
in test-remote-settings-client.c:383
make[4]: Entering directory `/tmp/NetworkManager/libnm-glib/tests'
/tmp/NetworkManager/libnm-glib/tests/test-remote-settings-client /tmp/NetworkManager/libnm-glib/tests test-remote-settings-service.py
** (/tmp/NetworkManager/libnm-glib/tests/.libs/lt-test-remote-settings-client:26983): WARNING **: Error connecting to D-Bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
make[4]: *** [check-local] Trace/breakpoint trap (core dumped)
Modify the Makefile to start the dbus-daemon, if it is not yet
running.
Signed-off-by: Thomas Haller <thaller@redhat.com>
All NMObjects created in response to property changes were getting
leaked, which in particular included all NMAccessPoint objects, which
meant that after disconnecting and reconnecting a wifi interface some
number of times (depending on how many access points were in the
area), gnome-shell would be watching so many D-Bus AccessPoint objects
(most of which didn't exist any more) that it would hit dbus-daemon's
limit on the number of match rules you can register, which meant that
NMActiveConnections created after that point wouldn't be able to
register for PropertiesChanged notifications, which meant that the
network status icon would get out of sync.
