Change the name of the file where to store the results
of the valgrind run.
Previously the file had a prefix "valgrind-", which is inconvinient.
Instead, have the file using the same name as the test executable,
with a ".valgrind-log" suffix.
When you want to run valgrind for a test, you either had to
invoke valgrind manually, or doing it via `make check` (provided
you configured --with-valgrind).
Make it more convenient to run valgrind by passing the test
to run to the "run-test-valgrind.sh" wrapper.
This also allows to pass -p/-s to the test, which is not possible
during `make check` because selecting tests conflicts with "--tap".
The following invocations are largely equivalent and work as
expected:
$ ./tools/run-test-valgrind.sh ./src/platform/tests/test-link-linux -p /link/software/detect/vlan
$ NMTST_DEBUG=no-debug,p=/link/software/detect/vlan ./tools/run-test-valgrind.sh ./src/platform/tests/test-link-linux
Add a macro to insert the necessary compiler/linker magic to add a
copy of an existing symbol to an older version. Also, update
check-exports.sh to be able to check for such symbols by listed them
commented-out in the appropriate section.
[thaller@redhat.com: patch modified]
Related: https://bugzilla.gnome.org/show_bug.cgi?id=742993
If the valgrind logfile is empty, don't log an error message with
the location of the logfile.
Also, if the test didn't fail due to memleaks, log a different message.
When configuring with --with-valgrind, tests will be invoked
via valgrind. That significantly slows down the tests. Allow
user to set the environment variable NMTST_NO_VALGRIND to invoke
tests directly, even when valgrind was enabled at configure time.
In Python 3, dbus.ByteArray() must be created using a byte string,
while strings obtained via DBUS are unicode strings.
This was wrong in WifiAp.__get_props() which broke the test
test_wifi_ap_added_removed().
File "/usr/lib/python3.3/site-packages/dbus/service.py", line 707, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "./NetworkManager/tools/test-networkmanager-service.py", line 102, in GetAll
return self._get_dbus_properties(iface)
File "./NetworkManager/tools/test-networkmanager-service.py", line 96, in _get_dbus_properties
return self.__dbus_ifaces[iface]()
File "./NetworkManager/tools/test-networkmanager-service.py", line 315, in __get_props
props[PP_SSID] = dbus.ByteArray(self.ssid)
TypeError: string argument without an encoding
https://bugzilla.gnome.org/show_bug.cgi?id=739448
On ppc64, `nm` reports the exported symbols as 'D' instead of 'T'.
This caused `make check` to fail.
"D" The symbol is in the initialized data section.
"T" The symbol is in the text (code) section.
Move the definition of NMSettingsError to nm-errors, register it with
D-Bus, and verify in the tests that it maps correctly.
Remove a few unused error codes, simplify a few others, and rename
GENERAL to FAILED and HOSTNAME_INVALID to INVALID_HOSTNAME, for
consistency.
Merge libnm's NMDeviceError and the daemon's NMDeviceError into a
single enum (in nm-errors.h). Register the domain with D-Bus, and add
a test that the client side decodes it correctly.
The daemon's NM_DEVICE_ERROR_CONNECTION_INVALID gets absorbed into
libnm's NM_DEVICE_ERROR_INVALID_CONNECTION, and
NM_DEVICE_ERROR_UNSUPPORTED_DEVICE_TYPE gets dropped, since it was
only returned from one place, which is now using
NM_DEVICE_ERROR_FAILED, since (a) it ought to be a "can't happen", and
(b) the only caller of that function just logs error->message and then
frees the error without ever looking at the code.
Register NMConnectionError with D-Bus on both sides, so that, eg,
connection validation failures in the daemon will translate to the
correct error codes in the client.
Implement some basic secret agent functionality in
test-networkmanager-service.py, and add test-secret-agent to test that
NMSecretAgent works as expected.
Due to behavioral change of test-networkmanager-service.py, the test
/remote_settings/remove_connection fails (test_remove_connection() at
test-remote-settings-client.c:318).
Fixes: 66a3480329
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since NMRemoteSettings doesn't announce new connections until it has
fetched their properties, it's possible that a connection could get
deleted while we're waiting for it to be created. NMRemoteSettings has
code to deal with this, so add a test to make sure that it works.
test-nm-client.c and test-remote-settings-client.c were using their
own assertion macros so they could kill the test service on assertion
failure. Except that some new code didn't get the memo and used the
g_assert* macros. Not to mention that sometimes the tests would crash
outside of an assertion macro.
We can make test-networkmanager-service.py notice that its parent has
crashed by opening a pipe between them and taking advantage of the
fact that the pipe will be automatically closed if the parent crashes.
So then test-networkmanager-service.py just has to watch for that, and
exit if the pipe closes.
Then that lets us drop the test_assert* macros and just use g_assert*
instead.
Move libnm-glib's test-fake-nm.py and test-remote-settings-service.py
to tools/, merge them together into a single program, and fix a few
bugs (notably some missing signal emissions in the Settings service).
Although they are currently only used by libnm-glib's tests, they are
generic enough that they could be used by other code in the future
(and in particular, they will be used by libnm's tests as well).
Interpret environment variable NMTST_DEBUG which allows
to specify 'sudo-cmd=CMD'. If the test program calls
nmtst_reexec_sudo(), it will `exec CMD "$0" "$@"`.
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.
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.
