similar to: ldmtool in RHEL (was: Re: https://www.redhat.com/archives/libguestfs/2012-December/msg00020.html)

This is just an initial version of the patch, not to be applied. It implements just the diskgroup functions, ie. corresponding to these ldmtool commands: * ldmtool scan * ldmtool show diskgroup <guid> I have chosen yajl as the JSON parsing library (don't worry, this is optional). You will also, of course, need ldmtool which is not packaged in anything except Fedora. Rich.

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

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

The ELF NEEDED are used to determine guestfsd's library dependencies with help from the dynamic linker and the package manager. This was prompted by Debian bug #972241 which was caused by a libtirpc package renaming in Debian/unstable because the SONAME had been changed. --- appliance/Makefile.am | 26 ++++++++++++++++- appliance/packagelist.in | 62

Forgive me if this is the wrong area to ask this question. I'm happy to inquire to a diff list if that's better. From: http://libguestfs.org/ "Downloads For source see the downloads directory. In Fedora or Red Hat Enterprise Linux: sudo yum install libguestfs-tools On Debian/Ubuntu: sudo apt-get install libguestfs-tools Open a disk image: guestfish --ro -i -a disk.img Other

How to reproduce: 1. Extract test images from test/data/ldm-data.tar.xz 2. losetup --show -f test/data/ldm-2003r2-simple-1.img Let's assume image file was associated with /dev/loop0 3. ldmtool -d /dev/loop0 create all Result: One LDM volume which contains all required components on the associated loop device will be mapped but application crashes on further attempt to do the same for

How to reproduce: 1. Extract test images from test/data/ldm-data.tar.xz 2. losetup --show -f test/data/ldm-2003r2-simple-1.img Let's assume image file was associated with /dev/loop0 3. ldmtool -d /dev/loop0 create all Result: One LDM volume which contains all required components on the associated loop device will be mapped but application crashes on further attempt to do the same for

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; -

Two simple build fixes for libldm. Well, the first isn't a build fix as such, but a code improvement. Rich.

I am running 4.8-STABLE. I recently did a cvsup (repeatedly, most recently today). Ever since, portupgrade dies with the following messages: zircon# portupgrade -r pkgconfig /usr/local/lib/ruby/site_ruby/1.6/pkgdb.rb:310:in `deorigin': failed to convert nil into String (PkgDB::DBError) from /usr/local/lib/ruby/site_ruby/1.6/pkgdb.rb:903:in `tsort_build' from

On Tue, Nov 03, 2020 at 07:06:49PM +0800, zhang yuxing wrote: > Hi, Mr.Rich: > > First of all, thank you very much for your help in the following question, > which perfectly solved the problem in my project. > > https://bugzilla.redhat.com/show_bug.cgi?id=1890478 > > In addition, I saw your commitment in August in the following project, which > fixes an important bug.

? Thank you. It will help me a lot if there is a new release version? > ? 2020?11?3??19:40?Richard W.M. Jones <rjones at redhat.com> ??? > ?On Tue, Nov 03, 2020 at 07:06:49PM +0800, zhang yuxing wrote: >> Hi, Mr.Rich: >> First of all, thank you very much for your help in the following question, >> which perfectly solved the problem in my project. >>

--- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 469ea96..0e7e2ea 100644 --- a/configure.ac +++ b/configure.ac @@ -85,14 +85,14 @@ PKG_CHECK_MODULES([GIO_UNIX], [gio-unix-2.0 >= 2.32.0], ] ) -PKG_CHECK_MODULES([ZLIB], [zlib >= 1.2.5], +PKG_CHECK_MODULES([ZLIB], [zlib >= 1.2], [

I'm very pleased to announce the release of libguestfs 1.20. Libguestfs is a library and a comprehensive set of tools for accessing and modifying virtual machine (VM) disk images. For more information see http://libguestfs.org Libguestfs 1.20 represents 7 months of upstream work, dozens of major new features and bug fixes. For full details read the release notes below. You can download

v1 was here: https://www.redhat.com/archives/libguestfs/2018-May/msg00058.html v2: - more correct explanation of a crash reason. Mykola Ivanets (1): Fix crash while creating mapper for a volume which lacks of partitions. src/ldm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.17.0

my ports database seems to have become broken. I'm running -stable, but haven't rebuilt the system in a year or so (I know, security vulerabilities, but the box has been shelved in this time). anyhow, at this point, I can't do even a make clean in ports, or build portupgrade. I fetched portupgrade with pkg_add hoping that running pkgdb -F would sort things out, but it errors with: **

I fixed a couple issues in the RedHat init script provided in the scripts directory. There are some other things about it that could use updating, but first I checked out the one included with the RPM (https://admin.fedoraproject.org/pkgdb/acls/name/nut). That one looks pretty good, maybe it should replace the included scripts if permission is given by mhlavink? -------------- next part

I''d like to clarify some points about the ports/package system in FreeBSD. I apoligize ahead of time if this is Both packages and ports use the pkgdb system. This isn''t some lame cludge; it''s by design, and the reason is really quite simple. Packages are built from the ports collection. The only real difference between them is the mode of delivery. When you run