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/ 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 -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
