similar to: [PATCH 00/10] tests: Introduce test harness for running tests.

This converts more of the tests (basically everything under tests/) to use the test harness, revealing some problems which have subsequently been fixed. Rich.

For v6: This is mainly just a rebase, but I have also added tests in the ocaml/ language bindings directory, and for all the OCaml-written virt tools. Rich.

v7: The only changes since v6 are those suggested by Pino in the review of v5.

Since v4: - More tests have been converted. - Testing local guests fixed. - Drop no-exec-stack test.

This is a more complete patch to add the test harness. The only parts missing now are the language bindings (except OCaml). The language bindings need a bit more thought. At the moment most language binding tests are done through some sort of shell script like perl/run-perl-tests which either runs each test itself or uses some language-specific machinary to run each test. The problem with that

Since v2: - Add perl tests. - Reworked and fixed the tests for virt-builder. - Some further minor bug fixes.

Since v3: - A large number of fixes, especially for running the tests on installed libguestfs. - Fixed EXTRA_DIST rules throughout. - Extra patch 17/17 which is a tidy-up of the generated XML listing guests. Rich.

This has got to the stage where it actually works, both for running the tests in-tree and installed. The 'test-harness' script has become rather over-complex in the process however. Rich.

On Sunday 05 October 2014 14:08:35 Richard W.M. Jones wrote: > +# Install the test harness. > +localtestsdir = $(alltestsdir) > +localtests_SCRIPTS = ../test-harness Shouldn't it rather go to libexec? > +../test-harness: > + rm -f $@ $@-t > + echo 'echo Warning: Install OCaml compiler in order to rebuild the test-harness.' > $@-t > + chmod +x

These are my thoughts on adding a test harness to run tests instead of using automake. The aim of this exercise is to allow us to run the full test suite on an installed copy of libguestfs. Another aim is to allow us to work around all the limitations and problems of automake. The first patch makes an observation that since the ./run script sets up $PATH to contain all the directories

- Add $(srcdir), $(builddir) to Makefiles where required - Post-process ocamldep output - generate ocaml/.depends --- builder/Makefile.am | 7 ++++--- common/mlgettext/Makefile.am | 2 +- common/mlpcre/Makefile.am | 2 +- common/mlprogress/Makefile.am | 2 +- common/mlstdutils/Makefile.am | 2 +- common/mltools/Makefile.am | 2 +- common/mlutils/Makefile.am | 2 +-

Just like the similar series that already went in for libguestfs [1], do similar fixes also for virt-v2v, with additional fixes for the builddir!=srcdir case. This will also need the fix to subdir-rules.mk. [1] https://www.redhat.com/archives/libguestfs/2019-December/msg00062.html Pino Toscano (7): Update common to latest build: stop shipping files generated by configure build: use the

Previously posted here: https://www.redhat.com/archives/libguestfs/2015-June/msg00266.html Rich.

Previously I posted a work-in-progress preview of this patch series: https://www.redhat.com/archives/libguestfs/2017-February/msg00224.html This is the finished version that updates all of the shell-script based tests. It passes 'make check', 'make check-direct' and 'make check-slow'. Rich.

This patch series moves some files and directories around but is only code motion (or supposed to be). A new directory, common/, is created for all of the common code which is currently shared in random ways between parts of the project. And src/ becomes lib/ (the largest change, but mostly mechanical). In full this series makes the following changes: src/libprotocol -> common/protocol

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

Previous patch series was posted here: https://www.redhat.com/archives/libguestfs/2017-January/msg00059.html v2 simply extends this patch series to cover the extra directories common/edit, common/progress, common/windows and common/parallel. The only remaining item is to consider whether we should rename mllib to something else, mlcommon was my suggestion. Rich.

*** BLURB HERE? *** Pino Toscano (6): build: stop shipping files generated by configure docs: fix out-of-source documentation build generator: do not generate mlv2v files when not needed perl: fix path to Build.PL rust: fix path to lib.rs rust: fix list of generator-built files daemon/Makefile.am | 8 ++++++-- docs/Makefile.am | 4 ++-- generator/main.ml | 11

This new series condenses all of the previously posted patches into new patch 1/2. The second patch is a new fix for parallel build in the haskell directory.

Fix one dist issue, and various builddir!=srcdir issues, also with the patch proposed in the Debian bug #946594. Patch #3 applies also to the virt-v2v repository, and will be committed there too (with references to the libguestfs commit). Pino Toscano (3): inspector: ship the actual test script tests: fix srcdir references build: fix make implicit dependencies on ml/mli files