"--with test" does two things:
(1) it enables "-Werror" compiler option. We always enable all
compiler warnings we care about, but this option makes all
warnings fatal.
Compiler warnings depend on compiler version and build options.
It's hard to build without any compiler warnings, in particular
for *future* compiler versions which we don't know yet. It
is desirable that a SRPM from yesterday can also be build
tomorrow.
(2) it fails build if any unit tests fail. We always run all
unit tests, but "--with test" makes it fatal. Again, we
have many unit tests that interact with the system (that is,
make system calls, like creating IP addresses or write files).
It is surprisingly hard to get them pass 100% on all the systems
we care. For example, on copr a test setup randomly fails during
ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
nm_utils_ifname_cpy(ifr.ifr_name, TEST_IFNAME);
r = ioctl(fd, TUNSETIFF, &ifr);
It's not clear why, nor is it at all clear that there is a bug
in NetworkManager. Making tests fatal basically means that a build
on copr infrastructure fails with a probability from a few percent.
Enough to be seriously annoying.
Note that on copr we actually build "--with test", because we want to catch these
issues. Likewise for our CI builds we explicitly specify "--with test".
In general, we build with various build configurations (compiler warnings)
and run unit tests on a source package many times. Starting on the
developer machine (`make check`), gitlab-ci, copr builds,
NetworkManager-ci. If you build an SRPM with such sources, a failure
of the unit tests is much more likely a glitch than an actual issue.
This is about changing the default if you build a Fedora/RHEL package.
That is with the Fedora/RHEL packages that are build in koji/brew.
Well, at least usually. In practice, we don't build frequently on non
x64_86 archs, so what I said there is less true. But the package build
is not there to replace CI/testing. The package build is there to get
a (mostly) working binary.
Note that RHEL packages anyway go through rpmdiff too, and rpmdiff
parses the build log and complain if `make check` fails.
This reverts commit e68e5c0a4c.
(cherry picked from commit e23bafe5d5)
nm-cloud-setup is provided by sub-package "NetworkManager-cloud-setup",
which also has the manual page. The main package "NetworkManager" should
not also contain the manual page.
With Fedora 33+ and RHEL 9+, the default plugins are
"plugins=keyfile,ifcfg-rh", instead of "plugins=ifcfg-rh,keyfile".
Update our "NetworkManager.conf" file to reflect that.
"build_clean.sh" (and "build.sh") scripts can both create a source
tarball (via `make dist`/`make distcheck`), an SRPM (and a spec file),
or build RPMs from the SRPM.
Note that the generated spec file has various options, like
%bcond_without nmtui
%bcond_without debug
%bcond_without test
When building an RPM from the SRPM, you can specify the "--with" or
"--without" option for rpmbuild. This is also what the "-w" / "-W" options
for "build_clean.sh" do.
However, the SRPM still has the intrinsic defaults, and if you later
build an RPM from it, you would have to pass "--with" / "--without"
to rpmbuild.
Often that is not conveniently possible, for example, when you build the
SRPM in koji.
Extend the scripts so that also the defaults for "-w debug" and "-w
test" can be specified when generating the SRPM. You can do that with
the new options "--default-for-{debug,test}" to "build_clean.sh".
Alternatively, it suffices to specify the previously supported
"-w" / "-W" options. That way, we will pass those options to rpmbuild,
but also set them as defaults in the generate spec file. The new
options "--default-for-{debug,test}" are only needed if you want
the default in the spec file to be different then what you use
when creating the SRPM.
By default, "build_clean.sh" script likes to automatically add "-w test"
-- unless the user specified "-w test" or "-W test" on the command line.
That is mostly fine. However, the spec file has an internal default for the
"test" option. So if you want to use the default that gets determined
by the spec file, then we should suppress that automatism.
We always run the unit tests during package build and also enable all compiler
warnings. However, by default we used to ignore failures. That is, because
rebuilding a package on another, future distro led to frequent, annoying build
failures. Especially compiler warnings appear easily when using a
different compiler version.
The default mostly matters here when you want to build the package in
brew/koji, where you don't have a possibility to explicitly select the
build option.
Note that rpmdiff detects failures in the build log, and thus we usually
would not miss failures for builds we add to errata. Also, all our CI
tests build packages with a manner where they would not allow a failure
of the unit tests. So, we run these unit tests frequently and in a
manner where we notice a failure.
For rhel-9 builds, change the default here and let test failures and
compiler warnings be fatal to the build.
These packages are also used during CI tests (in the checkpatch
stage). They are also used for formatting C/python code, and thus
useful for developing.
Install them as part of REQUIRED_PACKAGES script.
Add a new `main.rc-manager=auto` setting, that favours to use
systemd-resolved (and not touch "/etc/resolv.conf" but configure
it via D-Bus), or falls back to `resolvconf`/`netconfig` binaries
if they are installed and enabled at compile time.
As final fallback use "symlink", like before.
Note that on Fedora there is no "openresolv" package ([1]). Instead, "systemd"
package provides "/usr/sbin/resolvconf" as a wrapper for systemd-resolved's
"resolvectl". On such a system the fallback to resolvconf is always
wrong, because NetworkManager should either talk to systemd-resolved
directly or not but never call "/usr/sbin/resolvconf". So, the special handling
for resolvconf and netconfig is only done if NetworkManager was build with these
applications explicitly enabled.
Note that SUSE builds NetworkManager with
--with-netconfig=yes
--with-config-dns-rc-manager-default=netconfig
and the new option won't be used there either. But of course, netconfig
already does all the right things on SUSE.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=668153
Suggested-by: Jason A. Donenfeld <Jason@zx2c4.com>
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
This defaults to $DO_RELEASE. In that case, the script will also GPG sign
the source tarball.
The purpose is that when we do a release we want to ensure that the
published tarball is really the one that we generated. In that case,
the SHA sum would suffice, however that requires you to manually note
it down and compare the result. With the gpg signature, that
verification can be better automated.
Currently only "minor" and "devel" releases are implement. It's also not yet
tested with --no-dry-run, because that would actually create a release.
Test it when using it the next time.
