On 9/23/2026 5:13 AM, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2026 at 12:03:59PM -0700, Pierrick Bouvier wrote: >> 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. > > FYI, it is merged now. >
Thanks, I'll update series today. > With regards, > Daniel
