Re: [PATCH 4/5] CI: Add a Debian 13 (Trixie) arm64 container

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/05/2026 7:32 am, Orzel, Michal wrote:
>
> On 11-May-26 11:21, Andrew Cooper wrote:
>> On 11/05/2026 7:29 am, Orzel, Michal wrote:
>>> On 08-May-26 23:29, Andrew Cooper wrote:
>>>> Exactly as per the Bookworm container, but additionally with the ipxe-qemu 
>>>> and
>>>> qemu-system-aarch64 packages.  These will be used to remove the export 
>>>> jobs.
>>>>
>>>> Switch qemu-arm{32,64} jobs to use this container.
>>>>
>>>> No functional change.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> ---
>>>> CC: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>>> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> CC: Michal Orzel <michal.orzel@xxxxxxx>
>>>> CC: Doug Goldstein <cardoe@xxxxxxxxxx>
>>>>
>>>> We should probably wire up some build tests too, but it's too late on a 
>>>> Friday
>>>> for me to be thinking about that for this posting.
>>>> ---
>>>>  automation/build/debian/13-arm64v8.dockerfile | 71 +++++++++++++++++++
>>>>  automation/gitlab-ci/test.yaml                |  4 +-
>>>>  automation/scripts/containerize               |  1 +
>>>>  3 files changed, 74 insertions(+), 2 deletions(-)
>>>>  create mode 100644 automation/build/debian/13-arm64v8.dockerfile
>>>>
>>>> diff --git a/automation/build/debian/13-arm64v8.dockerfile 
>>>> b/automation/build/debian/13-arm64v8.dockerfile
>>>> new file mode 100644
>>>> index 000000000000..b9062ee8b443
>>>> --- /dev/null
>>>> +++ b/automation/build/debian/13-arm64v8.dockerfile
>>>> @@ -0,0 +1,71 @@
>>>> +# syntax=docker/dockerfile:1
>>>> +FROM --platform=linux/arm64/v8 debian:trixie-slim
>>>> +LABEL maintainer.name="The Xen Project"
>>>> +LABEL maintainer.email="xen-devel@xxxxxxxxxxxxxxxxxxxx"
>>>> +
>>>> +ENV DEBIAN_FRONTEND=noninteractive
>>>> +
>>>> +RUN <<EOF
>>>> +#!/bin/bash
>>>> +    set -eu
>>>> +
>>>> +    useradd --create-home user
>>>> +
>>>> +    apt-get update
>>>> +
>>>> +    DEPS=(
>>>> +        # Xen
>>>> +        bison
>>>> +        build-essential
>>>> +        checkpolicy
>>>> +        flex
>>>> +
>>>> +        # Tools (general)
>>>> +        ca-certificates
>>>> +        cpio
>>>> +        git-core
>>>> +        pkg-config
>>>> +        wget
>>>> +        # libxenguest dombuilder
>>>> +        libbz2-dev
>>>> +        liblzma-dev
>>>> +        liblzo2-dev
>>>> +        libzstd-dev
>>>> +        zlib1g-dev
>>>> +        # libacpi
>>>> +        acpica-tools
>>>> +        # libxl
>>>> +        libfdt-dev
>>>> +        libjson-c-dev
>>>> +        uuid-dev
>>>> +        # xentop
>>>> +        libncurses5-dev
>>>> +        # Python bindings
>>>> +        python3-dev
>>>> +        python3-setuptools
>>>> +        # Golang bindings
>>>> +        golang-go
>>>> +        # Ocaml bindings/oxenstored
>>>> +        ocaml-nox
>>>> +        ocaml-findlib
>>> Since this is a container used only for tests, why listing packages 
>>> required for
>>> Xen and tools build?
>> I did leave a note about that.
>>
>>>> +
>>>> +        # for test phase, qemu-* jobs
>>>> +        busybox-static
>>>> +        curl
>>>> +        device-tree-compiler
>>>> +        expect
>>>> +        file
>>>> +        ipxe-qemu
>>>> +        ovmf
>>>> +        qemu-system-aarch64
>>>> +        u-boot-qemu
>>>> +        u-boot-tools
>>> So after this change, even though you replace debian-12 with debian-13 for 
>>> all
>>> the tests, the debian-12 still contains the unneeded packages (i.e. for a 
>>> test
>>> phase that it no longer runs).
>> Yes.  I can't do this series bisectably without it.  Also, in the past
> Ok, I understand the bisectibility problem.

On further thought, I can in principle fix bisectibility by introducing
Trixie first, but that loses the logical sequence of events somewhat.

>> people have explicitly requested to be able to run the qemu smoke
>> testing from the build container, which is why it's like this and not split.
> Unless it's a rule that every container follows and is documented somewhere I
> don't like this argument.

It was explicitly requested by ARM, and accepted at a time.

If you'd like to revisit this decision, that's also fine too, but I
don't want to be flip-flopping on it.

I could:
1) Make a 13-arm64v8-test.dockerfile containing only the test phase stuff
2) Switch to this ahead of the 12 cleanup
3) Do the 12 cleanup without the test phase stuff

although this makes a new scheme that we haven't used before.

The one thing to say.  It's almost always safe to add packages to an
existing container, but ...

> My plan then is to do the clean up of Arm containers
> in the future to remove packages not used.

... you can't remove packages from an existing container.  The
containers are shared by all stable branches, and you'll generally break
older branches by doing this.

Where we have dropped dependences, e.g. ae26101f6bfc, I've commented the
dockerfile so it doesn't get copied forwards into a new container, and
can be dropped when the identified version falls out of stable support.

a0e29b316 is an example where the containers did get rebuilt after the
version of Xen ceased being tested.

>  It creates more confusion for people
> willing to create their own dockerfiles for testing (or just to see what it
> takes to build e.g. Xen on Arm) than it gives benefits.

That's why the dependencies are grouped and labelled.  I do expect
people to be able to figure out the bits they don't need based on the
comments.

>> Honestly, I was hoping to leave the Trixie update to the ARM
>> maintainers, but despite the Bookworm QEMU (7.2) being newer than the
>> 6.0 in the export jobs, it contains the SYSREG interception bugs which
>> prevents hiding ThumbEE from guests, and breaks all the arm32 testing
>> with a Linux dom0.
> Does it make sense to have both Debian 12 and Debian 13 build/test? Can't we
> have just the latest one?

Build, yes absolutely.  You want as wider range of compilers/toolchains
as possible.

Test, we tend to only do one.  For x86 it's the alpine build; for ARM,
it's from the Debian build.

> All of the remarks above are not something that should prevent this patch from
> going in, so:
> Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx>

Thanks, but lets see about the latest proposal first.

~Andrew