search for: dpkg_queri

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

* 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

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

--- 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])

dpkg used to ship with a symlink /usr/sbin/dpkg-divert -> ../bin/dpkg-divert that recently got removed nd caused breakage (libguestfs build failures) because configure had chosen the wrong binary. --- configure.ac | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 3a0d25d..72ffb92 100644 --- a/configure.ac +++ b/configure.ac @@ -110,10

When building the mini initrd, previously we copied the modules into the initrd as-is, so for example if the module was xz-compressed, we copied the foo.ko.xz file to the initrd. This requires that the mini init binary is linked to zlib & lzma, so that it knows how to uncompress these modules when insmoding them at boot time. Also since the init is statically linked, it required _static_

Allow an alternate libc, such as dietlibc, to be used for the init binary in the supermin appliance. Rich.

Check the ID field in /etc/os-release on the current system, before checking for the other old-style release-/version-like files in /etc. Some distributions (openSUSE Thumbleweed) are starting to remove them, breaking the supermin detection. --- src/dpkg.ml | 3 ++- src/pacman.ml | 5 +++-- src/rpm.ml | 15 +++++++++------ 3 files changed, 14 insertions(+), 9 deletions(-) diff --git

Hi, let's make supermin use /etc/os-release as primary source instead of the various release files in /etc; apparently distros (e.g. openSUSE) are starting removing them. Thanks, Pino Toscano (2): Add simple handling of /etc/os-release Use os-release to detect the distro src/Makefile.am | 3 +++ src/dpkg.ml | 3 ++- src/os_release.ml | 78

v1 -> v2: - If we split out the init program into a separate init/ directory, that makes it much easier to build against an alternate libc. I tried to build against uClibc, but uClibc requires an entire build chain, which looked like it was going to be a massive ballache. Rich.

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