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
(cherry picked from commit 4dacf0b1ad)
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
(cherry picked from commit 7bf10a75db)
NetworkManager set wpa_supplicant's fragment_size option to 1300. But if MTU
was lower, wpa_supplicant failed with "l2_packet_send - sendto: Message too
long" due to fragmentation of EAP-TLS or EAP-PEAP packets.
Actually, MTU has to be 14 bytes bigger than the "fragment_size" parameter.
Ideally, wpa_supplicant would take MTU in the account and adjust the
fragmentation limit accordingly. See discussion in
http://lists.shmoo.com/pipermail/hostap/2015-August/033546.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=755145
(cherry picked from commit 94bbe7465f)
Before, the Wi-Fi plugin was always build. Users who didn't want
to use it would simply drop "libnm-device-plugin-wifi.so".
Add a compile time option to disable needlessly building the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=743388
(cherry picked from commit 5439fbd77c)
NM core uses nm-logging which is entirely configurable at runtime.
Other components use glib-logging, which can also be partly configured
via G_MESSAGES_DEBUG.
It makes sense to have a compile time option to enable some
logging statements that are only useful for heavy debugging.
For glib-logging, this is a way to enable/disable extra logging.
For nm-logging, we could alternatively configure a least log-level
that is enabled at compile time (that way, we could configure to prune all
LOGL_TRACE logging). While that might be useful (too), this gives
an alternative way to disable/enable logging.
Add a configure option --enable-more-logging and a NM_MORE_LOGGING define
for that.
If we don't find this useful after a while, we can simply remove it,
because our logging statements are not part of a "stable" behavior.
(cherry picked from commit 63593a19d8)
NM already has two kinds of assertions:
- g_assert*(), conditionally compiled via #ifndef G_DISABLE_ASSERT
- g_return*(), conditionally compiled via #ifndef G_DISABLE_CHECKS
In theory, one should be able to disable both asserts and NM should
still work correctly (and possibly more efficient). In practice,
hardly anybody is testing such a configuration and it might be broken.
Especially, we don't disable asserts for production builds, both because
of less test coverage and because it might reduce our ability to debug.
Add a new configure option --enable-more-asserts, which defines
NM_MORE_ASSERTS and nm_assert(). This is for expensive asserts,
that -- contrary to the asserts above -- are disabled by default.
This is useful for extended debugging.
(cherry picked from commit 08ecafd2bf)
This reverts commit 7daf63461d.
Turns out the removal of the second set of [] in configure.ac causes the command
to be wrong in 'configure' and the test to be incorrect.
First, configure.ac's grep was wrong and wasn't setting DHCPCD_SUPPORTS_IPV6,
which caused dhcpcd to acquire a DHCPv6 address when NM didn't think that
was going to happen, and thus DHCP options couldn't be parsed.
Second, even if that does happen, don't just assert and quit, but set the
DHCP state to failed.
https://bugzilla.gnome.org/show_bug.cgi?id=743700
(cherry picked from commit 511a7395bf)
When specifying '--enable-lto=anything' or '--disable-lto',
the configure script would always set enable_lto=yes.
The only way to disable lto, was *not* specifying the
configure option.
https://bugzilla.gnome.org/show_bug.cgi?id=742575
(cherry picked from commit 6eccfda0fa)
In the 'configure.ac' script we already detect the git commit id
for the current source version. When creating a tarball, it is also
included inside the generated 'configure' script.
Add the commit id as a static string to nm-utils.c. That way, having
a build of libnm.so or NetworkManager, you can quickly find the
corresponding git commit:
strings src/NetworkManager | grep NM_GIT_SHA
Note that this only works after a new `autogen.sh` run. Only rebuilding
is not enough. Hence, you must rebuild all to ensure that the correct
commit id is embedded.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
(cherry picked from commit 924f7b2064)
Takes about 3x as long to build with gcc 4.8, but gcc 4.9
is supposed to speed that up considerably.
Name Before After Saved
-------------------------------------
NetworkManager 1734744 1689728 3%
libnm 1263536 808816 36%
nm-iface-helper 931136 906496 3%
libnm-util 441264 437168 1%
libnm-glib 297064 292960 2%
https://bugzilla.gnome.org/show_bug.cgi?id=741140
docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.
Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.
Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.
https://bugzilla.gnome.org/show_bug.cgi?id=740035
make[5]: Entering directory `./NetworkManager/_build/src/devices/bluetooth'
CC nm-bluez-device.lo
../../../../src/devices/bluetooth/nm-bluez-device.c: In function 'nm_bluez_device_disconnect':
../../../../src/devices/bluetooth/nm-bluez-device.c:430:5: error: "WITH_BLUEZ5_DUN" is not defined [-Werror=undef]
#if WITH_BLUEZ5_DUN
Fixes: f1c9595311
Fixes: 751b52e50b
Signed-off-by: Thomas Haller <thaller@redhat.com>
In case of a missing NetworkManager.conf (or a missing configuration option
main.plugins), allow to determine the fallback at compile time
https://bugzilla.gnome.org/show_bug.cgi?id=738611
Signed-off-by: Thomas Haller <thaller@redhat.com>
This adds service discovery via SDP and RFCOMM tty management to
NetworkManager, as it was dropped from Bluez.
Based on work by Dan Williams <dcbw@redhat.com>.
The SDP discovery is based on code from Bluez project.
