Since commit a447942fc0 ('contrib/rpm: rename package
"NetworkManager-config-routing-rules" to
"NetworkManager-dispatcher-routing-rules"'), the config-routing-rules
subpackage is gone.
This way to specify the version number with a variable parameter, causes
repeated messages in rpmdiff:
INFO NetworkManager-dispatcher-routing-rules changed from Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.2.el8 to Obsoletes: NetworkManager-config-routing-rules < 1:1.32.0-0.3.el8 on noarch
Avoid this by hard coding the obsoleted version.
This "Conflicts" is since commit b85b8ed6fa ('contrib/rpm: let
NetworkManager-libnm and NetworkManager-glib of differing version
conflict'). This was probably fine back then, but NetworkManager-glib is
long gone.
Also, not hard coding the version number leads to rpmdiff messages like:
NEEDS INSPECTION NetworkManager-libnm changed from Conflicts: NetworkManager-glib < 1:1.32.0-0.2.el8 to Conflicts: NetworkManager-glib < 1:1.32.0-0.3.el8 on all architectures
As NetworkManager-glib is long gone, hard code the version with which
we conflict.
On Fedora 33, we get it automatically because "clang" package
has an indirect (weak) dependency for clang-tools-extra. On
Fedora 34, that is no loger the case.
We need to explicitly install it.
When supported by the D-Bus daemon, it's better to have service files
in /usr rather than in /etc. Change the path for RHEL 8.
See also commit ef8c292881 ('contrib/rpm: install D-Bus service
files to /usr if we can').
We should write our CONTRIBUTING files in markdown syntax, because
it's nice to read a plain text and gets nicely rendered.
However, if the file doesn't have a ".md" extension, gitlab's
web interface shows it as plain text file.
Rename the file.
This possibly breaks links like [1], but referring to a branch name
(and not a commit ID or a tag) is anyway fragile. Hence, I don't try
to fix that by adding a symlink or similar, because I think that just
makes it more confusing.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/CONTRIBUTING
"--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.
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
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.
- accept directory names in the command line. In that case,
still honor the excluded files. That is a major improvement
for me, because I usually only want to reformat a directory
that I know has changed and it is fast to only process some
directories.
- pass all files at once to clang-format. For me that gives
a significant speed improvement (about 3 times faster), although
clang-format is only single threaded. Possibly clang-format could
even be faster by checking files in parallel.
In case of a style error, the script still falls back to
iterate over all files to find the first bad file and print
the full diff. But that is considered an unusual case.
- make it correctly work from calling it from a subdirectory.
In that case, we only check files inside that directory --
but still correctly honor the excluded files.
"shared/nm-std-aux/unaligned.h" is taken from systemd and frequently
re-imported via the "systemd" branch.
It is not our code, and should not be formatted with our clang-format.
Alpine is especially interesting because it uses musl as libc.
The build does not yet succeed. There are several issues that
need to be fixed.
However, it will be simpler to fix things, if we have tests
in place -- even if at the moment they are known to be broken.
See-also: https://git.alpinelinux.org/aports/tree/community/networkmanager?h=master
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.