search for: c_utils_unit_tests

...| 6 +- common/mlutils/Makefile.am | 156 ++++++++++++++++++++++++++++ v2v/utils-c.c => common/mlutils/c_utils-c.c | 6 +- common/mlutils/c_utils.ml | 26 +++++ common/mlutils/c_utils.mli | 30 ++++++ common/mlutils/c_utils_unit_tests.ml | 81 +++++++++++++++ common/mlutils/dummy.c | 2 + {mllib => common/mlutils}/unix_utils-c.c | 0 {mllib => common/mlutils}/unix_utils.ml | 0 {mllib => common/mlutils}/unix_utils.mli | 0 configure.ac | 1 +...

...sts.ml common/mltools/planner.ml common/mltools/regedit.ml common/mltools/registry.ml -common/mltools/tools_messages_tests.ml common/mltools/tools_utils.ml -common/mltools/tools_utils_tests.ml common/mltools/urandom.ml common/mltools/xpath_helpers.ml common/mlutils/c_utils.ml -common/mlutils/c_utils_unit_tests.ml common/mlutils/unix_utils.ml common/mlv2v/uefi.ml common/mlxml/xml.ml @@ -86,9 +77,7 @@ v2v/target_bus_assignment.ml v2v/types.ml v2v/utils.ml v2v/v2v.ml -v2v/v2v_unit_tests.ml v2v/vCenter.ml v2v/var_expander.ml -v2v/var_expander_tests.ml v2v/windows.ml v2v/windows_virtio.ml -- 2.24.1

...++++++++++++++++++++++++--- mlv2v/dummy.c | 2 ++ 3 files changed, 70 insertions(+), 4 deletions(-) create mode 100644 mlv2v/dummy.c diff --git a/.gitignore b/.gitignore index 88c1c63..a788c55 100644 --- a/.gitignore +++ b/.gitignore @@ -60,6 +60,7 @@ Makefile.in /mlutils/.depend /mlutils/c_utils_unit_tests /mlutils/oUnit-* +/mlv2v/.depend /mlvisit/.depend /mlvisit/visit_tests /mlxml/.depend diff --git a/mlv2v/Makefile.am b/mlv2v/Makefile.am index 9e82148..945f981 100644 --- a/mlv2v/Makefile.am +++ b/mlv2v/Makefile.am @@ -18,11 +18,74 @@ include $(top_srcdir)/subdir-rules.mk EXTRA_DIST = \ - $...

On Thu, Aug 03, 2017 at 06:08:24PM +0200, Pino Toscano wrote: > But I guess I have no chance to change the current patch (even adding > a test using asserts, instead of oUnit, for which I still did not get > a reason why a new test using it would be unacceptable), so ... Fewer dependencies make the code easier for others to consume, and that's especially true when (like oUnit) those

...n/mltools/regedit.ml > common/mltools/registry.ml > -common/mltools/tools_messages_tests.ml > common/mltools/tools_utils.ml > -common/mltools/tools_utils_tests.ml > common/mltools/urandom.ml > common/mltools/xpath_helpers.ml > common/mlutils/c_utils.ml > -common/mlutils/c_utils_unit_tests.ml > common/mlutils/unix_utils.ml > common/mlv2v/uefi.ml > common/mlxml/xml.ml > @@ -86,9 +77,7 @@ v2v/target_bus_assignment.ml > v2v/types.ml > v2v/utils.ml > v2v/v2v.ml > -v2v/v2v_unit_tests.ml > v2v/vCenter.ml > v2v/var_expander.ml > -v2v/var_expander_tes...

...> Surely I'm not an expert OCaml hacker, but at least to me oUnit2 does > not seem that complex, and a manually written framework would end up > reimplementing most of it, in the end. If you compare an oUnit test: https://github.com/libguestfs/libguestfs/blob/master/common/mlutils/c_utils_unit_tests.ml to an assert test: https://github.com/libguestfs/libguestfs/blob/master/daemon/daemon_utils_tests.ml There is barely any difference to me. This is my point really: oUnit doesn't bring any particular benefit. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat....

