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.
When not specifying --with/--without debug, the default depends on the
version number. Hence, we should always explicitly enable or disable
the debug flag.
Also, add support for --with sanitizer.
Installs valgrind and provides a template for vgdb enabled valgrind-wrapped
service. The test harness is expected to pick this up, finish the setup and
eventually make use of it.
Since 87dc14476b we can enable
more assertions when building the RPM package. Allow passing
that option to "build-from-source.sh" by setting environment
"WITH_DEBUG=yes".
Building NetworkManager during kickstart has the serious disadvantage
that we don't yet run the installed system. E.g. if the kernel has
issues there, it fails `make check` of the build process, although
the later run kernel is fine.
Also, a failure during kickstart does not allow to access the machine
later to inspect the failure reason (e.g. the testing logfiles).
Instead, move the building to a separate script and run it as a beaker
task.
The new one doesn't support returning or extending. It can still be used with
--reservesys=new.
Revert "contrib/bkr: update specifying reservesys"
This reverts commit 96f49913c4.
Get rid of UploadFileSsh. This was hardly used because it
is cumbersome to use. Also, the default scheme was file://
if no scheme was given, which makes this especially non-useful.
Replace it by a new provider RPM, so that you can just specify
any rpms you want to install, like --rpm package1,package2.
Also, drop the no longer needed init() and prepare() steps.
Finally, rename UploadFile* classes to RpmScheme*.
Extend the job-template to allow building NM from source during
the test. By passing "--build-id master", the test will first
git-clone the repository of NetworkManager and build an RPM
of the selected commit.
This saves you to first build NetworkManager and then use
"--rpm brew://" or similar.
