similar to: [supermin PATCH 0/2] Create a really empty base.tar.gz

This is a "merge" of two previous series: https://www.redhat.com/archives/libguestfs/2018-December/msg00015.html https://www.redhat.com/archives/libguestfs/2018-December/msg00020.html The goal is to handle better situations like: - empty file in the appliance directory - no config files available in the packages to include in an appliance Compared to the two series, the changes are: -

This is just refactoring, with no behaviour changes. --- src/mode_prepare.ml | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/src/mode_prepare.ml b/src/mode_prepare.ml index 7c8221e..7759c58 100644 --- a/src/mode_prepare.ml +++ b/src/mode_prepare.ml @@ -128,28 +128,28 @@ let prepare debug (copy_kernel, format, host_cpu, * be

tar defaults to 10K as block size, and thus it pads the created archives to multiples of that size using zero's. Hence, when creating an archive with no files, it will be 10K zero's, that is compressed by gzip, resulting in few bytes. The issue happens later, during the build phase: base.tar.gz is correctly detected as gz, and zcat is run to detect its content: since the empty tar was

--- configure.ac | 1 + src/config.ml.in | 1 + src/dpkg.ml | 1 + 3 files changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 2141540..99ea913 100644 --- a/configure.ac +++ b/configure.ac @@ -92,6 +92,7 @@ AC_PATH_PROG(APT_GET,[apt-get],[no]) AC_PATH_PROG(DPKG,[dpkg],[no]) AC_PATH_PROG(DPKG_DEB,[dpkg-deb],[no]) AC_PATH_PROG(DPKG_QUERY,[dpkg-query],[no])

While trying to run libguestfs tests after building with "--enable-appliance --with-supermin-extra-options=--use-installed", I ran into a peculiar error message in the c-api test: ,---- | libguestfs: error: strings: /abssymlink: strings: error while loading | shared libraries: libbfd-2.24-multiarch.so: cannot open shared object | file: No such file or directory `---- The problem here

Document what each module does, using *.mli files. Remove the --dtb option, it's obsolete. Rename modules according to their purpose. Rich.

This is an attempt to make supermin check for the existing results of an output when checking whether the appliance must be rebuilt using --if-newer. At the moment it is implemented only for the build mode, and for its ext2 output format. Pino Toscano (4): build: factor ext2 filenames Tighten Unix_error check for missing outputdir Extend modes with list of outputs build: set

--- src/build.ml | 43 ++++++++++++++++++++++++++----------------- src/chroot.ml | 12 +++++++----- src/dpkg.ml | 17 +++++++++++++++-- src/ext2.ml | 8 +++++++- 4 files changed, 55 insertions(+), 25 deletions(-) diff --git a/src/build.ml b/src/build.ml index 9225184..205701b 100644 --- a/src/build.ml +++ b/src/build.ml @@ -106,11 +106,7 @@ let rec build debug *) let files =

--- src/dpkg.ml | 3 ++- src/package_handler.ml | 1 + src/package_handler.mli | 4 ++++ src/pacman.ml | 2 +- src/rpm.ml | 2 +- 5 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/dpkg.ml b/src/dpkg.ml index c28354a..5a650b8 100644 --- a/src/dpkg.ml +++ b/src/dpkg.ml @@ -166,7 +166,8 @@ let dpkg_get_all_files pkgs = let config = try

This patch series fixes several problems in the way that supermin handles kernels. The most pressing problem is that supermin doesn't handle bogus vmlinuz files which aren't actual kernels. Along the way there is a lot of clean up. The patches look much better if you view them with ‘-w’. This series will require plenty of time to be tested in Fedora, especially on non-x86 arches.

Hi, to ease debugging issues with appliances (e.g. when used in libguestfs), using --include-packagelist will add a file containing the list of all the packages used. Thanks, Pino Toscano (3): ext2: add ext2fs_chmod and ext2fs_chown chroot: factor out file copy code Add --include-packagelist src/build.ml | 42 +++++++++++++++++++++++++------ src/chroot.ml | 29

Hi Rich But there is no src/kernel.ml file on my ubuntu powerpc to which the above patch is reffering. I have installed supermin as supermin_5.1.8-2_powerpc.deb debian package. Thanks On Tue, Jun 3, 2014 at 7:16 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Tue, Jun 03, 2014 at 06:55:49PM +0530, abhishek jain wrote: > > supermin: failed to find a suitable kernel

Hi, few cleanups in the supermin codebase; no actual functional change. Thanks, -- Pino Toscano (3): ext2: simplify tracking of visited modules utils: remove unused run_python function Add and use an helper error function src/build.ml | 20 +++++----------- src/dpkg.ml | 4 +--- src/ext2_initrd.ml | 10 ++++---- src/kernel.ml | 27

I have done some printf profiling and found that supermin's calls to dpkg for individual packages are quite expensive. Here are some patches that gather all information on demand where possible. On my Debian/unstable-based workstation at home, preparing a minimal appliance using $ ./supermin --use-installed --prepare bash -o supermin.d now takes ~3.5s (previously ~15s). Turning that

Add a function for each mode to return the list of potential outputs, so that the existance/timestamp checks done for --if-newer can take those into accounts. At the moment both modes return no outputs, so there is no behaviour change. --- src/mode_build.ml | 7 +++++++ src/mode_build.mli | 4 ++++ src/mode_prepare.ml | 9 ++++++++- src/mode_prepare.mli | 4 ++++ src/supermin.ml | 9

Hiya. While merging the 2.6.0 changes into our modified version of rsync, I noticed the following bit of code in 2.6.0's options.c: extern int sanitize_paths; if (sanitize_paths) sanitize_path(strdup(files_from), NULL); filesfrom_fd = open(files_from, O_RDONLY|O_BINARY); Since sanitize_path modifies its first argument in place, the path that open()

* Richard W.M. Jones: > On Sat, Apr 26, 2014 at 02:27:07PM +0200, Hilko Bengen wrote: >> --- >> src/kernel.ml | 43 ++++++++++++++++++++++++++++--------------- >> 1 file changed, 28 insertions(+), 15 deletions(-) >> >> diff --git a/src/kernel.ml b/src/kernel.ml >> index ed5aea3..436b1b0 100644 >> --- a/src/kernel.ml >> +++ b/src/kernel.ml

* Richard W.M. Jones: > This seems to change the result of this (very important and complex) > function. Since you didn't answer my followup message, I take it that I failed to convince you. I noticed that I can get away with leaving the structure of the function as-is, just changing the type... What do you think about this diff? Cheers, -Hilko diff --git a/src/build.ml

On Fri, Apr 03, 2020 at 12:20:57PM +0200, Pino Toscano wrote: > Add a function for each mode to return the list of potential outputs, so > that the existance/timestamp checks done for --if-newer can take those > into accounts. > > At the moment both modes return no outputs, so there is no behaviour > change. Patches 1, 2 and 4 are fine. I have a minor problem with this patch:

Hi Rich Kindly ignore my previos mail. I have downloaded the latest version of supermin supermin-5.1.8 and have compiled it for powerpc.Moreover there was no need to patch the src/ kernel.ml file as the changes were already implemented on the latest version. But still when i run libguestfs-test-tool on powerpc ubuntu,I get the below logs.. libguestfs-test-tool