...sts.ml common/mltools/planner.ml common/mltools/regedit.ml common/mltools/registry.ml -common/mltools/tools_messages_tests.ml common/mltools/tools_utils.ml -common/mltools/tools_utils_tests.ml common/mltools/urandom.ml common/mltools/xpath_helpers.ml common/mlutils/c_utils.ml -common/mlutils/c_utils_unit_tests.ml common/mlutils/unix_utils.ml common/mlv2v/uefi.ml common/mlvisit/visit.ml -common/mlvisit/visit_tests.ml common/mlxml/xml.ml customize/append_line.ml customize/crypt.ml -- 2.24.1

...pert OCaml hacker, but at least to me oUnit2 does > > not seem that complex, and a manually written framework would end up > > reimplementing most of it, in the end. > > If you compare an oUnit test: > > https://github.com/libguestfs/libguestfs/blob/master/common/mlutils/c_utils_unit_tests.ml > > to an assert test: > > https://github.com/libguestfs/libguestfs/blob/master/daemon/daemon_utils_tests.ml > > There is barely any difference to me. This is my point really: oUnit > doesn't bring any particular benefit. Just few points that come into my mind: -...

The previously selected 'atomic' recipe resulted in 2GB swap in a 6GB volume. Also, we don't really need the boot partition, so just create a partition using the whole disk space. --- builder/templates/debian.preseed | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/builder/templates/debian.preseed b/builder/templates/debian.preseed index

From: "Richard W.M. Jones" <rjones@redhat.com> With OCaml < 4.02 when using the alternate Bytes module, this module would be compiled twice during parallel builds, resulting in occasional corruption. The reason for this is that the ocamldep file mentions ‘bytes.cmo’ whereas the ‘$(OCAML_BYTES_COMPAT_ML)’ macro expands to ‘../../common/mlstdutils/bytes.ml’. Make doesn't

Commit 0a94cae15bae7cecb725e78e485708694d347612 added useful headings to parts of the configure script. This refactors the code by adding a common macro (‘HEADING’), and also changes the output so it's clearer at a glance: --- Checking for Haskell --- checking for ghc... (cached) ghc --- Checking for PHP --- checking for php... (cached) php checking for phpize... (cached) phpize

Even if ocamlopt is available, always build a bytecode version of ‘common/mlstdutils’. The generator is always built as bytecode. The generator depends on ‘../common/mlstdutils/guestfs_config.cmo’ and ‘../common/mlstdutils/std_utils.cmo’, but if these have not been built already then the generator races to build the .cmi files. Since the generator doesn't have the dependencies covering for

Untested - still working on reproducing this bug. Rich.

See: https://bugzilla.redhat.com/show_bug.cgi?id=1469655 https://github.com/systemd/systemd/issues/6334 https://lists.freedesktop.org/archives/systemd-devel/2017-July/039325.html

v1 was: https://www.redhat.com/archives/libguestfs/2017-July/msg00154.html There is no change in the first patch, but I added a second patch adding slow tests of opensuse guests (which pass, but require the first patch). Rich.

In SUSE guests, handle the case where Bootloader::Tools::GetDefaultSection () returns undef. Previously this would return an empty string and cause a bogus error in subsequent code: virt-v2v: error: libguestfs error: statns: statns_stub: path must start with a / character --- v2v/linux_bootloaders.ml | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git

v3 -> v4: Use HAVE_OCAMLOPT in both places.

Removed extra $(OCAML_BYTES_COMPAT_CMO). Add if HAVE_OCAMLOPT around the call to ocamlopt. Tested with OCaml 4.01 on RHEL 7. Rich.

v1: https://www.redhat.com/archives/libguestfs/2017-July/msg00127.html v2: - Remove /etc/systemd/system/default.target.wants/guestfs-firstboot.service link as well. - Use multi-user.target for virt-p2v as well. Rich.

The C function mkdtemp(3) requires that the string ends with 6 'X' characters, so appending a non-empty suffix causes the function to raise EINVAL. Luckily we only ever called this function with the last parameter "". --- builder/builder.ml | 2 +- builder/sigchecker.ml | 2 +- common/mlutils/unix_utils.ml | 4 ++--