Otherwise, the test generates an "messages.mo" file.
Fixes: 97c1bed37e ('build: add test for valid po files (msgfmt -vc)')
(cherry picked from commit ad55cf86e8)
Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.
Fixes: c056cb9306 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')
(cherry picked from commit bff23d15d4)
When a virtual device fails, its state goes to FAIL and then
DISCONNECTED. In DISCONNECTED we call schedule_activate_check() to
schedule an auto-activation if needed. We also schudule the deletion
of the link through delete_on_deactivate_check_and_schedule(). The
auto-activation attempt fails because the link deletion unmanages the
device; as a result, the device doesn't try to auto-activate again.
To fix this:
- don't allow the device to auto-activate if the device deletion is
pending;
- check again if the device can be auto-activated after its deletion.
https://bugzilla.redhat.com/show_bug.cgi?id=1818697https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/613
(cherry picked from commit e404585e60)
Avoids a compiler warning:
../src/devices/nm-device.c:16079:26: error: cast to smaller integer type 'NMDeviceStateReason' from 'gpointer' (aka 'void *') [-Werror,-Wvoid-pointer-to-enum-cast]
deactivate_ready (self, (NMDeviceStateReason) reason);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 121c58f0c4 ('core: set number of SR-IOV VFs asynchronously')
(cherry picked from commit 918ebd600a)
With Fedora 33, LTO will be enabled by default via CFLAGS in
redhat-rpm-config ([1]).
That basically sets "CFLAGS=-flto -ffat-lto-objects".
Note that we have our own configure/meson option to enable LTO.
With "--with-lto" we set CFLAGS="-flto -flto-partition=none". This
is necessary due ([2], [3]).
So, disable Fedora's automatism, but turn on the suitable configure
option to get working LTO.
[1] 5baaf4a99c
[2] e6cf4213a7 ('build: fix building with LTO')
[3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200#c28
(cherry picked from commit 839ba57c7f)
No amount of _Pragma was able to disable this warning.
In function ‘strncpy’,
inlined from ‘_nm_strndup_a_step’ at ./shared/nm-glib-aux/nm-macros-internal.h:1367:3,
inlined from ‘nms_keyfile_nmmeta_check_filename’ at src/settings/plugins/keyfile/nms-keyfile-utils.c:61:0:
/usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^
src/settings/plugins/keyfile/nms-keyfile-utils.c: In function ‘nms_keyfile_nmmeta_check_filename’:
src/settings/plugins/keyfile/nms-keyfile-utils.c:44: note: length computed here
44 | len = strlen (filename);
|
lto1: all warnings being treated as errors
Oddly enough, gcc is still emitting the warning even with "-Wno-stringop-overflow",
but at least it doesn't break the build.
(cherry picked from commit 407a1f1e98)
nmcli is build with libtool, so "clients/cli/nmcli" is really a shell script
that invokes the real nmcli (at "clients/cli/.libs/nmcli").
When building with LTO for some reasons "clients/cli/nmcli" still
does some build steps during the first invocation.
That means, if we run `make check-local-clients-tests-test-client` it
would first do the final build step. This takes a while, and the test
times out (worse, we do that build step many times in parallel).
Avoid that by invoking "clients/cli/nmcli" first.
(cherry picked from commit 00e3fc036a)
We use a linker version script "NetworkManager.ver", to hide
symbols from NetworkManager that are not used. That is important
due to our habit of using internal helper libraries that we link
statically everywhere, without handpicking the symbols we actually
need. We want the tooling to get rid of unnecessary symbols.
However, NetworkManager loads shared libraries for settings and device
plugins. These libraries require symbols from the NetworkManager binary,
but which one depends on build options. Hence, we also generate
"NetworkManager.ver" by the "tools/create-exports-NetworkManager.sh"
script.
For that the script uses "nm" to find symbols that are undefined in the
plugin libraries but defined in NetworkManager. With autotools the
script looked at "./src/.libs/libNetworkManager.a" to find the present
symbols. Note that for meson that already didn't work, and we build
instead an intermediate NetworkManager binary first (with all symbols
exposed). With LTO, "nm" doesn't find all symbols in
"./src/.libs/libNetworkManager.a", and consequently they are not
exported and dropped/hidden.
This also causes unit tests to fail with LTO, because our test script
"tools/check-exports.sh" catches such bugs.
Fix that by also with autotools generate a complete "NetworkManager-all-sym"
binary that is used to generate "NetworkManager.ver", before rebuilding
"NetworkManager" again.
(cherry picked from commit c92a3ca5c2)
On Debian sid, pygobject no longer builds "python-gobject" for
python2. Still, python2 may be installed and detected preferably
by AM_PATH_PYTHON(). Add workaround.
(cherry picked from commit 54a1cfa973)
The matchfilecon API is deprecated for a very long time. Since selinux 3.1
the functions are also marked as deprecated in the header, which causes
compiler warnings and build failures.
Update the code to use selabel API instead.
(cherry picked from commit 173533c3b2)
Seems with LTO the compiler can sometimes think that thes variables are
uninitialized. Usually those code paths are only after an assertion was
hit (g_return*()), but we still need to workaround the warning.
(cherry picked from commit 70971d1141)
With LTO and optimizations enabled, we get a compiler warning about fd_udp
not initialized:
../src/n-dhcp4-c-connection.c: In function ‘n_dhcp4_c_connection_connect’:
../src/n-dhcp4-c-connection.c:196:13: error: ‘fd_udp’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
196 | r = epoll_ctl(connection->fd_epoll,
| ^
../src/n-dhcp4-c-connection.c:185:16: note: ‘fd_udp’ was declared here
185 | int r, fd_udp;
| ^
6c6e936898
(cherry picked from commit 4e0e002092)
gcc-10.2.1-1.fc32 with optimizations and LTO enabled can think that "len"
is uninitialized. Let packet_recv_udp() always set the length.
../src/n-dhcp4-socket.c: In function ‘n_dhcp4_c_socket_packet_recv.constprop’:
../src/n-dhcp4-incoming.c:210:29: error: ‘len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
210 | incoming->n_message = n_raw;
| ^
../src/n-dhcp4-socket.c:558:16: note: ‘len’ was declared here
558 | size_t len;
| ^
142eedcfc3
(cherry picked from commit 08318a0bac)
Currently, we would not mark non-unicast routes with their type, so they
would wrongly appear as unicast routes in the D-Bus API.
That is wrong. For now, just hide them.
Fixes: 5d0d13f570 ('platform: add support for local routes')
(cherry picked from commit 5035687a7b)
Imagine we wait for a device, the device appears and starts activating.
That might take a while (during which it has a pending action). In the
meantime, the "connection.wait-device-timeout" timeout expires.
Now we want to log a warning about profiles that don't have their
device upon timeout. However, that the device is still busy at that
point is irrelevant. Skip logging a message about those profiles.
Fixes: 3df662f534 ('settings: rework wait-device-timeout handling and consider device compatibility')
(cherry picked from commit d9568ca3ee)
Since commit 3df662f534 ('settings: rework wait-device-timeout
handling and consider device compatibility'), "connection.wait-device-timeout"
works with profiles in general and doesn't require an interface-name
set.
Remove that restriction and let initrd generator create profiles that
always wait.
(cherry picked from commit 52af5e901e)
The network-legacy dracut module waits for all ethernet devices if the
command line contains rd.neednet=1. It also waits for the device
specified by 'bootdev='.
Do the same.
https://bugzilla.redhat.com/show_bug.cgi?id=1853348
(cherry picked from commit f114e16fdd)