similar to: [PATCH] builder: handle -v and -x flags like in other tools (RHBZ#1196100)

Instead of creating Guestfs handles and manually apply common options (e.g. debug and trace), use the open_guestfs in Common_utils. This also applies the common options to handles which didn't set them before, so we can inspect also their messages if needed. --- builder/builder.ml | 8 ++------ customize/customize_main.ml | 4 +--- dib/dib.ml | 4 +---

Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index c28905d..23bd708 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -60,19 +60,9 @@ let rec main () = let overlays = create_overlays source.s_disks in let targets = init_targets overlays source

Move most of open_guestfs to Types, so a common function to open a Guestfs handle is available. Since it does not do all the things the old open_guestfs did, the two operations have been moved to the only place requiring them. This function has been placed in Types and not Utils, as will be needed by other functions in Types; Utils uses Types, so this avoids a circular dependency. ---

.. and a lot of refactoring. https://bugzilla.redhat.com/show_bug.cgi?id=1167623 Rich.

https://bugzilla.redhat.com/show_bug.cgi?id=1167623

On Mon, Nov 25, 2013 at 09:58:50PM +0000, Richard W.M. Jones wrote: > On Mon, Nov 25, 2013 at 12:52:21PM -0700, Jon wrote: > > Hello, > > > > I'm having trouble connecting to rbd images. It seems like somewhere the > > name is getting chewed up. I wonder if this is related to my previous > > troubles [1] [2] with rbd images. > > > > I'm

Hello, I'm having trouble connecting to rbd images. It seems like somewhere the name is getting chewed up. I wonder if this is related to my previous troubles [1] [2] with rbd images. I'm trying to add an rbd image, but when I launch the guestfs object I get an error: >> libguestfs: trace: launch = -1 (error) I'm adding a single RBD >> libguestfs: trace: add_drive

Introduce a new common helper to add the common options for libguestfs tools (short/long options, version, verbose, trace), and sort them. All the OCaml-based tools had these options already, so there are no functional changes in the interface they provide. The only difference is that now the options are always sorted, while some tools didn't had them like that previously: because of this, a

Introduce a new option to control how virt-resize behaves when asking to expand a filesystem, either unknown to libguestfs or that virt-resize cannot expand. The default keeps the current behaviour, i.e. just warn. --- bash/virt-resize | 3 +++ resize/resize.ml | 65 ++++++++++++++++++++++++++++++++++++++++++++++++-- resize/virt-resize.pod | 28 +++++++++++++++++++++- 3 files

Don't pass these flags to dozens of functions. --- builder/builder.ml | 47 +++++++++-------- builder/cache.ml | 4 +- builder/cache.mli | 2 +- builder/cmdline.ml | 13 ++--- builder/downloader.ml | 14 +++-- builder/downloader.mli

Hey, The following code creates a raw binary (no ELF or PE.. just raw): gcc -nostartfiles -c -o hello.o hello.c ld -o hello1 hello.o --oformat binary You can try the following code out with it: void _start() { while(1); } The resulting raw binary is 5 bytes. Now how do you do this in clang/llvm? Apparently llvm-ld doesn't have a "--oformat binary" option. Anybody know how to

how to use python-guestfs to access rbd device? The function i found is g.add_drive_opts, but i dono know how it receive ceph's configuration. I found this link http://rwmj.wordpress.com/2013/03/12/accessing-ceph-rbd-sheepdog-etc-using-libguestfs/ Is that the only way i should use to access ceph rbd? Can we use python-guestfs to get the same effect? Thanks

On 2009-12-17 22:08, LiteHacker wrote: > Hey, > > The following code creates a raw binary (no ELF or PE.. just raw): > > gcc -nostartfiles -c -o hello.o hello.c > ld -o hello1 hello.o --oformat binary > > You can try the following code out with it: > > void _start() > { > while(1); > } > > The resulting raw binary is 5 bytes. > It is 2.1M here

The 'may' function is a higher-order function (HOF) that replaces: match x with | None -> () | Some x -> f x with: may f x The idea comes from lablgtk (OCaml Gtk bindings) where it is widely used. If this change is clearer than previous code, then this could be used in many more places. However I previously steered clear from using HOFs like this because they can be

Process the sources specified via the --source command line arguments before sources read from repositories, so the former have a chance to "override" the latter. Related to RHBZ#1193238. --- builder/builder.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builder/builder.ml b/builder/builder.ml index c7f1dae..a519913 100644 --- a/builder/builder.ml +++

On Tue, Aug 26, 2014 at 06:16:50PM +0800, Hu Tao wrote: > Hi, > > The attached patch adds support for resizing MBR logical partitions. The > failure is still there, I can't get any helpful information from lsof. > Any suggestions? I don't see the error: Error: Error informing the kernel about modifications to partition /dev/sdb5 However I do see this error:

Indeed ld does link it. The reason I am using llvm-ld, is for its unique functionality. I intend to link to object files together (created by cling), and link them with llvm-ld. The main feature that I am currently interested in is the ability to have "inline functions" between two object files. This was basically impossible with gcc. Is there any way to make the raw binary with llvm?

Refactor copying of virtio windows drivers into the guest so that the matching of the drivers to the guest os flavor and copying the files happens one next to the other in a single function, and no guestfs handle (nor any other irrelevant info) is leaked outside. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes since v1: - former patch #3 - updated usage of string functions

I have a Fedora 24 system I can already get this working for most OVA files, just the BSD and atomic ones weren't recognized. Assuming my version of virt-v2v is just old, I installed rawhide on a different system and tried with virt-v2v-1.37.8-1.fc27.x86_64 and now its having another problem. Is there a known version of virt-v2v I should be using? Here is the output from the rawhide attempt

One remaining blocking issue for linking FreeBSD with lld is the inability to build the bootloader components. We have a patch[1] in review to address one of the problems by switching to using a linker script instead of GNU ld's -N option. Another issue is that some bootloader components are created by the linker directly as binary objects, using --oformat binary. (Other bootloader components