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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 13/05/2026 11:58 am, Andrew Cooper wrote:
> 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.

I'm folding in the following hunk:

diff --git a/automation/gitlab-ci/build.yaml
b/automation/gitlab-ci/build.yaml
index 128b5f45cbad..a1acf2e827df 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -424,6 +424,16 @@ debian-12-arm64-gcc-debug:
   variables:
     CONTAINER: debian:12-arm64v8
 
+debian-13-arm64-gcc:
+  extends: .gcc-arm64-build
+  variables:
+    CONTAINER: debian:13-arm64v8
+
+debian-13-arm64-gcc-debug:
+  extends: .gcc-arm64-build-debug
+  variables:
+    CONTAINER: debian:13-arm64v8
+
 alpine-3.18-gcc-arm64:
   extends: .gcc-arm64-build
   <<: *build-test


which performs some build testing using this container too.  Full
resulting pipeline:

https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2562180822

~Andrew