When shipping the libguestfs tarball we do not necessarily have
common/mlcustomize. If we run the generator in this situation then
don't try to generate files in the non-existent directory.
See-also: commit 7ced2b9354
This was returning "readdir: Invalid argument" which is actually
impossible (readdir(3) cannot fail with EINVAL). It turns out that
the problem is just errno from some other place leaking out.
This was deprecated in btrfs 4.14.1 and recently removed (see
btrfs-progs commit 4bd94dba8a "btrfs-progs: mkfs: remove alloc start
options and docs"). If the option is set simply ignore it.
Use qemu-nbd --pid-file option so we don't have to use an arbitrary
sleep.
Enable all parts of the test, since everything should work now with
various upstream bugs having been fixed in the 8 years since the test
was originally written.
libcap commit 177cd41803 ("A more compact form for the text
representation of capabilities.") changed the format used by
cap_to_text(3), breaking our test. Change the test to cope. This
will break with older libcap now, but there's not a lot we can do
about it.
Before this change the tests ran in about 12m34 and afterwards in
about 6m20, although the real change is more dramatic if you only run
tests from the tests/ subdirectory (as language tests still run serially).
This breaks valgrinding for now, which I intend to fix properly later.
This test was correctly copied into the new guestfs-tools repository
when virt-resize was moved there along with the other tools. However
it was never removed from libguestfs. We were effectively running the
test on the installed virt-resize.
Fixes: commit 733d2182b6
Note this requires libvirt >= 7.1.0 which was only released in March 2021.
With an older libvirt you will see this error:
Original error from libvirt: unsupported configuration: Invalid mode attribute 'maximum' [code=67 int1=-1]
In theory we could check if this is supported by looking at the
libvirt capabilities and fall back, but this commit does not do that,
in the expectation that most people will be using the default backend
(direct) and on Fedora/RHEL we will add an explicit minimum version
dependency to the package.
qemu support has been around quite a bit longer (at least since 2017).
Fixes: commit 30f74f38bd
This is used in virt-win-reg, but that tool have moved out to
guestfs-tools so the dependency is no longer needed by libguestfs
itself.
Fixes: commit 733d2182b6
This was only used for a single rule (check-valgrind-local-guests)
which ran "make check-valgrind" on local guests. This was never
really used by me and was fairly inadvisable anyway, so we can easily
remove it and thus remove the dependency on perl Sys::Virt.
CC virt_builder-setlocale-c.o
setlocale-c.c:38: error: "Val_none" redefined [-Werror]
38 | #define Val_none (Val_int (0))
|
In file included from /usr/lib64/ocaml/caml/alloc.h:24,
from setlocale-c.c:23:
/usr/lib64/ocaml/caml/mlvalues.h:395: note: this is the location of the previous definition
395 | #define Val_none Val_int(0)
|
QEMU has a newish feature (from about 2017 / qemu 2.9) called -cpu max
which is supposed to select the best CPU, ideal for libguestfs.
After this change, on x86-64:
KVM TCG
Direct -cpu max -cpu max
(non-libvirt)
Libvirt <cpu mode="host-passthrough"> <cpu mode="host-model">
<model fallback="allow"/> <model fallback="allow"/>
</cpu> </cpu>
Thanks: Daniel Berrangé
Previously this was in common/utils. However it is not used anywhere
else, and guestfs-tools wants to remove gnulib dependencies, so move
this to libguestfs.
Normally packagers should try to use ./configure --with-guestfs-path=...
However if they do not, then a regression in 1.44 caused the path to
constain the literal string "${exec_prefix}". This was because of
autoconf stupidity.
Try to resolve this by expanding ${exec_prefix} to something sensible.
The expansion will often be wrong (but at least it will now be a valid
path), hence the recommendation to always set --libdir and/or
--with-guestfs-path when configuring.
Fixes: commit 94ff24b880
Fixes: https://bugzilla.redhat.com/1915646
In commit 4bbbf03b8b we started to
ignore bogus GCC 11 warnings. Unfortunately earlier versions of GCC
don't know about those pragmas so give warnings [hence errors in
developer builds] like:
tsk.c:75:32: error: unknown option after '#pragma GCC diagnostic' kind [-Werror=pragmas]
Turn off these warnings.
Updates: commit 4bbbf03b8b
