On 2026-09-22 19:35, Daniel P. Berrangé wrote:
On Tue, Sep 22, 2026 at 10:16:27AM -0700, Pierrick Bouvier wrote:
On 9/22/2026 9:54 AM, Daniel P. Berrangé wrote:
On Tue, Sep 22, 2026 at 09:15:02AM -0700, Pierrick Bouvier wrote:
On 9/21/2026 4:14 PM, Pierrick Bouvier wrote:
latest update of libvirt-ci changed packages, but images were not
refreshed.
Signed-off-by: Pierrick Bouvier <[email protected]>
---
tests/docker/dockerfiles/debian.docker | 1 -
tests/docker/dockerfiles/ubuntu2404.docker | 1 -
2 files changed, 2 deletions(-)
diff --git a/tests/docker/dockerfiles/debian.docker
b/tests/docker/dockerfiles/debian.docker
index 77869f71546..2d03ff03c8d 100644
--- a/tests/docker/dockerfiles/debian.docker
+++ b/tests/docker/dockerfiles/debian.docker
@@ -73,7 +73,6 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
libpcre2-dev \
libpipewire-0.3-dev \
libpixman-1-dev \
- libpmem-dev \
libpng-dev \
libpulse-dev \
librbd-dev \
diff --git a/tests/docker/dockerfiles/ubuntu2404.docker
b/tests/docker/dockerfiles/ubuntu2404.docker
index bb8f4e4e53f..440699a5005 100644
--- a/tests/docker/dockerfiles/ubuntu2404.docker
+++ b/tests/docker/dockerfiles/ubuntu2404.docker
@@ -73,7 +73,6 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
libpcre2-dev \
libpipewire-0.3-dev \
libpixman-1-dev \
- libpmem-dev \
libpng-dev \
libpulse-dev \
librbd-dev \
Dropping this patch, as it's incorrect.
In libvirt-ci, libpmem-dev is a dependency of targets debian-13 and
ubuntu2404, so not sure why it removes it here. Seems like a bug in
libvirt-ci itself.
Most likely you ran invoked lcitool from an aarch64 host OS, so it
filtered out libpmem-dev which is only valid on x86_64 targets.
The non-cross containers we have defined here are assumed to be
for x86_64 targets.
We should change the tests/lcitool/refresh script in QEMU to pass
'--host-arch x86_64' to lcitool, rather than defaulting to the
developers' machine's arch.
Thanks for the sharing the reason, I'll add this option.
Out of curiosity, what's the reason to differentiate generation based on
host arch?
Wouldn't that be better to be explicit if you want to generate an arch
specific Dockerfile (and use FROM docker.io/arch/... instead of
docker.io/library)?
I'm not familiar with docker.io/arch/
IIRC this was not available back then when lcitool was started.
but this all just grew up
organically over time, and since most usage was x86_64 host based
there was not much need to think about other scenarios.
If we want the tests/docker/dockerfiles to be portable to non-x86
hosts, then we'd need to either have many dockerfiles there for
each arch, or drop packages that are arch specific from the
install list.
With regards,
Daniel
