February 2024 - Devel - libvirt List Archives

[PATCH 0/4] char: Minor fixes, and a tighter QAPI schema
by Markus Armbruster 14 Feb '24

14 Feb '24

Markus Armbruster (4): chardev/parallel: Don't close stdin on inappropriate device tests/unit/test-char: Fix qemu_socket(), make_udp_socket() check qapi/char: Make backend types properly conditional qapi/char: Deprecate backend type "memory" docs/about/deprecated.rst | 8 ++++++++ qapi/char.json | 28 +++++++++++++++++----------- include/qemu/osdep.h | 9 ++++++++- chardev/char-parallel.c | 7 +++++-- tests/unit/test-char.c | 25 +++++++++++++++++++++++-- chardev/meson.build | 4 +--- 6 files changed, 62 insertions(+), 19 deletions(-) -- 2.43.0

4 14

gitlab pages hosting for libvirt.org
by Peter Krempa 14 Feb '24

14 Feb '24

Hi, gitlab released the support for HTTP redirects to other domains: https://gitlab.com/gitlab-org/gitlab-pages/-/issues/601#note_1761877536 this means that our definitions of redirects which are needed to host our main web page via libvirt pages became valid: https://libvirt.gitlab.io/libvirt/_redirects https://gitlab.com/libvirt/libvirt/-/blob/master/.gitlab_pages_redirects?re… The redirects currently apply on the libvirt.gitlab.io/libvirt domain which test-hosts the page for now. If anyone wants to check the redirects for themselves please do so. Later today or tomorrow I'll push the already-reviewed patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/FFY… which will switch over the redirect rule prefixes for hosting from a custom domain (libvirt.org) thus checking them will not be possible until the hosting is switched over.

1 1

[PATCH 0/4] secret: Modernize XML parsing and formatting
by Michal Privoznik 13 Feb '24

13 Feb '24

Couple of things happening here: 1) add a missing case to our polkit checks 2) modernize XML parsing and formatting, so that the code is prepared for a new feature I'm working on. Michal Prívozník (4): viraccessdriverpolkit: Add missing vtpm case secret_conf: Simplify calling of virSecretDefParseUsage() virSecretDef: Convert 'usage_type' field to proper enum type secret_conf: Modernize XML parsing & formatting src/access/viraccessdriverpolkit.c | 17 ++++++ src/conf/secret_conf.c | 92 ++++++++++++++---------------- src/conf/secret_conf.h | 2 +- 3 files changed, 60 insertions(+), 51 deletions(-) -- 2.43.0

2 5

[PATCH 1/3] qemu: add a 'chain' parameter to nbdkit start/stop
by Jonathon Jongsma 12 Feb '24

12 Feb '24

