Surisingly, the compiler may detect the remaining obj_type in
the default switch. Then, inlining nmp_class_from_type() it may detect
that this is only possible to hit with an out or range access to
_nmp_classes array.
Rework the code to avoid that compiler warning. It's either way not
supposed to happen.
Also, drop the default switch case and explicitly list the enum values.
Otherwise it is error prone to forget a switch case.
(cherry picked from commit 9848589fbf)
(cherry picked from commit 6f189da7b6)
(cherry picked from commit 6da20c24cd)
Otherwise, we get test failures with valgrind on fedora:rawhide
(valgrind-3.15.0-18.fc33.x86_64.rpm, gcc-10.0.1-0.8.fc33.x86_64,
glib2-devel-2.63.5-3.fc33.x86_64):
>>>> PRINT VALGRIND LOGS (valgrind test) (start)
+ find -name '*.valgrind-log' -print0
+ xargs -0 grep -H '^'
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- WARNING: unhandled amd64-linux syscall: 315
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- You may be able to write your own handler.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Nevertheless we consider this a bug. Please report
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- You may be able to write your own handler.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-secret-agent.valgrind-log:--95280-- You may be able to write your own handler.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-secret-agent.valgrind-log:--95280-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-nm-client.valgrind-log:--95208-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-nm-client.valgrind-log:--95208-- You may be able to write your own handler.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-nm-client.valgrind-log:--95208-- it at http://valgrind.org/support/bug_reports.html.
+ echo '>>>> PRINT VALGRIND LOGS (valgrind test) (done)'
>>>> PRINT VALGRIND LOGS (valgrind test) (done)
(cherry picked from commit 3e616c306d)
(cherry picked from commit a9372112b9)
(cherry picked from commit 4fb9f98bc6)
The client tests compare the test output with a .expected file that is
commit to git and that contains the expected output.
The expected output contains data like
size: 395
location: clients/tests/test-client.py:842:test_001()/1
cmd: $NMCLI
lang: C
returncode: 0
stdout: 277 bytes
>>>
...
Note that there is the line number (clients/tests/test-client.py:842) of
the source code where nmcli is called. This is to help correlate the output
with the test code.
However, Python 3.8 changes behavior and for function calls that span multiple
lines, frame.f_lineno will give now the starting line (previously, it gave the last
line) (see [1]).
No longer include the line number, as it is not stable accross Python versions.
If you really care, you can set NM_TEST_WITH_LINENO to get the line numbers back.
Of course, then the expected output won't match anymore, and you'd have to regenerate
it first. This is only useful if you debug tests, and want to have it easier to
correlate output with the tests while developing them.
[1] https://bugs.python.org/issue38283https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/292
(cherry picked from commit ad3ef326aa)
(cherry picked from commit 275a7c46a1)
It's unclear how to workaround this issue, so that the tests
work with older python versions and 3.8-beta.
Let's wait whether this will really be released as 3.8 and
for now just skip the test.
(cherry picked from commit d7b9906666)
(cherry picked from commit 460ed8112f)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘nmp_utils_ethtool_get_permanent_address’:
src/platform/nm-platform-utils.c:854:29: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u8[0]’ {aka ‘unsigned char[0]’} [-Werror=zero-length-bounds]
854 | if (NM_IN_SET (edata.e.data[0], 0, 0xFF)) {
./shared/nm-glib-aux/nm-macros-internal.h:731:20: note: in definition of macro ‘_NM_IN_SET_EVAL_N’
Fix this warning.
(cherry picked from commit d892a35395)
(cherry picked from commit c1417087c8)
(cherry picked from commit f7b9d06306)
GCC 10 complains about accesses to elements of zero-length arrays that
overlap other members of the same object:
src/platform/nm-platform-utils.c: In function ‘ethtool_get_stringset’:
src/platform/nm-platform-utils.c:355:27: error: array subscript 0 is outside the bounds of an interior zero-length array ‘__u32[0]’ {aka ‘unsigned int[0]’} [-Werror=zero-length-bounds]
355 | len = sset_info.info.data[0];
| ~~~~~~~~~~~~~~~~~~~^~~
In file included from src/platform/nm-platform-utils.c:12:
/usr/include/linux/ethtool.h:647:8: note: while referencing ‘data’
647 | __u32 data[0];
| ^~~~
Fix this warning.
(cherry picked from commit 16e1e44c5e)
(cherry picked from commit 286bb2f029)
(cherry picked from commit b474ed0044)
curl_multi_setopt() accepts CURLMOPT_* options, not CURLOPT_*
ones. Found by GCC 10:
clients/cloud-setup/nm-http-client.c:700:38: error: implicit conversion from ‘enum <anonymous>’ to ‘CURLMoption’ [-Werror=enum-conversion]
700 | curl_multi_setopt (priv->mhandle, CURLOPT_VERBOSE, 1);
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
(cherry picked from commit c11ac34f4c)
(cherry picked from commit 7ba2040caa)
(cherry picked from commit fb4d8705dd)
Building with GCC 10 gives the following error:
multiple definition of_nm_jansson_json_object_iter_key';
libnm/.libs/liblibnm.a(libnm_core_la-nm-json.o):/builddir/build/BUILD/NetworkManager-1.23.1/libnm-core/nm-json.c:24: first defined here /usr/bin/ld:
libnm/.libs/liblibnm.a(libnm_core_la-nm-team-utils.o):/usr/include/jansson.h:202: multiple definition of _nm_jansson_json_object_iter';
This happens because GCC 10 defaults to -fno-common and so multiple
definitions of the same global variable are not merged together.
_nm_jansson_json_* symbols are defined in nm-json.c as void pointers
and, due to the following macros in nm-json.h:
#define json_object_iter_next (*_nm_jansson_json_object_iter_next)
...
the function declaration in jansson.h:
void *json_object_iter_next(json_t *object, void *iter);
becomes a global variable as well:
void *(*_nm_jansson_json_object_iter_next)(json_t *object, void *iter);
So, the symbol is present in nm-json.o and all other object files that
include nm-json.h, and -fcommon is required. Without it, it would be
necessary to define the symbols only in one place (for example,
nm-json.c), but then static inline functions from the jannson.h header
would still refer to the original (missing) jansson functions.
For the moment, just use -fcommon.
(cherry picked from commit d2d6a68697)
(cherry picked from commit 311872ddca)
(cherry picked from commit 5d797b91e4)
Meson 0.54.0 requires ninja-1.7 ([1]).
On Ubuntu 16.04, we now would get meson 0.54.0 via pip3, but ninja-1.5.1 via
apt. That doesn't work anymore.
We could install ninja via pip3, but of course, doing that on other
Debian/Ubuntu versions fails due to ... I don't even want to know.
So, instead use an old meson version on Ubuntu 16.04, which is
known to still work with the ninja provided by the packaging system.
We anyway don't want to test the same meson/ninja versions on all our
Ubuntu/Debian images. The point of having different images is to build
with different software versions. If `pip3 install` gives us the same
everywhere, it isn't very useful.
https://mesonbuild.com/Release-notes-for-0-54-0.html#ninja-version-requirement-bumped-to-17
(cherry picked from commit 5feba97cd1)
(cherry picked from commit b9b00a1cb3)
(cherry picked from commit 3199349196)
Otherwise, installing a package might prompt for the user to type something,
breaking the CI build.
(cherry picked from commit 571786c211)
(cherry picked from commit b033ab8449)
(cherry picked from commit e79ce721d3)
Fixes: ec8068ec0c ('gitlab-ci: add "t_fedora:32" and by default build on Fedora 31')
(cherry picked from commit f12b830a94)
(cherry picked from commit 5abb14611b)
(cherry picked from commit c553c2ff3f)
For the moment, we use docker images from dockerhub, which require
a lot of extra overhead to prepare and install the test environment.
This should be improved, by using more suitable container images.
Anyway, for now to alleviate the pressure on the freedesktop gitlab
infrastructure, disable most test to only run manually.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/241#note_282521
(cherry picked from commit b733d477e8)
(cherry picked from commit 962297f908)
In continations (that use spaces for alignment), don't allow the number
of leading tabs to change. Previously only removal of tabs was
disallowed, but addition doesn't make sense either, as only spaces
should be used for further alignemnt.
This catches situations like this:
|<-tab->all_work_and_no_play (makes,
|<-tab-> jack,
|<-tab-><-tab-> a dull boy);
(cherry picked from commit da312e6220)
It doesn't have to be at the end of line, there may be more words
following.
Fixes: d66a1ace23 ('contrib/checkpatch: avoid command injection in checkpatch.pl script')
(cherry picked from commit f3f8e21bd3)
These packages no longer exist on Fedora 32 and dnf fails due to
that. Ignore such errors.
(cherry picked from commit bdd45e6afa)
(cherry picked from commit 27664ff425)
(cherry picked from commit e573f77855)
`which` is convenient, but not installed in Fedora container images.
Fix detection of whether to use `dnf` or `yum`.
(cherry picked from commit 5cc8ca4038)
(cherry picked from commit 68fa338e34)
(cherry picked from commit ceb602cab1)
"wireless-tools-devel" is long depreacted and not used by
NetworkManager, not even for WEXT.
Drop it from the build dependencies.
(cherry picked from commit 9fc4490513)
(cherry picked from commit 35a2a71801)
Plugins also may use nmtst_*() functions (when built with --with-more-asserts)
or c_list_*(). Whitelist them too.
(cherry picked from commit 7b6f1c2d90)
Otherwise, the script tries to run
dbus-run-session -- exec ...
which fails (because `exec` is a shell command, not a program).
After the failure, the code falls through to run the test under
valgrind.
Fixes: 6a58c55ca4 ('run-nm-test: Just use exec instead of running and exiting')
(cherry picked from commit b9c4d2bb72)
(cherry picked from commit af4671cda0)
When a test is going to be run under valgrind we set NM_TEST_UNDER_VALGRIND
so that we can properly check whether this is happening.
(cherry picked from commit 073eda68fc)
(cherry picked from commit 963ff8c2ab)
error: bare words are no longer supported, please use "...": no != "yes"
error: ^
error: /builds/NetworkManager/NetworkManager/contrib/fedora/rpm/NetworkManager.20200418-170120.dp5cp5/SPECS/NetworkManager.spec:596: bad %if condition: no != "yes"
(cherry picked from commit ed94ab6e23)
(cherry picked from commit 1667be7cf5)
(cherry picked from commit 719d492f4a)
(cherry picked from commit 71d4e261f6)
error: bare words are no longer supported, please use "...": no != yes
error: /builds/NetworkManager/NetworkManager/contrib/fedora/rpm/NetworkManager.20200418-163008.VM582H/SPECS/NetworkManager.spec:596: bad %if condition: no != yes
(cherry picked from commit be78a12012)
(cherry picked from commit c869d792a2)
(cherry picked from commit 5735e267cd)
(cherry picked from commit 3fcc337770)
warning: extra tokens at the end of %endif directive in line 717: %endif # end autotools
warning: extra tokens at the end of %endif directive in line 775: %endif # end autotools
(cherry picked from commit 0521e06ff1)
(cherry picked from commit 43aa1f7ff1)
Why "if (length > G_MAXUINT)"? This is never going to hit. Also,
we probably should actual missing keys handle differently from
empty lists. If @error is set, return without setting the property.
(cherry picked from commit 2cf31bfef0)
(cherry picked from commit f00d306ae7)
(cherry picked from commit cd33ea1fc0)
(cherry picked from commit e1acac6311)
g_key_file_get_integer_list() can return %NULL without setting an error.
That is the case if the key is set to an empty value.
For X sake, this API. Read the documentation and figure out whether
the function can return %NULL without reporting an error.
Anyway, avoid the assertion failure.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/412
(cherry picked from commit 8f46425b11)
(cherry picked from commit 97139f5e3d)
(cherry picked from commit 59d488cb46)
(cherry picked from commit b82a8e4e01)
If a device is being autoactivated and requires a parent that is
blocked due to user request, the autoactivation attempt should fail
because NM shouldn't overrule the user decision.
https://bugzilla.redhat.com/show_bug.cgi?id=1765566
(cherry picked from commit f2dbf8fbc0)
(cherry picked from commit 61d431a9e8)
(cherry picked from commit 74649429df)
g_ascii_strtoull() returns a guint64, which is very wrong to directly pass
to the variadic argument list of g_object_set(). We expect a guint there
and need to cast.
While at it, use _nm_utils_ascii_str_to_int64() to parse and validate the input.
(cherry picked from commit d506823d4f)
(cherry picked from commit 24177569c1)
(cherry picked from commit 0a10468d79)
error: bare words are no longer supported, please use "...": "x" != x
error: ^
error: /root/nm-build/NetworkManager/contrib/fedora/rpm/NetworkManager.20200402-030113.Hk7EGs/SPECS/NetworkManager.spec:32: bad %if condition: "x" != x
ERROR: rpmbuild FAILED
(cherry picked from commit 68b38a09d1)
(cherry picked from commit 045194760e)
(cherry picked from commit 477c6c3e70)
We try to set only one time the MTU from the connection to not
interfere with manual user changes.
If at some point the parent interface changes temporarily MTU to a
lower value (for example, because the connection was reactivated), the
kernel will also lower the MTU on child interface and we will not
update it ever again.
Add a workaround to this. If we detect that the MTU we want to set
from connection is higher that the allowed one, go into a state where
we follow the parent MTU until it is possible to set again the desired
MTU. This is a bit ugly, but I can't think of any nicer way to do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1751079
(cherry picked from commit ec28f5b343)
(cherry picked from commit 49857ed279)
A MACsec connection doesn't have an ordering dependency with its
parent connection and so it's possible that the parent gets activated
later and sets a greater MTU than the original one.
It is reasonable and useful to keep the MACsec MTU configured by
default as the maximum allowed by the parent interface, that is the
parent MTU minus the encapsulation overhead (32). The user can of
course override this by setting an explicit value in the
connection. We already do something similar for VLANs.
https://bugzilla.redhat.com/show_bug.cgi?id=1723690
(cherry picked from commit 438a0a9ad5)
(cherry picked from commit c58ce8945d)
