On 1/2/24 19:19, Philippe Mathieu-Daudé wrote: > On 12/7/23 15:07, Daniel P. Berrangé wrote: >> On Wed, Jul 12, 2023 at 02:55:10PM +0200, Philippe Mathieu-Daudé wrote: >>> On 12/7/23 13:12, Daniel P. Berrangé wrote: >>>> On Wed, Jul 12, 2023 at 01:00:38PM +0200, Philippe Mathieu-Daudé wrote: >>>>> On 11/7/23 19:58, Daniel P. Berrangé wrote: >>>>>> On Tue, Jul 11, 2023 at 04:49:20PM +0200, Philippe Mathieu-Daudé wrote: >>>>>>> Refresh the generated files by running: >>>>>>> >>>>>>> $ make lcitool-refresh >>>>>>> >>>>>>> Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org> >>>>>>> --- >>>>>>> tests/docker/dockerfiles/debian-amd64.docker | 2 - >>>>>>> tests/docker/dockerfiles/ubuntu2004.docker | 2 - >>>>>>> tests/docker/dockerfiles/ubuntu2204.docker | 2 - >>>>>> >>>>>> I don't know why this would be removing xen/pmem from these files. If >>>>>> I run 'lcitool-refresh' on current git master that doesn't happen > > FTR since commit cb039ef3d9 libxdp-devel is also being changed on my > host, similarly to libpmem-devel, so I suppose it also has some host > specific restriction.
Yeah, many distributions are not building libxdp for non-x86 architectures today. There are no real reasons not to, but they just do not, because the package is relatively new. It will likely become available in the future. I see this thread is a bit old. Was a solution found for the pmem/xen? i.e. do I need to do something specific for libxdp at this point? Best regards, Ilya Maximets. > >>>>>> Do you have any other local changes on top ? >>> >>> (I just noticed manually updating the libvirt-ci submodule is >>> pointless because the 'lcitool-refresh' rule does that) >>> >>>>> diff --git a/tests/docker/dockerfiles/ubuntu2204.docker >>>>> b/tests/docker/dockerfiles/ubuntu2204.docker >>>>> index 1d442cdfe6..5162927016 100644 >>>>> --- a/tests/docker/dockerfiles/ubuntu2204.docker >>>>> +++ b/tests/docker/dockerfiles/ubuntu2204.docker >>>>> @@ -73 +72,0 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ >>>>> - libpmem-dev \ >>>>> @@ -99 +97,0 @@ RUN export DEBIAN_FRONTEND=noninteractive && \ >>>>> - libxen-dev \ >>>> >>>> What architecture are you running from ? I'm suspecting it is a non >>>> x86_64 architecture as these pacakges are both arch conditionalized. >>> >>> My host is Darwin aarch64, but how is this relevant to what we >>> generate for guests? Are we missing specifying the target arch >>> somewhere? (This is not the '--cross-arch' argument, because we >>> don't want to cross-build). These dockerfiles always targeted x86_64, >>> in particular the debian-amd64.docker one... >> >> This is an unfortunate design choice of lcitool. >> >> If you give '--cross-arch' it will always spit out the dockerfile >> suitable for cross-compiling to that arch. >> >> If you omit '--cross-arch' it will always spit out the dockerfile >> suitable for compiling on the *current* host arch. >> >> When we're committing the dockerfiles to qemu (or any libvirt project >> using lcitool), we've got an implicit assumption that the non-cross >> dockerfiles were for x86_64, and hence an implicit assumption that >> the person who ran 'lcitool' was also on x86_64. >> >> This is clearly a bad design choice mistake in retrospect as people >> are increasingly likely to be using aarch64 for day-to-day dev work. >> >> So I guess we need to come up with a more explicit way to say give >> me a native container for x86_64. >> >> With regards, >> Daniel >
