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)? > With regards, > Daniel Thanks, Pierrick
