network-online.target should not be reached before nm-cloud-setup
completes configuring the network, which may make user service get
started before the network is fully configured.
Setting nm-cloud-setup.service as "Before=network-online.target" would
maybe have already achieved that. However, also use a pre-up dispatcher
script, so that the device activation in NetworkManager is also waiting
for nm-cloud-setup to complete.
https://bugzilla.redhat.com/show_bug.cgi?id=2151040https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1653
Originally, the package was called vala-devel (it still is on CentOS7).
Then it was renamed to libvala-devel, but keeping a Provides.
On Fedora 39, the Provides was dropped. Workaround.
This is the version shipped in Fedora 38. As Fedora 38 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. This change
in isolation will break the "check-tree" test.
The actual formatting depends on the version of clang-format. Print the
used version, which is in particular interesting when we get an error in
our gitlab-ci check (which uses the correct version).
- We need to fetch more entries per page. 100 is the maximum without
pagination, but that is enough for us.
- Previously, we checked all stages. Now, let's skip the "prep" and "tier3" stages.
This change should work both with old and new pipelines.
Every branch (for example "nm-1-40") has exactly one next branch, from
which patches should be backported (in that example that branch is
"nm-1-42").
While "find-backports" searches all newer branches for patches, it does
not make it clear form where the patch should come from.
That means, if you run the script `contrib/scripts/find-backports origin/nm-1-40`
it will check nm-1-42 and main branch, and might suggest to backport
patches that are only on main, but not "nm-1-42". That would be wrong,
because patches need to first go into nm-1-42, and then backported (from
there) further to nm-1-40.
Print a warning to highlight that.
By default, podman bind mounts a "/etc/resolv.conf" file. That prevents
NetworkManager (inside the container) to update the file, which leads to
warnings in the log and certain NM-ci tests won't pass due to that.
Disable handling of "/etc/resolv.conf" in podman. But also pre-deploy a
default resolv.conf, with the google name server 8.8.8.8. I don't
understand why, but even with "--dns=none", writing "/etc/resolv.conf"
while building the container doesn't take effect. Instead, write a
usable "/etc/resolv.conf" from "/etc/rc.d/rc.local".
A "minor" release can still be the latest release. It depends
on which minor release you do. The script isn't smart enough
to understand the difference, so make the hint a bit clearer.
"configure-for-system.sh" is supposed to be in sync with
NetworkManager.spec. Update for the recent changes.
Also add a make/ninja call at the end. Almost always we want to build
after the configure.
[thaller@redhat.com: I introduced this bug when taking the original patch].
Fixes: 820f6f3a4a ('contrib/rpm: sync obsoletes_{initscripts_updown,ifcfg_rh} version')
Initially, when we obsoleted {initscripts_updown,ifcfg_rh}, the package
versions that we build from this upstream spec file differed from what
we put into Fedora/RHEL.
By now, this is long gone, and for upstream package builds we don't care
to accurately track the version, when using upstream/copr builds. Just
sync the version to what they are in Fedora/RHEL.
On the main branch, we commonly rebase our WIP branches to latest HEAD,
before merging them with "--no-ff". The effect is to have a merge commit
that acts as a parentheses around the set of patches.
When backporting such a branch, we should preserve that structure and
take the merge commit too. We should must use `git cherry-pick -x` to
record the commit IDs of the original patch.
This script helps with that.
Also hook it up in "contrib/scripts/nm-setup-git.sh" to create an alias
for it. This alias has the advantage, of fetching the latest version of
the script from "main" or "origin/main", so it also works on older
branches.
It seems that `meson test` is preferred over `ninja test`. Also, pass
"--print-errorlogs" to meson, and pass "-v" to the build steps.
Note that `ninja test` already ends up calling `meson test
--print-errorlogs`, but it doesn't use "-v", so the logs are truncated.
Like done for autotools. First we run the test without debugging option.
If it fails, we run it again to possibly trigger the failure again and
get better logs.
"debug" is implied when setting NMTST_DEBUG, but not specifying
"no-debug". This change has thus no effect, but it seems clearer to be
explicit.
The "debug" flag affects nmtst_is_debug(). Note that tests *must* not
result in different code paths based on debug, they may only
1) print more debug logging
2) do more assertion checks.
Having more assertion checks can result in different outcome of the
test, that is, that the additional assertion fails first. That is
acceptable, because failing earlier is possibly closer to the issue and
helps debugging. Also, when the additional failure is fixed and passes,
we still will fail at the assertion we are trying to debug.
In particular, an access to nmtst_get_rand*()/nmtst_rand*() must not
depend on nmtst_is_debug(), because then different randomized paths
are taken based on whether debugging is enabled.
The code was just wrong. Usually in gitlab-ci, NMTST_SEED_RANDOM is
unset, so the previous code would not have set it. Which means that our
tests run with NMTST_SEED_RANDOM="0".
Fuzzing (or randomizing tests) is very useful, we should do that for the
unit tests that run in gitlab-ci. Fix this.
But don't let the test choose a random number. Instead, let the calling
script choose it. That is, because we might run the tests more than once
(without debugging and no valgrind; in case of failure return with
debugging; with valgrind). Those runs should use the same seed.
This fixes commit 70487d9ff8 ('ci: randomize tests during our CI'),
but as fixing randomization can break previously running tests, we may
only want to backport this commit after careful evaluation.
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.
