On 9/22/2026 12:01 PM, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2026 at 11:33:47AM -0700, Pierrick Bouvier wrote: >> On 9/22/2026 11:29 AM, Daniel P. Berrangé wrote: >>> On Tue, Sep 22, 2026 at 11:22:43AM -0700, Pierrick Bouvier wrote: >>>> On 9/22/2026 11:04 AM, Daniel P. Berrangé wrote: >>>>> On Tue, Sep 22, 2026 at 06:55:18PM +0100, Daniel P. Berrangé wrote: >>>>>> On Mon, Sep 21, 2026 at 11:14:54PM +0000, Pierrick Bouvier wrote: >>>>>>> We'll use this in next patch to switch FROM docker.io/library to >>>>>>> docker.io/amd64. It would not make sense to add a new target to >>>>>>> libvirt-ci for this, since it's just a variant of an existing target. >>>>>>> Simply replace container registry with arch specific one. >>>>>> >>>>>> We shouldn't need to add new targets to lcitool for this, >>>>>> rather it would be enhanced to include a list of arch >>>>>> specific container images. >>>>>> >>>>>> eg in >>>>>> >>>>>> https://gitlab.com/libvirt/libvirt-ci/-/blob/master/lcitool/facts/targets/debian-13.yml?ref_type=heads >>>>>> >>>>>> We would extend: >>>>>> >>>>>> containers: >>>>>> base: docker.io/library/debian:13-slim >>>>>> >>>>>> to allow for >>>>>> >>>>>> containers: >>>>>> base: docker.io/library/debian:13-slim >>>>>> aarch64: docker.io/amd64/debian:13-slim >>>>>> ...more... >>>>>> >>>>>> such that we default to the 'base' image name, unless >>>>>> there is an arch specific name defined. That would be >>>>>> a fairly quick extension to impl in lcitool. >>>>> >>>>> Quicker than I thought.... take a look at this, which >>>>> I think will enable you to drop this patch and the >>>>> next one and get the same end result: >>>>> >>>>> https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/588 >>>>> >>>> >>>> Very quick indeed, good job :) >>>> >>>> IIUC, when no host-arch is given, we keep on using base, but in case >>>> user specifies -host-arch, in this case we use one of specialized image >>>> (if available)? >>> >>> Actually it is indepedent of --host-arch. >>> >>> If --host-arch is omitted we default it to what uname() reports, >>> and the result then goes into the container image lookup, which >>> is optionally specialized per arch. >>> >> >> It works for QEMU needs, but would that be a safe default for other >> users of lcitool? > > Yes, I think it ought to be OK. If something unexpected crops up > we'll deal with it as needed. > >> Technically, you can write portable Dockerfiles between arch. Our >> current debian-all-test is kind of an example of it (ignoring the change >> this series does). > > True, but lcitool isn't guaranteeing it can be done, as we allow > output to filter per-arch, so there's always the risk of getting > the libpmem situation - IIRC it hits with 'xen-devel' too as some > arches lack Xen. > > So realistically I think we would say lcitool container outputs > are arch specific. >
I'm good with this assumption. There are always small details that makes it hard to have truly portable Dockerfiles. I'll wait for PR to be merged on libvirt-ci, then update current series with it for v2. > With regards, > Daniel Thanks for the help on this, Pierrick
