Previous commit 97c57a8887 added a
potential bug in the sparsify build. If virt-sparsify had used a
*.mli file then it would have tried to run a command like:
ocamlc mlguestfs.cmxa -c foo.mli -o foo.cmi
This would fail because ocamlc doesn't know about native code
libraries (*.cmxa). In fact virt-sparsify was not affected by this
because it doesn't use any *.mli files.
Fix this by adjusting the automake variables.
If a disk has type 0x42 partition (which would indicate LDM), but LDM
is not available then try parsing the partition anyway. It might be
parseable as plain old NTFS.
There are two observations which make this possible: (1) virt-sparsify
contains at least one C unit, so automake thinks it is compiling a C
program. (2) Automake lets us add a *_LINK rule to override linking.
We list the C sources of virt-sparsify as virt_sparsify_SOURCES, so
automake thinks it is building a C program as normal.
We override virt_sparsify_LINK to make it actually link an OCaml
program.
We add virt_sparsify_DEPENDENCIES listing the OCaml objects so that
they get built before linking.
We need a small linker script (link.sh) which adds some options at the
end of the linker command line which are impossible to add using pure
automake.
Inspired by the same idea in supermin:
https://github.com/libguestfs/supermin/blob/master/src/Makefile.am
As long as over ~300MB is recovered, declare sparsification to be
successful in this test.
It looks as if the journal or other metadata takes up a variable
amount of space after sparsification.
We must avoid touching appliance/supermin.d unless it is necessary, so
that we avoid unnecessary rebuilds of the full appliance.
Unfortunately since we created temporary files there, even if we
didn't decide to keep those temporary files they would still end up
touching supermin.d. To stop this, move the temporary files out.
Exclude the arch-independent pkg-config files (no pkg-config available
in the appliance).
Exclude also the doc-base and reportbug files, typically found in Debian
systems.
Add a new lexer token, unused in the grammar, for the unknown lines in
index files; this should allow to better handle such kind of parsing
errors, removing the need to exit() directly (and leave things in an
unclean state).
Since HPET is specific to x86, we can safely add it its option only on
x86 and x86_64 when creating the libvirt XML (no more hitting the
launching failures due to that on other architectures).
Regarding the direct qemu launch, since qemu 1.1 (which is our current
minimum) "-ho-hpet" appears in the help only where actually supported,
so we could just checking for it and adding it only if present. This
should fix the architecture issues on this backend as well.
The boot partition name is /dev/ubda1 in this case, so use a small sed
script to canonicalize it for the test comparison.
This fixes commit f6a37740f2.
61323fa introduced a mandatory arch field within index files to
identify the architecture of the OS installed within a given template.
This change simply documents the requirement within the relevant
section of the virt-builder man page.
Signed-off-by: Lee Yarwood <lyarwood@redhat.com>
This removes the internal APIs internal_set_libvirt_selinux_label and
internal_set_libvirt_selinux_norelabel_disks. The communication
between the libvirt domain and the backend now uses the backend
settings.
Currently the backend settings are treated as a list of strings. You
can set the whole list (clearing any strings there previously), but
you cannot search for an individual string or replace an individual
string.
This adds further APIs allowing you to do that. We treat the backend
settings as a list of environment-like strings (ie. name=value), and
add the following functions:
- set-backend-setting (name, value)
Set name=value. Any previous settings of name are cleared.
- get-backend-setting (name)
Search for name or name=value and return the value.
- clear-backend-setting (name)
Remove any name or name=value settings.
This also adds a regression test.
This is not used by libguestfs right now, but it does allow you to
build a python "distribution" of libguestfs, like this:
make -C python sdist
The distribution tarball will be in python/dist/
You can copy the distribution tarball somewhere, unpack it, and use
regular 'python setup.py' commands such as:
python setup.py build
python setup.py install [--prefix=...]
python setup.py --name
In future we hope to be able to upload the distribution tarball to
PyPi, but licensing issues prevent this at present.
guestfs___validate_guid was a new function added to utils.c in
commit beef77403c.
However utils.c should not include <guestfs-internal.h> since the
other functions in this file can be used by all front-end code, not
just libguestfs.so.
This function is only needed in libguestfs.so, so move it to another
source file, and remove include of <guestfs-internal.h> from utils.c.
Also: use 'size_t' for counting, not 'int'.
This fixes commit beef77403c.
Breaks Python distutils which doesn't use C99:
utils.c: In function ‘guestfs___copy_string_list’:
utils.c:79:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t j = 0; j < i; ++j)
^
utils.c:79:7: note: use option -std=c99 or -std=gnu99 to compile your code
