Re: [Libguestfs] Running lcitool in nbdkit

I rebased Martin's tree[1] on top of libvirt-ci head, and reran lcitool. There are several places where I changed the generated files in nbdkit.git and where those changes are overwritten (I didn't realise those files were generated). I think I can fix most of them. But a couple of larger problems I can see ... (a) lcitool wants to make this change: diff --git a/ci/containers/fedora-rawhide.Dockerfile b/ci/containers/fedora-rawhide.Dockerfile index 7e0a8d25..d4409f87 100644 --- a/ci/containers/fedora-rawhide.Dockerfile +++ b/ci/containers/fedora-rawhide.Dockerfile @@ -6,10 +6,7 @@ FROM registry.fedoraproject.org/fedora:rawhide -RUN dnf update -y && \ - dnf install 'dnf-command(config-manager)' -y && \ - dnf config-manager -y --add-repo=http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo && \ - dnf update -y --nogpgcheck fedora-gpg-keys && \ +RUN dnf update -y --nogpgcheck fedora-gpg-keys && \ I added "dnf install 'dnf-command(config-manager)'" in: https://gitlab.com/nbdkit/nbdkit/-/commit/e359fab8c682436faff914591b5ff42... because the dnf config-manager command doesn't work. The dnf config-manager command in turn was added earlier in Martin's original commit. I don't know if Martin added that manually or if an earlier version of lcitool generated it, but it is necessary in order to use the nodebug kernel, and using the nodebug kernel is necessary to avoid performance problems, timeouts and out of memory problems when using libguestfs on Rawhide.

(b) lcitool wants to remove my perl conditionalization changes: @@ -312,11 +309,10 @@ mingw32-fedora-35: - mingw32-fedora-35-container allow_failure: false variables: - NAME: fedora-35 CROSS: mingw32 - PERL: skip - RUST: skip GOLANG: skip + NAME: fedora-35 + RUST: skip which I added here: https://gitlab.com/nbdkit/nbdkit/-/commit/414ee371ee2b1a12c6d45466d041322... I'm not clear where I should have added those. The rust conditionalization stuff doesn't seem to be part of lcitool so I guess it's generated from another file somewhere. Be nice if original files were called "file.in" or something like that so we can tell what files are generated and what are originals.