search for: db_load

...s_deb (guestfs_h *g, const char *root) { diff --git a/m4/guestfs-progs.m4 b/m4/guestfs-progs.m4 index 757d50d88..a36b9ad2d 100644 --- a/m4/guestfs-progs.m4 +++ b/m4/guestfs-progs.m4 @@ -65,12 +65,8 @@ AM_CONDITIONAL([HAVE_PO4A], [test "x$PO4A" != "xno"]) dnl Check for db_dump, db_load (optional). GUESTFS_FIND_DB_TOOL([DB_DUMP], [dump]) GUESTFS_FIND_DB_TOOL([DB_LOAD], [load]) -if test "x$DB_DUMP" != "xno"; then - AC_DEFINE_UNQUOTED([DB_DUMP],["$DB_DUMP"],[Name of db_dump program.]) -fi -if test "x$DB_LOAD" != "xno"; then -...

We went around the houses a few times last year in order to try to fix this old Debian bug: https://bugzilla.redhat.com/show_bug.cgi?id=1409024 My last attempt was: https://www.redhat.com/archives/libguestfs/2017-October/msg00058.html which I believe was neither reviewed nor rejected, so I'm reposting the same patch again, simply rebased against current git. Rich.

Previously posted: https://www.redhat.com/archives/libguestfs/2017-October/msg00032.html This takes a completely different approach. It turns out that POSIX / the shell already defines a special exit code 127 for ‘command not found’. We can make a small adjustment to lib/command.c to return this exit code in that case. Then we just have to modify the db_dump code to test for this exit code. I

Brought to you by the "I haven't rebuilt the libguestfs universe in a while" saga -- now with working test suite. Pino Toscano (5): build: remove extra gnulib submodule build: remove extra checks and submodules build: stop using gnulib in test-harness build: remove unused gnulib modules Remove extra entries from podfiles .gitmodules | 3 -- Makefile.am

Brought to you by the "I haven't rebuilt the libguestfs universe in a while" saga. Pino Toscano (5): build: remove extra gnulib submodule build: remove extra checks and submodules build: stop using gnulib in test-harness build: remove unused gnulib modules Remove extra entries from podfiles .gitmodules | 3 -- Makefile.am | 2 - bootstrap

Hi, the libguestfs library uses a number of external tools; for some of them, we search for them at build time, enabling some feature only if found, and later on assuming at runtime they are installed. However, the situation is more complex than that: - hardcoding the full path means that there is an incoherency in the way some of the tools are used, as some other tools (e.g. qemu-img) are

Hi, the libguestfs library uses a number of external tools; for some of them, we search for them at build time, enabling some feature only if found, and later on assuming at runtime they are installed. However, the situation is more complex than that: - hardcoding the full path means that there is an incoherency in the way some of the tools are used, as some other tools (e.g. qemu-img) are

...ng way of doing this in reverse. That is, I do not have a corresponding way to write the new values back to the Astdb. The most obvious way of writing to the Astdb is by using PERL's DB_File. I tried compiling DB_File using the Berkeley 1.85 lib and header to no avail. I've had no luck with db_load either. Any insight at all to write many values to the Astdb quickly would be greatly appreciated. Regards; _________________________________________________________________ Windows Live?: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_ex...

On 22/02/16 17:26, Richard W.M. Jones wrote: > On Sun, Feb 21, 2016 at 11:22:23PM +0200, Matteo Cafasso wrote: >> Adding ntfscat_i command for downloading files based on their inode number. >> >> This allows the dowload of files unaccessible otherwise from a NTFS guest disk image. > The patch seems fine, but it really needs a test otherwise this > feature could silently

...p to date. > make[3]: 'blank-bootrootlv.img' is up to date. > make[3]: 'debian.img' is up to date. > rm -f fedora-name.db fedora-name.db-t > no fedora-name.db-t < fedora-name.db.txt > /bin/bash: no: command not found What happens here is it's trying to run ``$(DB_LOAD) fedora-name.db-t'' but the db_load program wasn't found by your configure. I think you need to install whatever is the db4-utils (Berkeley DB 4) on your OS. Alternately you can grab the pre-built databases from a recent tarball, since we distribute this stuff in the tarball so it doe...

...[3]: 'blank-bootrootlv.img' is up to date. >> make[3]: 'debian.img' is up to date. >> rm -f fedora-name.db fedora-name.db-t >> no fedora-name.db-t < fedora-name.db.txt >> /bin/bash: no: command not found > What happens here is it's trying to run ``$(DB_LOAD) fedora-name.db-t'' > but the db_load program wasn't found by your configure. I think you > need to install whatever is the db4-utils (Berkeley DB 4) on your OS. > > Alternately you can grab the pre-built databases from a recent > tarball, since we distribute this stuff...

Hi, continuing what started a couple of weeks ago [1], the attached patch series continues the work in making it easier to build and run libguestfs (in fixed appliance mode) on OSes different than Linux. The provided changes should cause no functional changes on Linux. [1] https://www.redhat.com/archives/libguestfs/2014-October/msg00176.html Thanks, -- Pino Pino Toscano (9): build: check

I spent the last couple of days rethinking how we go about building the appliance, and the difficulties we have porting that to other Linux distros. I've come up with a much better way that works better and faster on (so far) Fedora and Debian (probably on Ubuntu too, not tried it), and should be much simpler to port to other distros. The current way is to do: +------------------+

This just fixes 'make'. 'make check' is still broken. Further patches for that to follow tomorrow. Rich.

We are migrating to Weblate (the Fedora instance, in particular) for translations instead of Zanata. Adapt our tooling a bit to the different workflow: - Weblate takes care of updating the po files whenever a new translation catalog is available, so stop doing that on our own: this meant also tweaking the po4a usage for POD documentations, resulting in simpler rules (IMHO) - ensure that the

Two (not related to each other) refactorings: Patches 1-12 split configure.ac into smaller files using the m4_include mechanism. Patches 13-15 split out parts of guestfs.pod (ie. guestfs(3)) into three new manual pages: guestfs-hacking(3) - how to extend and contribute to libguestfs guestfs-internals(3) - architecture and internals guestfs-security(3) - security and CVEs Patch 16 is a

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

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..87dba240b 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

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

We are migrating to Weblate (the Fedora instance, in particular) for translations instead of Zanata. Adapt our tooling a bit to the different workflow: - Weblate takes care of updating the po files whenever a new translation catalog is available, so stop doing that on our own: this meant also tweaking the po4a usage for POD documentations, resulting in simpler rules (IMHO) - ensure that the