This will allow us to start or stop nbdkit for just a single disk source or for every source in the backing chain. This will be used in following patches. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/qemu/qemu_extdevice.c | 8 +++--- src/qemu/qemu_hotplug.c | 6 ++--- src/qemu/qemu_nbdkit.c | 51 ++++++++++++++++++++++++++++++--------- src/qemu/qemu_nbdkit.h | 6 +++-- 4 files changed, 51 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c index 3cf3867056..ed5976d1f7 100644 --- a/src/qemu/qemu_extdevice.c +++ b/src/qemu/qemu_extdevice.c @@ -234,12 +234,12 @@ qemuExtDevicesStart(virQEMUDriver *driver, for (i = 0; i < def->ndisks; i++) { virDomainDiskDef *disk = def->disks[i]; - if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0) return -1; } if (def->os.loader && def->os.loader->nvram) { - if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram, true) < 0) return -1; } @@ -297,11 +297,11 @@ qemuExtDevicesStop(virQEMUDriver *driver, for (i = 0; i < def->ndisks; i++) { virDomainDiskDef *disk = def->disks[i]; - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); } if (def->os.loader && def->os.loader->nvram) - qemuNbdkitStopStorageSource(def->os.loader->nvram, vm); + qemuNbdkitStopStorageSource(def->os.loader->nvram, vm, true); } diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 31b00e05ca..e67673b762 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1018,7 +1018,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver, if (qemuHotplugAttachManagedPR(vm, disk->src, VIR_ASYNC_JOB_NONE) < 0) goto cleanup; - if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0) goto cleanup; } @@ -1045,7 +1045,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver, if (virStorageSourceChainHasManagedPR(disk->src)) ignore_value(qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE)); - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); } qemuDomainSecretDiskDestroy(disk); qemuDomainCleanupStorageSourceFD(disk->src); @@ -4562,7 +4562,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriver *driver, qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE) < 0) goto cleanup; - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); if (disk->transient) { VIR_DEBUG("Removing transient overlay '%s' of disk '%s'", diff --git a/src/qemu/qemu_nbdkit.c b/src/qemu/qemu_nbdkit.c index 1c72b6fe6a..39f9c58a48 100644 --- a/src/qemu/qemu_nbdkit.c +++ b/src/qemu/qemu_nbdkit.c @@ -893,18 +893,34 @@ qemuNbdkitInitStorageSource(qemuNbdkitCaps *caps WITHOUT_NBDKIT_UNUSED, } +static int +qemuNbdkitStartStorageSourceOne(virQEMUDriver *driver, + virDomainObj *vm, + virStorageSource *src) +{ + qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src); + + if (priv && priv->nbdkitProcess && + qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0) + return -1; + + return 0; +} + + int qemuNbdkitStartStorageSource(virQEMUDriver *driver, virDomainObj *vm, - virStorageSource *src) + virStorageSource *src, + bool chain) { virStorageSource *backing; - for (backing = src; backing != NULL; backing = backing->backingStore) { - qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing); + if (!chain) + return qemuNbdkitStartStorageSourceOne(driver, vm, src); - if (priv && priv->nbdkitProcess && - qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0) + for (backing = src; backing != NULL; backing = backing->backingStore) { + if (qemuNbdkitStartStorageSourceOne(driver, vm, backing) < 0) return -1; } @@ -912,18 +928,31 @@ qemuNbdkitStartStorageSource(virQEMUDriver *driver, } +static void +qemuNbdkitStopStorageSourceOne(virStorageSource *src, + virDomainObj *vm) +{ + qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src); + + if (priv && priv->nbdkitProcess && + qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0) + VIR_WARN("Unable to stop nbdkit for storage source '%s'", + qemuBlockStorageSourceGetStorageNodename(src)); +} + + void qemuNbdkitStopStorageSource(virStorageSource *src, - virDomainObj *vm) + virDomainObj *vm, + bool chain) { virStorageSource *backing; - for (backing = src; backing != NULL; backing = backing->backingStore) { - qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing); + if (! chain) + return qemuNbdkitStopStorageSourceOne(src, vm); - if (priv && priv->nbdkitProcess && - qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0) - VIR_WARN("Unable to stop nbdkit for storage source '%s'", qemuBlockStorageSourceGetStorageNodename(src)); + for (backing = src; backing != NULL; backing = backing->backingStore) { + qemuNbdkitStopStorageSourceOne(backing, vm); } } diff --git a/src/qemu/qemu_nbdkit.h b/src/qemu/qemu_nbdkit.h index 853b2cca6f..637bf962a7 100644 --- a/src/qemu/qemu_nbdkit.h +++ b/src/qemu/qemu_nbdkit.h @@ -63,11 +63,13 @@ qemuNbdkitReconnectStorageSource(virStorageSource *source, int qemuNbdkitStartStorageSource(virQEMUDriver *driver, virDomainObj *vm, - virStorageSource *src); + virStorageSource *src, + bool chain); void qemuNbdkitStopStorageSource(virStorageSource *src, - virDomainObj *vm); + virDomainObj *vm, + bool chain); int qemuNbdkitStorageSourceManageProcess(virStorageSource *src, -- 2.43.0

2 9

[PATCH 0/5] tests: More USB and capabilities for s390x
by Andrea Bolognani 12 Feb '24

12 Feb '24

*** UNIVERSAL SERIAL BLURB *** https://gitlab.com/abologna/libvirt/-/commits/caps-s390x Andrea Bolognani (5): tests: Rename s390-usb-* tests: Minimize s390-usb-* tests: Add s390-usb-model tests: Update capabilities for QEMU 8.1.0 on s390x tests: Add capabilities for QEMU 8.2.0 on s390x tests/domaincapsdata/qemu_8.1.0.s390x.xml | 80 +- ...u_8.1.0.s390x.xml => qemu_8.2.0.s390x.xml} | 152 +- .../caps_8.1.0_s390x.replies | 5000 +++++---- .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 732 +- ...s390x.replies => caps_8.2.0_s390x.replies} | 9526 ++++++++++------- ...s_8.1.0_s390x.xml => caps_8.2.0_s390x.xml} | 2058 ++-- ...default-video-type-s390x.s390x-latest.args | 2 +- ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- .../s390-allow-bogus-usb-controller.xml | 32 - .../s390-allow-bogus-usb-none.xml | 30 - ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- ...rgs => s390-usb-address.s390x-latest.args} | 9 - ....xml => s390-usb-address.s390x-latest.xml} | 22 +- tests/qemuxmlconfdata/s390-usb-address.xml | 15 + ....args => s390-usb-model.s390x-latest.args} | 11 +- ...st.xml => s390-usb-model.s390x-latest.xml} | 26 +- tests/qemuxmlconfdata/s390-usb-model.xml | 13 + ...t.args => s390-usb-none.s390x-latest.args} | 12 +- ...est.xml => s390-usb-none.s390x-latest.xml} | 22 +- tests/qemuxmlconfdata/s390-usb-none.xml | 13 + tests/qemuxmlconftest.c | 5 +- 24 files changed, 10053 insertions(+), 7717 deletions(-) copy tests/domaincapsdata/{qemu_8.1.0.s390x.xml => qemu_8.2.0.s390x.xml} (79%) copy tests/qemucapabilitiesdata/{caps_8.1.0_s390x.replies => caps_8.2.0_s390x.replies} (93%) copy tests/qemucapabilitiesdata/{caps_8.1.0_s390x.xml => caps_8.2.0_s390x.xml} (96%) delete mode 100644 tests/qemuxmlconfdata/s390-allow-bogus-usb-controller.xml delete mode 100644 tests/qemuxmlconfdata/s390-allow-bogus-usb-none.xml rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-none.s390x-latest.args => s390-usb-address.s390x-latest.args} (58%) copy tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.xml => s390-usb-address.s390x-latest.xml} (55%) create mode 100644 tests/qemuxmlconfdata/s390-usb-address.xml rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.args => s390-usb-model.s390x-latest.args} (58%) rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-controller.s390x-latest.xml => s390-usb-model.s390x-latest.xml} (51%) create mode 100644 tests/qemuxmlconfdata/s390-usb-model.xml copy tests/qemuxmlconfdata/{s390-defaultconsole.s390x-latest.args => s390-usb-none.s390x-latest.args} (61%) rename tests/qemuxmlconfdata/{s390-allow-bogus-usb-none.s390x-latest.xml => s390-usb-none.s390x-latest.xml} (50%) create mode 100644 tests/qemuxmlconfdata/s390-usb-none.xml -- 2.43.0

2 6

[PULL 02/10] docs: mark CRIS support as deprecated
by Alex Bennée 10 Feb '24

10 Feb '24

This might be premature but while streamlining the avocado tests I realised the only tests we have are "check-tcg" ones. The ageing fedora-cris-cross image works well enough for developers but can't be used in CI as we need supported build platforms to build QEMU. Does this mean the writing is on the wall for this architecture? Cc: Rabin Vincent <rabinv(a)axis.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Acked-by: Edgar E. Iglesias <edgar.iglesias(a)gmail.com> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240207163812.3231697-3-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index c7b95e6068e..7b0c59919e5 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -192,6 +192,13 @@ in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``, an alias, but for consistency these will get removed in a future release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead. +CRIS CPU architecture (since 9.0) +''''''''''''''''''''''''''''''''' + +The CRIS architecture was pulled from Linux in 4.17 and the compiler +is no longer packaged in any distro making it harder to run the +``check-tcg`` tests. Unless we can improve the testing situation there +is a chance the code will bitrot without anyone noticing. System emulator machines ------------------------ -- 2.39.2

1 0

Question about libvirtxml and kubernetes/kubevirt conventions
by Alice Frosi 09 Feb '24

09 Feb '24

Hi everyone, I would like to bring up a possible issue with the libvirt-go-xml-module and request your advice. We are considering using libvirtxml [2] as an alternative of the custom types for the libvirt schema in KubeVirt [1]. Nonetheless, KubeVirt makes an effort to adhere to Kubernetes best guidelines. One thing I've noticed, though, is that libvirtml consistently uses uint or int rather than uint32 or int32. This is in opposition to the primitive types that Kubernetes [3] recommends; in fact, KubeVirt uses them in the schema.go [4]. Would it be possible to align the libvirtxml go library to the Kubernetes conventions? [1] https://github.com/kubevirt/kubevirt [2] https://github.com/kubevirt/kubevirt/issues/10844 [3] https://github.com/kubernetes/community/blob/master/contributors/devel/sig-… [4] https://github.com/kubevirt/kubevirt/blob/main/pkg/virt-launcher/virtwrap/a… Many thanks, Alice

3 5

[PATCH v2] docs: Improve documentation for dies and clusters
by Andrea Bolognani 09 Feb '24

09 Feb '24

I've seen examples in the wild of the cluster attribute having non-zero value on x86_64. This is obviously quite confusing, but it's the information that Linux exposes to userspace and we don't really have a way to tell apart a valid die/cluster ID from a dummy one. What ultimately matters is that the underlying assumptions about topology are respected, which they are: in the x86_64 cases that I have analyzed, for example, each "cluster" contained exactly one core, so any program that would use this information to influence guest topology decisions would be unaffected by the additional level showing up in the hierarchy. In an attempt to reduce confusion, remove any reference to any specific value for the attributes having any special meaning attached to it. In fact, since there are plans to make it possible to create guests with multiple CPU clusters on x86_64, rework the note into a more generic warning cautioning users that an attribute showing up here does not imply that the same attribute can be used when defining a guest CPU topology. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/formatcaps.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index f37532296f..68477e639f 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -74,14 +74,14 @@ The ``<host/>`` element consists of the following child elements: ``die_id`` Identifier for the die the CPU is in. - Note that not all architectures support CPU dies: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, even if this attribute is present, you might not be able to + define guests with multiple CPU dies. ``cluster_id`` Identifier for the cluster the CPU is in. - Note that not all architectures support CPU clusters: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, even if this attribute is present, you might not be able to + define guests with multiple CPU clusters. ``core_id`` Identifier for the core the CPU is in. -- 2.43.0

2 1

[PATCH] docs: Improve documentation for dies and clusters
by Andrea Bolognani 09 Feb '24

09 Feb '24

I've seen examples in the wild of the cluster attribute having non-zero value on x86_64. This is obviously quite confusing, but it's the information that Linux exposes to userspace and we don't really have a way to tell apart a valid die/cluster ID from a dummy one. What ultimately matters is that the underlying assumptions about topology are respected, which they are: in the x86_64 cases that I have analyzed, for example, each "cluster" contained exactly one core, so any program that would use this information to influence guest topology decisions would be unaffected by the additional level showing up in the hierarchy. In an attempt to reduce confusion, document that the value for these attributes is not necessarily going to be zero. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- docs/formatcaps.rst | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index f37532296f..c15d391b63 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -74,14 +74,18 @@ The ``<host/>`` element consists of the following child elements: ``die_id`` Identifier for the die the CPU is in. - Note that not all architectures support CPU dies: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, while not all architectures support CPU dies, this attribute + will always be present in the capabilities XML. If the architecture + doesn't support them, the value will likely be 0 for all CPUs, but it + could also be some other arbitrary value. ``cluster_id`` Identifier for the cluster the CPU is in. - Note that not all architectures support CPU clusters: if the current - architecture doesn't, the value will be 0 for all CPUs. + Note that, while not all architectures support CPU clusters, this + attribute will always be present in the capabilities XML. If the + architecture doesn't support them, the value will likely be 0 for all + CPUs, but it could also be some other arbitrary value. ``core_id`` Identifier for the core the CPU is in. -- 2.43.0

2 10

[libvirt PATCH 0/2] ci: lcitool: sync dependencies with libvirt-ci repo
by Ján Tomko 09 Feb '24

09 Feb '24

Ján Tomko (2): ci: lcitool: sync dependencies with libvirt-ci repo ci: regenerate ci/buildenv/almalinux-8.sh | 1 + ci/buildenv/alpine-319.sh | 1 + ci/buildenv/alpine-edge.sh | 1 + ci/buildenv/centos-stream-8.sh | 1 + ci/buildenv/centos-stream-9.sh | 1 + ci/buildenv/debian-11-cross-aarch64.sh | 1 + ci/buildenv/debian-11-cross-armv6l.sh | 1 + ci/buildenv/debian-11-cross-armv7l.sh | 1 + ci/buildenv/debian-11-cross-i686.sh | 1 + ci/buildenv/debian-11-cross-mips64el.sh | 1 + ci/buildenv/debian-11-cross-mipsel.sh | 1 + ci/buildenv/debian-11-cross-ppc64le.sh | 1 + ci/buildenv/debian-11-cross-s390x.sh | 1 + ci/buildenv/debian-11.sh | 1 + ci/buildenv/debian-12-cross-aarch64.sh | 1 + ci/buildenv/debian-12-cross-armv6l.sh | 1 + ci/buildenv/debian-12-cross-armv7l.sh | 1 + ci/buildenv/debian-12-cross-i686.sh | 1 + ci/buildenv/debian-12-cross-mips64el.sh | 1 + ci/buildenv/debian-12-cross-mipsel.sh | 1 + ci/buildenv/debian-12-cross-ppc64le.sh | 1 + ci/buildenv/debian-12-cross-s390x.sh | 1 + ci/buildenv/debian-12.sh | 1 + ci/buildenv/debian-sid-cross-aarch64.sh | 1 + ci/buildenv/debian-sid-cross-armv6l.sh | 1 + ci/buildenv/debian-sid-cross-armv7l.sh | 1 + ci/buildenv/debian-sid-cross-i686.sh | 1 + ci/buildenv/debian-sid-cross-mips64el.sh | 1 + ci/buildenv/debian-sid-cross-ppc64le.sh | 1 + ci/buildenv/debian-sid-cross-s390x.sh | 1 + ci/buildenv/debian-sid.sh | 1 + ci/buildenv/fedora-38-cross-mingw32.sh | 1 + ci/buildenv/fedora-38-cross-mingw64.sh | 1 + ci/buildenv/fedora-38.sh | 1 + ci/buildenv/fedora-39.sh | 1 + ci/buildenv/fedora-rawhide-cross-mingw32.sh | 1 + ci/buildenv/fedora-rawhide-cross-mingw64.sh | 1 + ci/buildenv/fedora-rawhide.sh | 1 + ci/buildenv/opensuse-leap-15.sh | 1 + ci/buildenv/opensuse-tumbleweed.sh | 1 + ci/buildenv/ubuntu-2004.sh | 1 + ci/buildenv/ubuntu-2204.sh | 1 + ci/containers/almalinux-8.Dockerfile | 1 + ci/containers/alpine-319.Dockerfile | 1 + ci/containers/alpine-edge.Dockerfile | 1 + ci/containers/centos-stream-8.Dockerfile | 1 + ci/containers/centos-stream-9.Dockerfile | 1 + ci/containers/debian-11-cross-aarch64.Dockerfile | 3 ++- ci/containers/debian-11-cross-armv6l.Dockerfile | 3 ++- ci/containers/debian-11-cross-armv7l.Dockerfile | 3 ++- ci/containers/debian-11-cross-i686.Dockerfile | 3 ++- ci/containers/debian-11-cross-mips64el.Dockerfile | 3 ++- ci/containers/debian-11-cross-mipsel.Dockerfile | 3 ++- ci/containers/debian-11-cross-ppc64le.Dockerfile | 3 ++- ci/containers/debian-11-cross-s390x.Dockerfile | 3 ++- ci/containers/debian-11.Dockerfile | 1 + ci/containers/debian-12-cross-aarch64.Dockerfile | 3 ++- ci/containers/debian-12-cross-armv6l.Dockerfile | 3 ++- ci/containers/debian-12-cross-armv7l.Dockerfile | 3 ++- ci/containers/debian-12-cross-i686.Dockerfile | 3 ++- ci/containers/debian-12-cross-mips64el.Dockerfile | 3 ++- ci/containers/debian-12-cross-mipsel.Dockerfile | 3 ++- ci/containers/debian-12-cross-ppc64le.Dockerfile | 3 ++- ci/containers/debian-12-cross-s390x.Dockerfile | 3 ++- ci/containers/debian-12.Dockerfile | 1 + ci/containers/debian-sid-cross-aarch64.Dockerfile | 3 ++- ci/containers/debian-sid-cross-armv6l.Dockerfile | 3 ++- ci/containers/debian-sid-cross-armv7l.Dockerfile | 3 ++- ci/containers/debian-sid-cross-i686.Dockerfile | 3 ++- ci/containers/debian-sid-cross-mips64el.Dockerfile | 3 ++- ci/containers/debian-sid-cross-ppc64le.Dockerfile | 3 ++- ci/containers/debian-sid-cross-s390x.Dockerfile | 3 ++- ci/containers/debian-sid.Dockerfile | 1 + ci/containers/fedora-38-cross-mingw32.Dockerfile | 3 ++- ci/containers/fedora-38-cross-mingw64.Dockerfile | 3 ++- ci/containers/fedora-38.Dockerfile | 1 + ci/containers/fedora-39.Dockerfile | 1 + ci/containers/fedora-rawhide-cross-mingw32.Dockerfile | 3 ++- ci/containers/fedora-rawhide-cross-mingw64.Dockerfile | 3 ++- ci/containers/fedora-rawhide.Dockerfile | 1 + ci/containers/opensuse-leap-15.Dockerfile | 1 + ci/containers/opensuse-tumbleweed.Dockerfile | 1 + ci/containers/ubuntu-2004.Dockerfile | 1 + ci/containers/ubuntu-2204.Dockerfile | 1 + ci/lcitool/projects/libvirt+minimal.yml | 2 +- ci/lcitool/projects/libvirt.yml | 5 +++-- 86 files changed, 115 insertions(+), 30 deletions(-) -- 2.43.0

3 4