Now that nm-setting-docs.xml is more D-Bus-specific, it's less
appropriate for nmcli's internal documentation. So generate a second
copy of the docs without using the overrides file, and use that one
for nmcli's documentation.
Add "---dbus---" sections to the NMSetting property docs, in the same
style as the plugin docs, parse them out into a file
"nm-setting-docs-overrides.xml", and use them to override the GObject
property docs in nm-setting-docs.xml.
This lets us put more D-Bus-specific information in the setting docs,
without cluttering up the property docs, and it also lets us document
dbus-only properties.
Add nm_setting_get_dbus_property_type(), and use this to get the
correct type for properties in nm-seting-docs.xml, in situations where
the D-Bus and GObject property types don't match.
In the case of enum/flags-valued properties, give both the enum name
and the underlying D-Bus type.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
All the old "const GByteArray" methods got changed to return a GBytes
instead, but since they aren't declared "const" any more, we need to
explicitly annotate them "(transfer none)".
Also, the scanner apparently doesn't recognize that an (out)
"const char **" is "(transfer none)", so annotate that in two places
too
Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _()
will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than
"gettext (string)" (which will use the program's default domain, which
works fine for programs in the NetworkManager tree, but not for
external users). Likewise, we need to call bindtextdomain() so that
gettext can find the translations if the library is installed in a
different prefix from the program using it (and
bind_textdomain_codeset(), so it will know the translations are in
UTF-8 even if the locale isn't).
(The fact that no one noticed this was broken before is because the
libraries didn't really start returning useful translated strings much
until 0.9.10, and none of the out-of-tree clients have been updated to
actually show those strings to users yet.)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Causes the info->remaining to be counted incorrectly possibly resulting in
g_main_loop_quit() being called twice:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5a03155 in g_mutex_lock (mutex=0x7ffff7b764b4) at gthread-posix.c:1331
1331 if G_UNLIKELY (g_atomic_int_add (&mutex->i[0], 1) != 0)
Missing separate debuginfos, use: debuginfo-install libgcc-4.9.2-1.fc21.x86_64 libgudev1-216-8.fc21.x86_64 libselinux-2.3-5.fc21.x86_64 libuuid-2.25.2-1.fc21.x86_64 ncurses-libs-5.9-16.20140323.fc21.x86_64 nspr-4.10.7-1.fc21.x86_64 nss-3.17.2-1.fc21.x86_64 nss-softokn-3.17.2-1.fc21.x86_64 nss-softokn-freebl-3.17.2-1.fc21.x86_64 nss-util-3.17.2-1.fc21.x86_64 sqlite-3.8.7-1.fc21.x86_64 systemd-libs-216-8.fc21.x86_64
(gdb) bt
#0 0x00007ffff5a03155 in g_mutex_lock (mutex=0x7ffff7b764b4) at gthread-posix.c:1331
#1 0x00007ffff59bf258 in g_main_loop_quit (loop=0x7fffffffd130) at gmain.c:4000
#5 0x00007ffff5edc3bf in <emit signal notify:active-connection on instance 0x5555557bd180 [NMDeviceVlan]> (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3365
#2 0x00007ffff5ec1d35 in g_closure_invoke (closure=0x5555557b3da0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd760, invocation_hint=invocation_hint@entry=0x7fffffffd700) at gclosure.c:768
#3 0x00007ffff5ed3a52 in signal_emit_unlocked_R (node=node@entry=0x555555787040, detail=detail@entry=341, instance=instance@entry=0x5555557bd180, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd760) at gsignal.c:3553
#4 0x00007ffff5edc191 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd8f0) at gsignal.c:3309
#6 0x00007ffff5ec6465 in g_object_dispatch_properties_changed (object=0x7ffff7b764b4, n_pspecs=1434087776, pspecs=0x5555557ba880) at gobject.c:1056
#7 0x00007ffff5ec88c1 in g_object_notify (pspec=<optimized out>, object=0x5555557bd180 [NMDeviceVlan])
at gobject.c:1149
#8 0x00007ffff5ec88c1 in g_object_notify (object=0x5555557bd180 [NMDeviceVlan], property_name=property_name@entry=0x7ffff7b772f6 "active-connection") at gobject.c:1197
#9 0x00007ffff7ae57d3 in deferred_notify_cb (data=<optimized out>) at nm-object.c:246
#10 0x00007ffff59beafb in g_main_context_dispatch (context=0x555555784ac0) at gmain.c:3111
#11 0x00007ffff59beafb in g_main_context_dispatch (context=context@entry=0x555555784ac0) at gmain.c:3710
#12 0x00007ffff59bee98 in g_main_context_iterate (context=0x555555784ac0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#13 0x00007ffff59bf1c2 in g_main_loop_run (loop=0x5555557699e0) at gmain.c:3975
#14 0x000055555555811d in test_activate_virtual () at test-nm-client.c:1103
#15 0x00007ffff59e4243 in g_test_run_suite_internal (tc=0x555555769a30) at gtestutils.c:2059
#16 0x00007ffff59e4243 in g_test_run_suite_internal (suite=suite@entry=0x555555766640, path=path@entry=0x7ffff5a6355e "") at gtestutils.c:2120
#17 0x00007ffff59e4412 in g_test_run_suite_internal (suite=suite@entry=0x555555766620, path=<optimized out>,
path@entry=0x7ffff5a6355e "") at gtestutils.c:2131
#18 0x00007ffff59e477b in g_test_run_suite (suite=0x555555766620) at gtestutils.c:2184
#19 0x00007ffff59e47b1 in g_test_run () at gtestutils.c:1488
#20 0x0000555555556c01 in main (argc=1, argv=0x7fffffffe028) at test-nm-client.c:1189
https://bugzilla.gnome.org/show_bug.cgi?id=739861
Because internal objects do some processing/setup in the various
_added class signal handlers, they need to be emitted before
property change notifications. Otherwise it leads to situations
where external objects that listen to NMClient property changes
will be called before internal processing has been completed.
Specifically, NMRemoteSettings uses connection_added() to check
connection visibility and assign the new connection to one of
two internal arrays. If a client got a property notification
for NMClient::connections before NMRemoteSettings can process
the new connection, then nm_client_get_connections() will
return an empty array because NMRemoteSettings hasn't had the
chance to add the new connection to priv->visible yet, which
is done in NMRemoteSettings::connection_added().
Fixes:Beaker:NetworkManager_Test240_nmtui_general_realtime_refresh_edit_screen
Make NMClient disconnect from the NMManager and NMRemoteSettings
signals when disposing, in case they outlive the NMClient (which
shouldn't happen, but...)
Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
Update the docs build to include and exclude the correct files.
Fill in some missing documentation, and fix problems in the existing
docs. (In particular, "<" can't appear as a literal in documentation,
so change it to "<". Also, "PKCS#12" has to be written as
"PKCS#<!-- -->12", or gtk-doc will think "#12" is a reference to a
type named "12".)
A NMActiveConnection may disappear before a match with NMDevice is found. In
such case recheck_pending_activations() would never call the activation
callback and the client would hang indefinitely:
libnm-Message: PC: (0x95bf088) NMManager:active-connections => '['/org/freedesktop/NetworkManager/ActiveConnection/225']' (ao / NMActiveConnection)
libnm-Message: PC: (0x95bf088) NMManager:activating-connection => ''/'' (o / NMActiveConnection)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:state => '4' (u)
libnm-Message: PC: (0x95d0a28) NMActiveConnection:devices => '[]' (ao / NMDevice)
libnm-Message: PC: (0x95bf088) NMManager:active-connections => '[]' (ao / NMActiveConnection)
*hang*
Let's listen for active-connection-removed and tear down the activation with
an error if the removed connection is one we're activating.
Rename NMVpnPluginUiInterface to NMVpnEditorPlugin (to clarify that
it's unrelated to NMVpnPlugin), and add it to NetworkManager.h.
Rename NMVpnPluginUiWidgetInterface to NMVpnEditor, because it's not a
widget, and will soon be used for non-gui editing too. (Also, add a
placeholder for the method that non-gui editing will use.)
Fix the typedefs to not mix up the (dummy) NMVpnEditorPlugin and
NMVpnEditor types with the types of their interface structs. Update to
use G_DEFINE_INTERFACE.
Drop NMVpnPluginUiInterfaceProp; it doesn't matter what codes plugin
implementations use for the interface properties that they implement.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
Property notifications are queued during object initialization and
reloading, but the added/removed signals were emitted immediately
even before the object was fully initialized.
Additionally, depending on how long asynchronous initialization took,
the notifications could have been emitted before the object was
fully initialized as deferred_notify_cb() wasn't being suppressed
until all the properties were complete.
For synchronous intialization, signals could be emitted at various
times during initialization and not all of the object's properties
may be read. Furthermore property notifications were queued in an
idle handler, which breaks users that may not use a mainloop. All
signals and notifications should be emitted immediately after
initialization is complete for synchronous initialization.
To make things consistent and ensure that all signals and notifications
are emitted only when initialization is complete, queue signals for
deferred emission and only run notifications/signals when all the
object's properties have been read. For synchronous initialization,
emit all notifications and signals immediately after initialization
and not from an idle handler.
If the operation isn't canceled it returns an error, printing this:
/libnm/client-nm-running:
(/home/dcbw/Development/fdo/NetworkManager/libnm/tests/.libs/lt-test-nm-client:17983): libnm-WARNING **: updated_properties: error reading NMRemoteSettings properties: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
/bin/sh: line 5: 17983 Trace/breakpoint trap ./libnm-test-launch.sh ${dir}$tst
FAIL: test-nm-client
which screws up testcases because they don't expect this message.
And in this case, since libnm knows that NM is exiting and will
just clear out the properties anyway, it's useless to print the message.
A parenthesized comment in nm-dbus-interface.h was being misparsed as
an annotation.
The annotations on NMDhcp4Config:options and NMDhcp6Config:options
were incorrect.
It might simply mean that the object disappeared (which is perfectly fine):
(process:7680): libnm-WARNING **: Could not fetch property 'Vpn' of interface 'org.freedesktop.NetworkManager.Connection.Active' on /org/freedesktop/NetworkManager/ActiveConnection/151: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
https://bugzilla.gnome.org/show_bug.cgi?id=739255
libnm mostly used GPtrArrays in its APIs, except that arrays of
connections were usually GSLists. Fix this and make them GPtrArrays
too (and rename nm_client_list_connections() to
nm_client_get_connections() to match everything else).
Add nm-core-types.h, typedefing all of the GObject types in
libnm-core; this is needed so that nm-setting.h can reference
NMConnection in addition to nm-connection.h referencing NMSetting.
Removing the cross-includes from the various headers causes lots of
fallout elsewhere. (In particular, nm-utils.h used to include
nm-connection.h, which included every setting header, so any file that
included nm-utils.h automatically got most of the rest of libnm-core
without needing to pay attention to specifics.) Fix this up by
including nm-core-internal.h from those files that are now missing
includes.
The new VPN plugin API will hopefully simplify some the the tasks that
are currently handled by nm-vpn-plugin-utils functions, so make those
functions explicitly be part of the "old" API. (If we still want them
in the new API we can just move them back out, and have the "_old_"
versions just be wrappers around the undeprecated ones.)
Rename libnm's NMVpnPlugin to NMVpnPluginOld, in preparation for
having a new-and-improved NMVpnPlugin in NM 1.2. Also remove it from
NM-1.0.gir.
Make nm-vpn-plugin-old.h be separately includable, since it's not
included from NetworkManager.h, and we probably don't want it to be.
Remove NMVpnPlugin, NMVpnPluginUiInterface, and nm-vpn-plugin-utils
from the docs, since they're basically undocumented anyway.
This fixes the /libnm/client-nm-running test failure when a race condition is hit:
test-nm-client:10350): libnm-WARNING **: updated_properties:
error reading NMRemoteSettings properties:
GDBus.Error:org.freedesktop.DBus.Error.NoReply:
Message did not receive a reply (timeout by message bus)
What actually happens is that nm_running_changed_cb() calls GetAll() for a
NMRemoteSettings object when NM appears on the bus. If it disappears shortly
afterwards, another nm_running_changed_cb() is called which suppresses further
object updates, but the original GetAll() might not have finished yet and DBus
will generate a NoReply() response for it. We ought to ignore it.
They require a tty or X11 displays, thus are not suitable for headless runs
(such as in mock). Furthermore, they die with the tty or X11 session, which
is somehow late -- a lot of them may accumulate. Let's kill them right away.
Consolidate NMClientError and NMObjectError (such that there is now
only one libnm-API-specific error domain). In particular, merge
NM_CONNECTION_ERROR_CONNECTION_REMOVED with
NM_OBJECT_ERROR_OBJECT_CREATION_FAILURE as the new
NM_CONNECTION_ERROR_OBJECT_CREATION_FAILED.
Also make object_creation_failed() be a plain method rather than a
signal, since there's no reason for anyone to be connecting to it on
another object. And remove its GError argument because the subclass
can just create its own more-specific error.
Move the definition of NMVpnPluginError to nm-errors and register it
with D-Bus. Rename GENERAL to FAILED, and CONNECTION_INVALID to
INVALID_CONNECTION, for consistency.
(As with the NMSecretAgentError renamings, the renaming here is not an
ABI break, because the daemon currently never checks for any specific
error codes other than INTERACTIVE_NOT_SUPPORTED.)
Move the definition of NMSecretAgentError to nm-errors, register it
with D-Bus, and verify in the tests that it maps correctly.
NM_SECRET_AGENT_ERROR_INTERNAL_ERROR is renamed to
NM_SECRET_AGENT_ERROR_FAILED, and NM_SECRET_AGENT_ERROR_NOT_AUTHORIZED
to NM_SECRET_AGENT_ERROR_PERMISSION_DENIED, for consistency with other
error domains. While NMSecretAgentError, unlike most other error
domains, has always been correctly mapped across D-Bus, the renaming
is not an ABI break, because the daemon never checks for either of
those values, so all versions of the daemon will treat
"org.freedesktop.NetworkManager.SecretAgent.InternalError" and
"org.freedesktop.NetworkManager.SecretAgent.Failed" the same (by just
ignoring the error name and keeping only the error message).
