Like done for autotools. First we run the test without debugging option.
If it fails, we run it again to possibly trigger the failure again and
get better logs.
"debug" is implied when setting NMTST_DEBUG, but not specifying
"no-debug". This change has thus no effect, but it seems clearer to be
explicit.
The "debug" flag affects nmtst_is_debug(). Note that tests *must* not
result in different code paths based on debug, they may only
1) print more debug logging
2) do more assertion checks.
Having more assertion checks can result in different outcome of the
test, that is, that the additional assertion fails first. That is
acceptable, because failing earlier is possibly closer to the issue and
helps debugging. Also, when the additional failure is fixed and passes,
we still will fail at the assertion we are trying to debug.
In particular, an access to nmtst_get_rand*()/nmtst_rand*() must not
depend on nmtst_is_debug(), because then different randomized paths
are taken based on whether debugging is enabled.
The code was just wrong. Usually in gitlab-ci, NMTST_SEED_RANDOM is
unset, so the previous code would not have set it. Which means that our
tests run with NMTST_SEED_RANDOM="0".
Fuzzing (or randomizing tests) is very useful, we should do that for the
unit tests that run in gitlab-ci. Fix this.
But don't let the test choose a random number. Instead, let the calling
script choose it. That is, because we might run the tests more than once
(without debugging and no valgrind; in case of failure return with
debugging; with valgrind). Those runs should use the same seed.
This fixes commit 70487d9ff8 ('ci: randomize tests during our CI'),
but as fixing randomization can break previously running tests, we may
only want to backport this commit after careful evaluation.
Seems this test fails easily under gitlab-ci, if we set NMTST_SEED_RAND
to something else than "0". There is nothing particular special about
"0", except that a randomly different code paths are chosen.
A randomized test that doesn't pass on all systems with all random
paths, is broken. Disable for now. Needs to be fixed.
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=2165141
We must trust l3cfg when generating dependent onlink routes for all kind
of routes not default routes only. This was done by
"nm_platform_ip_route_sync()" so there is not change in behaviour at
all.
"nm_platform_ip_route_sync()" could be needed for other situation where
l3cfg cannot add the dependent onlink routes, so we are not removing
that logic.
This reverts commit 6b4123db1c.
Currently, the use of [global-dns] section for setting DNS options is
conditioned on presence of a nameserver in a [global-dns-domain-*] section.
Attempt to use the section for options alone results in an error:
[global-dns]
options=timeout:1
Or via D-Bus API:
# busctl set-property org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager \
GlobalDnsConfiguration 'a{sv}' 2 \
"options" as 1 "timeout:1" \
"domains" a{sv} 0
...
Nov 24 13:15:21 zmok.local NetworkManager[501184]: <debug> [1669292121.3904]
manager: set global DNS failed with error: Global
DNS configuration is missing the default domain
The insistence on existence of [global-dns-domain-*] would make sense if
other [global-dns-domain-...] sections were present.
However, the user might only want to set the options in resolv.conf and
still use connection-provide nameservers for the actual resolving.
Lift the limitation by allowing the [global-dns] to be used alone, while
still insist on [global-dns-domain-*] being there in presence of other
domain-specific options.
https://bugzilla.redhat.com/show_bug.cgi?id=2019306
(cherry picked from commit 1f0d1d78d2)
This effectively makes [*global-dns-domain-*] sections in configuration be
ignored unless [*global-dns] is also present. This happens because
nm_config_keyfile_has_global_dns_config() mixes the group names up and
attempts to loop up [.intern.global-dns-domain-*] in user configuration and
[global-dns-domain-*] in the internal one.
Fixes: da0ded4927 ('config: drop global-dns.enable option in favor of .config.enable')
(cherry picked from commit de1c06daab)
We silently tolerate NetworkManager not responding at all (easily
reproduced with e.g. pkill -STOP NetworkManager):
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[23540]: <debug> [3316.81989] nmclient[ddafb84b8deebe4a]: new NMClient instance
libnm-dbus[23540]: <debug> [3316.81998] nmclient[ddafb84b8deebe4a]: starting async initialization...
libnm-dbus[23540]: <debug> [3316.82461] nmclient[ddafb84b8deebe4a]: name owner changed: (null) -> ":1.2"
libnm-dbus[23540]: <debug> [3316.82464] nmclient[ddafb84b8deebe4a]: fetch all
libnm-dbus[23540]: <debug> [3341.85715] nmclient[ddafb84b8deebe4a]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[23540]: <debug> [3341.85740] nmclient[ddafb84b8deebe4a]: async init complete with success
Error: dummy666 - no such connection profile.
libnm-dbus[23540]: <debug> [3341.86723] nmclient[ddafb84b8deebe4a]: release all
libnm-dbus[23540]: <debug> [3341.86798] nmclient[ddafb84b8deebe4a]: disposed
$
As a comment in _dbus_get_managed_objects_cb() explains, this is sort of
intentional. NetworkManager might just be shutting down and the libnm
users will eventually see the objects once a new daemon starts up.
This may make some sense for long-running clients ("nmcli monitor",
various desktop environments), but not for one-shot invocations that
require the daemon running, such as those of "nmcli c ...".
Let's not consider the client running unless we actually got the manager
object. That way the error message will make more sense:
$ LIBNM_CLIENT_DEBUG=trace nmcli c show dummy666
libnm-dbus[24730]: <debug> [5360.95480] nmclient[8cb898d3c891e210]: new NMClient instance
libnm-dbus[24730]: <debug> [5360.95487] nmclient[8cb898d3c891e210]: starting async initialization...
libnm-dbus[24730]: <debug> [5360.95901] nmclient[8cb898d3c891e210]: name owner changed: (null) -> ":1.2"
libnm-dbus[24730]: <debug> [5360.95904] nmclient[8cb898d3c891e210]: fetch all
libnm-dbus[24730]: <debug> [5385.98487] nmclient[8cb898d3c891e210]: GetManagedObjects() call failed: Timeout was reached
libnm-dbus[24730]: <debug> [5385.98497] nmclient[8cb898d3c891e210]: async init complete with success
Error: NetworkManager is not running.
libnm-dbus[24730]: <debug> [5385.98571] nmclient[8cb898d3c891e210]: release all
libnm-dbus[24730]: <debug> [5385.98698] nmclient[8cb898d3c891e210]: disposed
$
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1502
Currently, the use of [global-dns] section for setting DNS options is
conditioned on presence of a nameserver in a [global-dns-domain-*] section.
Attempt to use the section for options alone results in an error:
[global-dns]
options=timeout:1
Or via D-Bus API:
# busctl set-property org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager org.freedesktop.NetworkManager \
GlobalDnsConfiguration 'a{sv}' 2 \
"options" as 1 "timeout:1" \
"domains" a{sv} 0
...
Nov 24 13:15:21 zmok.local NetworkManager[501184]: <debug> [1669292121.3904]
manager: set global DNS failed with error: Global
DNS configuration is missing the default domain
The insistence on existence of [global-dns-domain-*] would make sense if
other [global-dns-domain-...] sections were present.
However, the user might only want to set the options in resolv.conf and
still use connection-provide nameservers for the actual resolving.
Lift the limitation by allowing the [global-dns] to be used alone, while
still insist on [global-dns-domain-*] being there in presence of other
domain-specific options.
https://bugzilla.redhat.com/show_bug.cgi?id=2019306
This effectively makes [*global-dns-domain-*] sections in configuration be
ignored unless [*global-dns] is also present. This happens because
nm_config_keyfile_has_global_dns_config() mixes the group names up and
attempts to loop up [.intern.global-dns-domain-*] in user configuration and
[global-dns-domain-*] in the internal one.
Fixes: da0ded4927 ('config: drop global-dns.enable option in favor of .config.enable')
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
Fixes: 096b9955d6 ('contrib/fedora: make "lto" in the spec file configurable')
Fixes: 7a62845424 ('contrib/rpm: fix condition in "NetworkManager.spec"')
When we build a copr image, we run the "nm-copr-build.sh" script.
That script, should honor "LTO=0|1|" to explicitly enable/disable
LTO. Since the copr script only builds a SRPM, which then gets build
we need that the default LTO flag in the SRPM is templated.
Fixes: 0566e9dc63 ('contrib: support disabling "LTO" in "nm-copr-build.sh"')
The "nm-copr-build.sh" script is run by our copr to generate the SRPM of
NetworkManager (via `curl ... | bash`).
Building with LTO takes a long time, for testing it can be nice to disable
that. Add an environment variable for that. It can be used when manually
building an RPM in copr.
With the meson build configuration, there is obviously python3 installed
and in the path. The build script will pick that up as preferred python.
However, we will also need working pygobject to build the documentation.
But we only have that for python2 installed. Fix that, by installing
"python36-gobject".
We have "BuildRequires: ppp-devel". While in Fedora 37 that has a
dependency on "ppp" package, that is not the case on Centos7. I didn't
test others, but the point is it's not always there.
"/usr/sbin/pppd" is provided by "ppp" package, and we might not have it
installed via the build requirements. But we only need it to detect the
path, which is not necessary on RHEL/Fedora. Just set the path
explicitly with the respective configure option.
It is possible that an ra leads to two routes having
the same prefix as well as the same prefix length.
One of them, however, refers to the on-link prefix,
and the other one to a route from the route information field.
(Moreover, they might have different route preferences.)
Hence, if both routes differ in the on-link property,
both are added, and the route from the route information
option receives a metric penalty.
Fixed#1163.
(cherry picked from commit 11832e2ba3)
It is possible that an ra leads to two routes having
the same prefix as well as the same prefix length.
One of them, however, refers to the on-link prefix,
and the other one to a route from the route information field.
(Moreover, they might have different route preferences.)
Hence, if both routes differ in the on-link property,
both are added, and the route from the route information
option receives a metric penalty.
Fixed#1163.
Obviously, it would be nice if our unit tests are fast. However, with
valgrind and a busy machine, some of the tests can take a relatively
long time. In particular those, that are marked as "slow" (if you want
to skip them during development, do so via "NMTST_DEBUG=quick"
environment, or "CFLAGS=-DNMTST_TEST_QUICK=TRUE", see
"nm-test-utils.h").
Anyway. Our tests almost never hit the timeout, and if they do, the most
likely reason is that something was just slower then expected, and the
timeout is a bogus error.
Timeouts only act as last fail safe. It more important to avoid a false
(premature) timeout failure, than to minimize the wait time when the
test really hangs. Because a real hang is a bug anyway, that we will
discover and need to fix.
Increase the default test timeout for meson tests to 3 minutes.
Also, "test-route-linux" is known to take a long time. Increase that
timeout even further.
