similar to: Libguestfs gobject bindings

This patch replaces patches 14 and 15 from my previous series. The gtk-doc output is now reasonable, and we can rely on an automatically generated guestfs-sections.txt. Matt

I've summarised how the GObject bindings work below, which should hopefully help reviewing the generator/generated code. There are a couple of points in here I'm still not 100% happy with. Specifically the handling of FBuffer and the Cancellable flag. Both are explained below. I'm interested in suggestions. Return values: ************** All functions which can return an error

This is the first iteration of the GObject bindings. I have 'kicked the tyres' on these, meaning I have ensured that a bunch of basic manual tests work as expected. I'm in the process of adding more comprehensive tests. Here's an example simple javascript program which uses these bindings: === const Guestfs = imports.gi.Guestfs; print('Starting'); var g = new

The main goal of these patch series is to implement a new API that allows to retrieve created device-mapper devices for volumes and partitions back after they have been created. As part of this patch: - required libdevmapper version was bumped to 1.02. I think it is safe because it was released more then 10 years ago; - newer version of libdevmapper allowed to simplify code base a little bit; -

This reverts commit 3f6ca541c7b24d4c86688a509582cb41a7e0078c. The original commit was reverted prematurely. --- generator/generator_actions.ml | 10 +++++----- generator/generator_checks.ml | 5 +++++ generator/generator_types.ml | 3 +++ 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/generator/generator_actions.ml b/generator/generator_actions.ml index

--- generator/generator_actions.ml | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/generator/generator_actions.ml b/generator/generator_actions.ml index 68a7bf6..fcf363f 100644 --- a/generator/generator_actions.ml +++ b/generator/generator_actions.ml @@ -4664,7 +4664,7 @@ This creates an ext2/3/4 filesystem on C<device> with an external journal on

--- generator/generator_gobject.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/generator/generator_gobject.ml b/generator/generator_gobject.ml index e4c175b..48ddbf0 100644 --- a/generator/generator_gobject.ml +++ b/generator/generator_gobject.ml @@ -391,7 +391,7 @@ let generate_gobject_optargs_source name optargs flags () = pr "G_DEFINE_TYPE(%s, guestfs_%s,

RConstOptString cannot return an error in the C api. This makes it a special case for the GObject api, as all other return types have a corresponding GError **err argument to return an error. This change removes this special case, and includes the possibility of an error return in the API. An error is indicated by setting *err to a non-NULL value. This change is in preparation for adding a close

v2: wrap commit message, "PATCH libldm" prefix. v3: correctly initialize and free GLib resources. The result of this patch might be used by libguestfs to return drive mappings for LDM volumes. Note, that "show volume" ldmtool command already returns hint which is a drive letter assigned by Windows to corresponding volume. But it is not reliable source of information. More

v2: wrap commit message, "PATCH libldm" prefix. v3: correctly initialize and free GLib resources. v4: gtk-doc is updated to reflect presence of new volume GUID field. The result of this patch might be used by libguestfs to return drive mappings for LDM volumes. Note, that "show volume" ldmtool command already returns hint which is a drive letter assigned by Windows to

The result of this patch will be used by libguestfs to return drive mappings for LDM volumes. Note, that "show volume" ldmtool command already returns hint which is a drive letter assigned by Windows to corresponding volume. But it is not reliable source of information. More over, in multiboot environment it is unclear which drive letter belongs to which operating system. Volume GUID

v2: wrap commit message, "PATCH libldm" prefix. The result of this patch might be used by libguestfs to return drive mappings for LDM volumes. Note, that "show volume" ldmtool command already returns hint which is a drive letter assigned by Windows to corresponding volume. But it is not reliable source of information. More over, in multiboot environment it will be unclear

Hi, this patch serie adds a new GUID type in the generator, which would do the same as String, but also validating (just in the C output) the passed GUID string. This allows to reject invalid GUIDs before passing them to low-level tools. Pino Toscano (4): utils: add a function to validate a GUID string generator: add a GUID parameter type generator: generate code for parameter validation

> source("http://www.bioconductor.org/biocLite.R") > biocLite(c("Ruuid")) Running getBioC version 0.1.6 with R version 2.3.1 Running biocinstall version 1.8.4 with R version 2.3.1 Your version of R requires version 1.8 of Bioconductor. trying URL 'http://bioconductor.org/packages/1.8/bioc/src/contrib/Ruuid_1.10.0.tar.gz' Content type 'application/x-gzip'

v1 -> v2: Added a (now blue) underlined "Identify interface" link. It's not really a link, but it looks like one, so hopefully should resolve the previous UI issue. Rich.

run on startup by default like the other ovirt services --- conf/ovirt-vnc-proxy | 49 ++++++++ installer/modules/ovirt/manifests/ovirt.pp | 1 + ovirt-server.spec.in | 5 + src/vnc-proxy/vnc-proxy.rb | 167 ++++++++++++++++++++++++++++ 4 files changed, 222 insertions(+), 0 deletions(-) create mode 100755 conf/ovirt-vnc-proxy

This patch series integrates libosinfo in virt-v2v to get the list of files for Windows from libosinfo, if possible. The actual data is still from virtio-win, just unpacked. Changes from v1: - adapt to use the priority in libosinfo 1.7.0+ - filter out non-pre-installable drivers - collect all the drivers matching the requirements, not just the first, sorting them by priority like libosinfo does

Hi, This is an initial implementation of a vhost-user backend for the VirtIO RPMB device. The device is currently in the draft of the next VirtIO specification and describes block device which uses combination of a key, nonce, hashing and a persistent write counter to prevent replay attacks (hence Replay Protected Memory Block). It is implemented as a vhost-user device because we want to

In an effort to reduce the code, start to use few bits of GLib: - replace the gnulib c-type module - replace the gnulib getprogname module - use g_spawn_sync to launch curl, and drop a file reading function Pino Toscano (6): Include glib.h in p2v.h Use g_ascii_isspace instead of c_isspace from gnulib Use g_get_prgname instead of getprogname from gnulib build: remove no more used gnulib

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1792141 Let the user pass "-oo" options from the kernel cmdline and from the GUI to virt-v2v. This is primarily useful with the OpenStack output mode, so reenable that mode. Cc: Alban Lecorps <alban.lecorps at ubisoft.com> Laszlo Alban Lecorps (1): Introduce "p2v.output.misc" for passing "-oo" options