similar to: [common PATCH] Trim whitespaces from commands read from file

On Thu, Jan 23, 2020 at 02:04:53PM +0100, Martin Kletzander wrote: > On Thu, Jan 23, 2020 at 12:16:50PM +0100, Martin Kletzander wrote: > >Signed-off-by: Martin Kletzander <mkletzan@redhat.com> > > I forgot to mention this is trying to fix the following BZ: > > https://bugzilla.redhat.com/show_bug.cgi?id=1351000 > >--- > >mlcustomize/customize_cmdline.ml |

On Thu, Jan 23, 2020 at 10:32:17PM +0100, Martin Kletzander wrote: >On Thu, Jan 23, 2020 at 03:16:47PM +0000, Richard W.M. Jones wrote: >>On Thu, Jan 23, 2020 at 02:04:53PM +0100, Martin Kletzander wrote: >>> On Thu, Jan 23, 2020 at 12:16:50PM +0100, Martin Kletzander wrote: >>> >Signed-off-by: Martin Kletzander <mkletzan@redhat.com> >>> >>> I

On Wed, Jan 29, 2020 at 03:07:12PM +0100, Martin Kletzander wrote: > From: Martin Kletzander <mkletzan@redhat.com> > > The first split does not care about the whole string, it is just trying to get > the command name in front, so triml is just right. > > Signed-off-by: Martin Kletzander <mkletzan@redhat.com> > --- > mlcustomize/customize_cmdline.ml | 1 + >

On Thu, Jan 23, 2020 at 03:16:47PM +0000, Richard W.M. Jones wrote: >On Thu, Jan 23, 2020 at 02:04:53PM +0100, Martin Kletzander wrote: >> On Thu, Jan 23, 2020 at 12:16:50PM +0100, Martin Kletzander wrote: >> >Signed-off-by: Martin Kletzander <mkletzan@redhat.com> >> >> I forgot to mention this is trying to fix the following BZ: >> >>

On Thu, Jan 23, 2020 at 03:16:47PM +0000, Richard W.M. Jones wrote: >On Thu, Jan 23, 2020 at 02:04:53PM +0100, Martin Kletzander wrote: >> On Thu, Jan 23, 2020 at 12:16:50PM +0100, Martin Kletzander wrote: >> >Signed-off-by: Martin Kletzander <mkletzan@redhat.com> >> >> I forgot to mention this is trying to fix the following BZ: >> >>

On Thu, Jan 23, 2020 at 12:16:50PM +0100, Martin Kletzander wrote: >Signed-off-by: Martin Kletzander <mkletzan@redhat.com> I forgot to mention this is trying to fix the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1351000 >--- > mlcustomize/customize_cmdline.ml | 1 + > 1 file changed, 1 insertion(+) > >diff --git a/mlcustomize/customize_cmdline.ml

The first split does not care about the whole string, it is just trying to get the command name in front, so triml is just right. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- mlcustomize/customize_cmdline.ml | 1 + 1 file changed, 1 insertion(+) diff --git a/mlcustomize/customize_cmdline.ml b/mlcustomize/customize_cmdline.ml index c062379879e2..abd21a4cbca5 100644 ---

On Wednesday, 29 January 2020 17:22:51 CET Richard W.M. Jones wrote: > On Wed, Jan 29, 2020 at 03:07:12PM +0100, Martin Kletzander wrote: > > From: Martin Kletzander <mkletzan@redhat.com> > > > > The first split does not care about the whole string, it is just trying to get > > the command name in front, so triml is just right. > > > > Signed-off-by:

I got a little way into this. The two attached patches are preliminary work. My proposed split is: libguestfs.git common -> git submodule libguestfs-common.git generator/ lib/ all language bindings C based tools (eg. virt-df, virt-edit, guestfish) guestfs-tools.git common -> git submodule libguestfs-common.git

They do not contain messages. --- Makefile.am | 1 + po/POTFILES-ml | 11 ----------- 2 files changed, 1 insertion(+), 11 deletions(-) diff --git a/Makefile.am b/Makefile.am index 4dde5002..46a52ca3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -115,6 +115,7 @@ po/POTFILES-ml: configure.ac grep -v '^common/mlprogress/' | \ grep -v '^common/mlvisit/' | \ grep -v

Prune from the list of sources where to extract messages various sources with no messages: - .pl and .pm files, as they do not contain messages: almost all the .pl files are tests, and the only .pm file is the Perl Sys::Guestfs module, which wraps the XS extension - dummy.c sources; they are empty sources used to build OCaml-only targets using automake - gperf generated sources - C/OCaml

Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> --- mlcustomize/inject_virtio_win.ml | 2 +- mlcustomize/inject_virtio_win.mli | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index 8d72c5d..cf078c0 100644 --- a/mlcustomize/inject_virtio_win.ml +++

This type is going to be used as a return value in case we're injecting virtio-scsi block driver during conversion. Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> Acked-by: Laszlo Ersek <lersek at redhat.com> --- mlcustomize/inject_virtio_win.ml | 2 +- mlcustomize/inject_virtio_win.mli | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

From: "Richard W.M. Jones" <rjones at redhat.com> When injecting virtio-win drivers, allow the list of block drivers that we search to be modified. This functionality will be used when we introduce an option for changing the default block driver in virt-v2v. Originally-by: Richard W.M. Jones <rjones at redhat.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at

When injecting virtio-win drivers, allow the list of block drivers that we search to be modified. --- mlcustomize/inject_virtio_win.ml | 12 +++++++++--- mlcustomize/inject_virtio_win.mli | 10 ++++++++++ 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/mlcustomize/inject_virtio_win.ml b/mlcustomize/inject_virtio_win.ml index 4e977b3..2a7c742 100644 ---

In case when we are injecting virtio-scsi device driver into the guest (rather than the default virtio-blk), make sure we write the right PCI ID value into the Windows guest registry. This is essential for the guest to be bootable afterwards. Originally-by: Roman Kagan <rkagan at virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> ---

From: Roman Kagan <rkagan at virtuozzo.com> Since different hypervisor vendors are allowed to use their own vendor-id as PCI subsystem-vendor-id for virtio devices, during v2v conversion it makes sense to only match the vendor/device/revision and not the full device "path" in the Windows registry. This way the code will remain universal but will work for different hypervisor

Discussion on v1 https://listman.redhat.com/archives/libguestfs/2023-February/030849.html https://listman.redhat.com/archives/libguestfs/2023-March/030917.html v1 -> v2: * Drop the logic where default is switched to "vioscsi". Keep virtio-blk as default. * Adapt the patch suggested by Richard: https://listman.redhat.com/archives/libguestfs/2023-March/030974.html This

In case when we are injecting virtio-scsi device driver into the guest (rather than the default virtio-blk), make sure we write the right PCI ID value into the Windows guest registry. This is essential for the guest to be bootable afterwards. Originally-by: Roman Kagan <rkagan at virtuozzo.com> Signed-off-by: Andrey Drobyshev <andrey.drobyshev at virtuozzo.com> ---

From: Roman Kagan <rkagan at virtuozzo.com> Since different hypervisor vendors are allowed to use their own vendor-id as PCI subsystem-vendor-id for virtio devices, during v2v conversion it makes sense to only match the vendor/device and not the full device "path" in the Windows registry. This way the code will remain universal but will work for different hypervisor vendors.