This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use g_test_expect_message() in the various daemon-side test programs,
to avoid spewing error messages when (successfully) running "make
check".
The ifnet and ifupdown plugins are extremely verbose, so they were
partially "fixed" by turning down the logging level from INFO to WARN
in those tests.
test-dhcp-options needed to be converted to gtestutils so that the
newly-added check in nm-dbus-manager would recognize it as a test
program and not try to create a private bus.
Remove the PLUGIN_PRINT() and PLUGIN_WARN() macros and use the
standard NM logging functions instead.
Also changed PLUGIN_PRINT("error: ...") to nm_log_warn("...") in
places.
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.
Keyfile plugin writer had a bug, when writing IP6 routes with gateway
"::". Instead of writing "net/plen,,metric" it wrote "net/plen,metric".
- fix this bug and add test cases. Also, add a workaround to reader, to
accept such wrongly written IP6 routes as valid.
- change the writer for IP4 addresses, IP4 routes and IP6 routes to
omit the gateway and the metric, if it is 0.0.0.0/::/0, respectively.
Also change the reader, to accept such empty gateway as valid.
It only omits the gateway, if the metric is not 0, this means it would
write:
route1=1.2.3.4/24,0.0.0.0,1
instead of
route1=1.2.3.4/24,,1
Both representations are now supported by the reader, but older plugin
versions could only read the former (thus, we keep writing that
version).
With a metric of zero, it would instead write:
route1=1.2.3.4/24
- some refactoring and code cleanup. Fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=719851
Signed-off-by: Thomas Haller <thaller@redhat.com>
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
Settings with all-default values are not written to reduce
complexity of the keyfile (and be more human-readable friendly)
and that includes VLAN settings with a VLAN ID of zero. So
when reading this file back, if there is no 'base type' setting
(eg, the setting specified by the connection::type property)
then just add that setting. nm_connection_verify() will catch
cases where an empty 'base type' setting is invalid.
Add these aliases for the setting names '802-3-ethernet',
'802-11-wireless', and '802-11-wireless-security' and write them by
default. It's much friendlier for administrators to type, and a lot
less ugly.
Also works for:
[connection]
type=ethernet
test-keyfile.c: In function 'test_read_string_ssid':
test-keyfile.c:1154:51: error: argument to 'sizeof' in 'memcmp' call is the
same expression as the second source; did you mean to provide an explicit
length? [-Werror=sizeof-pointer-memaccess]
ASSERT (memcmp (array->data, expected_ssid, sizeof (expected_ssid)) == 0,
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
Use --enable-doc and --enable-tests instead of --with-docs and
--with-tests. This is consistent with other features and with
--enable-gtk-doc option. Support current variants as fallback.
Don't build tests unless --enable-tests is specified.
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
The regex was capturing integers larger than 3 digits, which aren't
valid SSID integer list items because each byte of the SSID cannot be
larger than 255. Add an explicit testcase for intlist SSIDs too.
The previous regex was causing a testcase failure with an SSID of
'1337' which it was interpreting as a single element intlist, but
should have been interpreted as a string since it's clear > 255.
The keyfile code has to handle a few different formats of cert/key values,
and wasn't doing a good enough job of detecting plain paths as values. By
default the writer will write out a plain path (ie, not prefixed with file://)
and the reader will handle that correctly, *unless* that file does not
exist, at which the reader assumed it was a byte array. This caused the
read-in keyfile not to match the in-memory connection (since the in-memory
connection though the cert/key held a path, but the read-in one thought it
contained a blob) and this seems to eventually have triggered a write-out
with the new values (as a blob), which would then drop a .pem file into
system-connections/ containing the path that should have been in the
keyfile in the first place.
This all happened because we assumed that the given path for the cert or
key would actually be valid, which doesn't seem to be the case for a lot
of people. Clearly these connections won't work (since the certificate or
key does not exist) but the keyfile plugin shouldn't be messing up the
connection's settings at the very least.
Fix that by handling the check of whether the cert/key data is a path or
not in a less restrictive manner and add some testcases to make sure that
everything works as we expect.
If the cert/key path is relative to the keyfile then don't
bother writing the absolute path out. This also prevents the
keyfile plugin from rewriting a relative path to an absolute one,
preventing some annoyance for people that hand-edit keyfiles.
Passing a relative path to wpa_supplicant does no good since the supplicant
may not have the same working directory as NetworkManager. Relative paths
used in keyfiles are assumed to be relative to the keyfile itself anyway,
so actually use the absolute path we compute for the cert/key instead of
leaving it relative.
