Add gtk-docs for enum types that previously didn't have them.
Explicitly note the relationship between NetworkManager.h /
NetworkManagerVPN.h types and the corresponding introspection/*.xml
types.
Previously, we built a second copy of libnm-glib that was hacked to
use the session bus rather than the system bus, for use by the test
programs. Rather than doing that, just have test-nm-client explicitly
override the choice of bus. (test-remote-settings-client was actually
already doing this, although it leaked the bus after.)
- Remove list of authors from files that had them; these serve no
purpose except to quickly get out of date (and were only used in
libnm-util and not libnm-glib anyway).
- Just say "Copyright", not "(C) Copyright" or "Copyright (C)"
- Put copyright statement after the license, not before
- Remove "NetworkManager - Network link manager" from the few files
that contained it, and "libnm_glib -- Access network status &
information from glib applications" from the many files that
contained it.
- Remove vim modeline from nm-device-olpc-mesh.[ch], add emacs modeline
to files that were missing it.
g-i allows you to specify types in annotations using either their
fully-qualified introspected names (eg, "NMClient.Device") or their
plain C names ("NMDevice"). Switch from the former to the latter (so
that they'll still be correct when migrated to libnm later).
NetworkManager.h, NetworkManagerVPN.h, and nm-version.h are part of
the libnm-util API, so move them to libnm-util.
include/ still contains headers that are strictly NM-internal (eg,
nm-glib-compat.h).
Even if administrator-configured hostname (/etc/hostname) takes precedence
over other hostname configurations, we don't take "localhost", "localhost6",
"localhost.localdomain", "localhost6.localdomain6" as such. These values might
be set by some tools (like installer). But that's not right and we compensate
for that. It doesn't make much sense that an admimistrator would set these
values manually (intentionally), because leaving /etc/hostname empty will
result in "localhost" hostname anyway (set by systemd).
https://bugzilla.redhat.com/show_bug.cgi?id=1110436
Ensure that the @type_funcs and @type_async_funcs
hashes are initialized before running the class
init function.
libnm-glib-scan hits the following assertion:
GLib-CRITICAL **: g_hash_table_insert_internal: assertion 'hash_table != NULL' failed
#0 0x0000003370c504e9 in g_logv (log_domain=0x3370cb2f4e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffd1578f70) at gmessages.c:989
#1 0x0000003370c5063f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007f2169f42545 in _nm_object_register_type_func (base_type=base_type@entry=13597296, type_func=type_func@entry=0x7f2169f47ae9 <_nm_device_type_for_path>, type_async_func=type_async_func@entry=
0x7f2169f47880 <_nm_device_type_for_path_async>) at nm-object.c:551
#3 0x00007f2169f48664 in nm_device_get_type () at nm-device.c:62
#4 0x0000000000402577 in get_object_types () at libnm-glib-scan.c:46
#5 0x0000000000404b0b in main (argc=<optimized out>, argv=<optimized out>) at libnm-glib-scan.c:135
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel adds these for various operations; they are short-lived,
added often, and not useful to NetworkManager. Ignore them. This
prevents NetworkManager from continuously updating the IPv6 config
and emitting state changes to clients via D-Bus for useless changes.
The non-"_t"-suffixed type names in gnutls have been deprecated since
1.x, and in recent versions will trigger deprecation warnings. Fix by
using "gnutls_datum_t" instead of "gnutls_datum".
Quite possibly these logging lines hit before we setup nm-logging
initially and before NM main() calls nm_logging_syslog_openlog().
This is because NM first needs to read the configuration, before setting
up logging.
Note however, that nm-logging is robust against both.
If nm_logging_setup() was not yet called, it will automatically setup
"DEFAULT","INFO".
If nm_logging_syslog_openlog() was not yet called, it will redirect
logging to g_log() -- which basically ends up at g_warning() again.
Still this is useful in case when hitting those lines *afterwards*.
Especially, later when we support reloading of configuration.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Defining G_DEBUG=fatal-warnings is useful for debugging, but it causes
the build to fail due to asserts during vapigen.
Unset G_DEBUG before calling vapigen.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, build_clean.sh always required building all NetworkManager
and doing another `make distcheck` before calling rpmbuild.
That is still a good idea, to ensure that we get a proper build.
For some quick testing however, lets speed this up with a new
--dist argument that only calls `make dist`.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This was added for debugging, but is no longer necessary.
Also, strace might not be installed on any system so don't depend on it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The interface is owned by the parent NMDeviceBt and is not independently
usable. If not ignored, NM tries to assume a connection on the bnep
interface and messes the Bluetooth connection up.
The addition of Bluez5 support mistakenly broke support for Bluez4 property
change events. Bluez4 uses a custom D-Bus interface that we must explicitly
handle.
This caused NM to ignore BT devices immediately after pairing, since the UUIDs
only show up through a custom Bluez4 PropertyChanged even when pairing is
complete. Only then do we finally know priv->capabilities, and only then is
the NMBluezDevice usable.
We only want to treat a veth device as ethernet if (a) NM is running
inside a container, and (b) the veth in question is the "inside" end
of the veth, not the outside. Unfortunately, we don't have good
heuristics for this at the moment, so just ignore veths for now.
https://bugzilla.gnome.org/show_bug.cgi?id=731014
No need to keep references of the singleton and take an additional ref
when accessing nm_firewall_manager_get().
Especially, since the firewall manager instance was nowhere passed in from
externally, it doesn't even sense for some vague testing purporse. Not to
mention, that there are no tests that actually inject a firewall manager stub.
Signed-off-by: Thomas Haller <thaller@redhat.com>
An assertion in nm_dhcp4_config_get_dbus_path() has been actually fixed
by 3d6936b2cc (hopefully for all cases).
But still I think we should check _config here instead of _client.
This functionality is now provided by nm_connection_normalize().
Contrary to nm_utils_normalize_connection(), nm_connection_normalize()
is in libnm-util and available to clients as well.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is the same behaviour as nm_utils_normalize_connection(),
which will soon be removed in favor of nm_connection_normalize().
This takes care, that normal connections always have an IP4 and IP6 setting,
and that slave connections never have it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- Before, when setting the slave-type to an invalid type, the setting
was silently accepted. Now verification fails with "Unknown slave type '%s'"
- Before, the @master property was not checked. So you could have a @slave-type,
without having @master set. And similarly, you could have @master, but
no @slave-type. Fix both issues.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some type-specific NMSetting implementations (bond, bridge, team, vlan)
have their own 'interface-name' property. This property will be
deprecated in favour of 'interface-name' in NMSettingConnection.
Change verify() and normalize() to check that the redundant
values match and repair/normalize the properties.
Force the virtual interface name of the type-specific setting to be
equal to NMSettingConnection:interface_name. This way, the depreacted
field stays valid and backward compatible.
NMSettingInfiniband is special, because it does not have a backing
property for the interface name, although it implements
get_virtual_iface_name(). To account for this, some special handling
is needed in order not to change the behaviour of get_virtual_iface_name().
Signed-off-by: Thomas Haller <thaller@redhat.com>
This function behaves like verify(), but it also performs some
normalization/fixing of inconsistent connections.
Contrary to verify(), this function might modify the settings.
This will be mainly used, to repair connections from older versions
and to fix deprecated options.
Signed-off-by: Thomas Haller <thaller@redhat.com>