On 9/22/2026 10:44 AM, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2026 at 10:41:38AM -0700, Pierrick Bouvier wrote: >> On 9/22/2026 10:35 AM, 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/ 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. >>> >> >> Basically, it's (official) docker images per arch, following docker >> platform naming: >> - docker.io/amd64 >> - docker.io/aarch64 >> >> https://github.com/docker-library/official-images#architectures-other-than-amd64 >> >> Advantage is that image are provided for a specific platform, which >> avoid some of the issue multi plaform images have. >> >> For instance, on aarch64 host: >> $ podman run --platform linux/amd64 docker.io/library/debian:latest true >> $ podman run docker.io/library/debian:latest true >> WARNING: image platform (linux/amd64) does not match the expected >> platform (linux/arm64) >> # podman/docker now select the amd64 version by default, which can break >> build of other containers. It's a design issue with docker cli IMHO. >> >>> 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. >>> >> >> I'll add the --host-arch x86_64 option to lcitool as recommended, which >> should be enough for our need. > > Hmm, I think we also need '--arch x86_64' passed to 'docker build' for > similar reasons, since the dockerfile input to the build has an > arch specific list of packages. >
That's what patch 1 is doing, adding --platform to build and run commands 👍. > > With regards, > Daniel
