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.
NM-ci wants to install a lot of packages when running the first test.
In particular, NM-ci has no nice script that lists all the dependencies,
so it's not immediately clear which packages are required.
Still, install some of those packages so that they are already present
when running the first NM-ci test.
python-setuptools is now gone from debian:testing ([1], [2]):
Package python-setuptools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'python-setuptools' has no installation candidate
This package is entirely optional. Fix the failure by ignoring any failure to
install the package.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938168
[2] https://tracker.debian.org/news/1391360/python-setuptools-removed-from-testing/
This is the version shipped in Fedora 37. As Fedora 37 is now out, the
core developers switch to it. Our gitlab-ci will also use that as base
image for the check-{patch.tree} tests and to generate the pages. There
is a need that everybody agrees on which clang-format version to use,
and that version should be the one of the currently used Fedora release.
Also update the used Fedora image in "contrib/scripts/nm-code-format-container.sh"
script.
The gitlab-ci still needs update in the following commit. The change
in isolation will break the "check-tree" test.
Cleanup the handling of close().
First of all, closing an invalid (non-negative) file descriptor (EBADF) is
always a serious bug. We want to catch that. Hence, we should use nm_close()
(or nm_close_with_error()) which asserts against such bugs. Don't ever use
close() directly, to get that additional assertion.
Also, our nm_close() handles EINTR internally and correctly. Recent
POSIX defines that on EINTR the close should be retried. On Linux,
that is never correct. After close() returns, the file descriptor is
always closed (or invalid). nm_close() gets this right, and pretends
that EINTR is a success (without retrying).
The majority of our file descriptors are sockets, etc. That means,
often an error from close isn't something that we want to handle. Adjust
nm_close() to return no error and preserve the caller's errno. That is
the appropriate reaction to error (ignoring it) in most of our cases.
And error from close may mean that there was an IO error (except EINTR
and EBADF). In a few cases, we may want to handle that. For those
cases we have nm_close_with_error().
TL;DR: use almost always nm_close(). Unless you want to handle the error
code, then use nm_close_with_error(). Never use close() directly.
There is much reading on the internet about handling errors of close and
in particular EINTR. See the following links:
https://lwn.net/Articles/576478/https://askcodes.net/coding/what-to-do-if-a-posix-close-call-fails-https://www.austingroupbugs.net/view.php?id=529https://sourceware.org/bugzilla/show_bug.cgi?id=14627https://news.ycombinator.com/item?id=3363819https://peps.python.org/pep-0475/
Our GObject structs should be internal API. In which case, we should
embed the private data in the struct themselves (`_priv`) and use the
_NM_GET_PRIVATE() macro. The advantage is better debugability because
following G_TYPE_INSTANCE_GET_PRIVATE() in the debugger is very
cumbersome. Another (less relevant) advantage is better performance.
Thus, warn about uses of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE().
Note that if the struct and is in a header file (which is usually only
necessary when subclassing the type), then the private data should be
an opaque pointer `_priv` instead, and we should use the _NM_GET_PRIVATE_PTR()
macro. In that case, the use of g_type_class_add_private() and
G_TYPE_INSTANCE_GET_PRIVATE() is correct and the warning is false. But
this is only a warning, for the unusual case where we have deep object
hierarchies.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1396
"-u" calls `git diff -name-only $UPSTREAM` to get a list of files.
However, if $UPSTREAM contains a file that doesn't exist in the current
checkout, we get a non-existing file name and clang-format will fail.
Avoid that, by filtering only files that exist.
Also, pass "--no-renames" option to git-diff.
Reformatting the entire source tree takes quite long. For fast
development it's useful to only check the files that changes on the
current checkout.
For that there was already the "-F|--fast" option, but that only
compared the files that changed compared to HEAD^.
What actually would be useful is to check the files that changed on the
current branch, compared to some upstream commit. Add "-u|--upstream"
option to specify the upstream commit (usually "main").
As a special twist,
./contrib/scripts/nm-code-format.sh -u
is the same as
./contrib/scripts/nm-code-format.sh -u main
We need to mount sysfs, so that `ip netns exec` works.
Do that automatically when starting the system container, via rc.local.
While at it, use `podman build --squash-all` to speedup the building of
the container image.
It's between "stop" and "clean". It removes the container,
but keeps the container images. This is to fast restart without
rebuilding the container (image).
- instead of g_str_hash()/g_direct_hash(), use our own functions
nm_str_hash()/nm_direct_hash(). Those use siphash24 with a random
seed.
- don't pass g_direct_equal() to GHashTable. When omitting the equal
function, it falls back to direct pointer comparison, which is likely
faster. In any case, it's consistent to not use g_direct_hash()
when using pointer equality.
- instead of g_int_hash()/g_int64_hash()/g_double_hash(), use
our nm_pint_hash()/nm_pint64_hash()/nm_pdouble_hash(). The latter
two don't exist yet.
The reason is that we want to use siphash24.
Yes, our name differs from glib's. Our naming seems to make sense
to me however, because we also have nm_pstr_hash(), nm_pdirect_hash()
and even nm_ppdirect_hash() for following the pointers. Naming is hard.
- instead of g_int_equal()/g_int64_equal()/g_double_equal() use
our nm_pint_equal()/nm_pint64_equal()/nm_pdouble_equal(). The latter
two don't exist yet. The reason is purely naming consistency since
our hash variants follow the other name.
Leave a hint about core-dumps.
Also, now we have `contrib/fedora/rpm/configure-for-system.sh` script,
which can configure the build in a way similar to what we get
when doing an RPM build.
That means, inside "contrib/scripts/nm-in-container.sh" we
can just type `make install`, and it will replace the pre-installed
NetworkManager.
The main advantage is that it becomes convenient to run NetworkManager
as a systemd service. Previously, the suggested was to to install
NetworkManager inside another prefix, and run it in the terminal.
Running NetworkManager as systemd service is also necessary for NM-ci,
which restarts the NetworkManager service, and you couldn't run a test,
if you just started NetworkManager in a terminal.
Previously, you had to build a complete RPM, which takes a lot of time.
Yes, it's a large dependency. But on your outer host you
probably configured NetworkManager with QT enabled (for the
example scripts). We want to compile the same work tree inside
the container. So install qt-devel.
This will use the same option as when we do an RPM build.
The purpose is that you could type `make install` with such
a build, and it would replace the files that you'd get by installing
the NetworkManager RPMs.
Of course, you would not want to do that on your work station, but it
will be useful in a container, where we don't mind messing up the
installation.
autotools accepts both --with-$OPTION/--without-$OPTION and
--with-$OPTION=yes|no. Consistently use the latter.
The advantage is that whether it's enabled becomes an argument, so in a
script you could do
"--with-$OPTION=$VALUE"
Same for enable/disable option.
The test bcond is used to make test suite failure terminate the %check
phase. That should generally be done for distro builds.
What the distro builds shouldn't do is terminate the build on compiler
warnings, because they're fairly likely to appear on toolchain updates
without indicating actual bugs.
However, currently that's precisely what do we do now.
Let's use -Werror on debug builds instead. They are intentionally made
more prone to fail (e.g. trip more runtime assertions) because failures
can be more rapidly addressed and don't affect distro builds.
Resolve the defaults in build.sh instead of RPM macros. This looks less
terrible maintaining the same defaults as well as options to override it
upstream.
Moving it to the block that downstreams (Fedora, Red Hat) keep
customized makes it possible for them to also maintain customized
defaults here.
In particular, the downstreams should be able to enable bcond_test
at least for their production release (otherwise there's little point in
actually running tests at package build time).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1286
Otherwise, the path "src/c-stdaux/src/docs/conf.py" matches for
formatting. But this file is imported via git-subtree, we don't
want to format it.
Filter out such paths.
