Fix the following error:
meson.build:3:0: ERROR: Unknown options: "console_kit, systemd_logind"
Fixes: a287659c5f ('automation: adapt build_from_source to use meson')
As autotools is deprecated, we must build with meson for
NetworkManager-1.47 or greater. As we plan to drop autotools in
NetworkManager-1.50, we must do the change as soon as possible.
The existing find-backports.sh script seems to not work well.
For example, it does not include fixes for patches that are in
the common history of the current branch and upstream. This script is
supposed to work better.
Fetch both from github and gitlab, and also fetch the references for the
merge-requests/pull-requests.
In practice is github just a mirror of gitlab, so seemingly it wouldn't
make sense to fetch from there. However:
- by adding github as a remote, we can preferably fetch from there.
I think that is faster than our gitlab at freedesktop.org. Thank
you, Microsoft!
- pull requests against github are indeed not found in gitlab.
We need to fetch all kinds of remote references, so that the referenced
commits are in the git repository. Also, we need to fetch them under
various name, so that these references are available to CI.
For example, when someone opens a merge-request from their fork on
gitlab/github, the commit is usually not not referenced by regular
branches on gitlab/github. Hence, we couldn't schedule CI for those
commit. Also fetch the special references for these.
Also, don't use `timeout` to fetch the repository.
find-backports.sh only works because we craft commit messages with
necessary information. In particular the "Fixes" and cherry-picked-from
messages. That means, it relies on our git history to maintained in
a suitable manner so that the script can gather the necessary
information.
Likewise, we have a particular scheme how we do releases, how versions
are numbered, how stable branches and release tags are called, etc.
Exploit that, to allow for simpler calling convention for
find-backports.sh script:
$ contrib/rh-utils/find-backports.sh 1.14
will automatically complete to
$ contrib/rh-utils/find-backports.sh 1.14.0 nm-1-14 master
- moves installing libubsan to the previous yum-install.
Since we already pass --skip-broken, we don't need the
"|| true".
- also, sort the packages
- also, combine "set" lines
Fix installing also noarch packages. I think they were omitted wrongly
before, and installing them now might break existing assumptions during
CI (like, which packages are installed and which not).
But since the script anyway didn't ensure which RPMs are installed
prevoiusly, it was very likely that packages like NetworkManager-config-server
was already installed. CI needs to always anticipate that such packages
may be installed and act accordingly. Usually, this just means to
explicitly overwrite the configuration snippets provided by these
packages.
During the test build we enabled "--with-netconfig=yes".
Since commit "5b36585a3d build/autotools: fail configure if
netconfig/resolveconf tool is not found", when specifying
"--with-netconfig=yes" the user is required to have netconfig
installed (so that the path can be detected). Otherwise it fails
with
checking for netconfig... no
configure: error: cannot find netconfig in path. Set the path explicitly via --with-netconfig=PATH.
The correct way is to explicitly specify the path. In that
case, it's OK that the file doesn't actually exist.
In the final version which was merged, the check is non-fatal and
has to be enabled explicitly to fail. See "aa8a7559a3 build: merge
branch 'th/check-gtk-doc-behavior'".
This reverts commit cd8b1cc284.
For libnm, we use opaque types. gtk-doc has/had an issue parsing
this code, and generates suboptimal documentation.
There is a merge request against gtk-doc to address that [1].
However, there is also a `make check` test, which tries to determine
whether gtk-doc is suitable [2].
When building for beaker, we don't need this check. Also, because likely
beaker is not up to the task.
[1] https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/2
[2] https://github.com/NetworkManager/NetworkManager/pull/196
git doesn't like to fetch into a local branch which is currently
checked out.
$ git fetch origin --prune
fatal: Refusing to fetch into current branch refs/heads/master of non-bare repository
We need to first checkout a plain commit (detached HEAD).
Fixes: 2f67ac9eaf
Without it, `git checkout -B nmbuild nm-1-10` will fail, because
there is no local branch refs/heads/nm-1-10. Previously, it worked
because there was (one) refs/remotes/origin/nm-1-10, so if we didn't
specify "-B" option, git would create a remote-tracking local branch.
Fix it, by fetching the remote branches as local branches.
Fixes: 2f67ac9eaf
When somebody creates a pull request against NetworkManager's github
repository, the github repository itself usually doesn't have a branch
that references the pull request.
Hence, the commit will not be fetched by default and checking out
the commit will fail.
Also add and fetch the refs for the pull request.
