[RFC][PATCH] Update to container images to Debian 13

[Jan Kiszka]

From: Jan Kiszka <jan.k...@siemens.com>

This brings newer compilers, relevant - or challenging - for yocto
builds, and otherwise just minor dependency adjustments.

Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---

I'd like to hear from affected parties whether such a bump is manageable
- e.g. also with the help of the now added buildtools support - or still
too restricting. If you couldn't follow this update, you would have to
stay on 4.x for which we do not have a stable plan yet.

Dockerfile | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Dockerfile b/Dockerfile
index e4ac8b4..716e060 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,7 +1,7 @@
#
# kas - setup tool for bitbake based projects
#
-# Copyright (c) Siemens AG, 2017-2024
+# Copyright (c) Siemens AG, 2017-2025
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
@@ -21,14 +21,14 @@
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.

-ARG DEBIAN_TAG=bookworm-slim
+ARG DEBIAN_TAG=trixie-slim

FROM debian:${DEBIAN_TAG} AS kas-base

ARG SOURCE_DATE_EPOCH
ARG CACHE_SHARING=locked

-ARG DEBIAN_TAG=bookworm-slim
+ARG DEBIAN_TAG=trixie-slim
ENV DEBIAN_BASE_IMAGE_TAG=${DEBIAN_TAG}

ARG TARGETPLATFORM
@@ -106,7 +106,7 @@ RUN --mount=type=cache,target=/var/cache/apt,sharing=${CACHE_SHARING} \
apt-get update && \
apt-get install -y -f --no-install-recommends \
binfmt-support bzip2 mmdebstrap arch-test apt-utils dosfstools \
- dpkg-dev gettext-base git mtools parted python3 python3-distutils \
+ dpkg-dev gettext-base git mtools parted python3 \
quilt qemu-user-static reprepro sudo unzip git-buildpackage \
pristine-tar sbuild schroot zstd \
umoci skopeo \
@@ -138,8 +138,8 @@ RUN --mount=type=cache,target=/var/cache/apt,sharing=${CACHE_SHARING} \
apt-get install --no-install-recommends -y \
gawk wget git diffstat unzip texinfo \
gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
- xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
- pylint xterm python3-subunit mesa-common-dev zstd liblz4-tool && \
+ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1 libsdl1.2-dev \
+ pylint xterm python3-subunit mesa-common-dev zstd lz4 && \
if [ "$TARGETPLATFORM" = "linux/amd64" ]; then \
apt-get install --no-install-recommends -y gcc-multilib g++-multilib; \
fi && \
--
2.51.0

[MOESSBAUER, Felix]

On Mon, 2025-09-15 at 16:20 +0200, 'Jan Kiszka' via kas-devel wrote:
> From: Jan Kiszka <jan.k...@siemens.com>
>
> This brings newer compilers, relevant - or challenging - for yocto
> builds, and otherwise just minor dependency adjustments.

This brings memories back: When switching from bullseye to bookworm, I
noticed that many of the kas forks reverted the change as Yocto did not
support the platform (yet).

Back then I started working on multi-image support, but the differences
between bullseye and bookworm were big and testing this remained a
blocker.

I just gave the old series a revive and tested it on trixie - which
seemed to work out of the box. In addition, we now have a significantly
better CI coverage of the container, so testing is hopefully not a
blocker anymore.

I'll send out the series by today.

If you are interested in multi-distro (version) support as well, please
speak up. This helps us to prioritize things.

These changes also work on bookworm.

> quilt qemu-user-static reprepro sudo unzip git-buildpackage \
> pristine-tar sbuild schroot zstd \
> umoci skopeo \
> @@ -138,8 +138,8 @@ RUN --mount=type=cache,target=/var/cache/apt,sharing=${CACHE_SHARING} \
> apt-get install --no-install-recommends -y \
> gawk wget git diffstat unzip texinfo \
> gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
> - xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
> - pylint xterm python3-subunit mesa-common-dev zstd liblz4-tool && \
> + xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1 libsdl1.2-dev \
> + pylint xterm python3-subunit mesa-common-dev zstd lz4 && \

Same here. Please split the commit into the general dependency update
and the update of the DEBIAN_TAG.

Best regards,
Felix

> if [ "$TARGETPLATFORM" = "linux/amd64" ]; then \
> apt-get install --no-install-recommends -y gcc-multilib g++-multilib; \
> fi && \
> --
> 2.51.0
>

> --
> You received this message because you are subscribed to the Google Groups "kas-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kas-devel+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/kas-devel/ce0411e6-f52e-4bd0-8186-a5eff36f4787%40siemens.com.

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

[Jan Kiszka]

On 16.09.25 10:56, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Mon, 2025-09-15 at 16:20 +0200, 'Jan Kiszka' via kas-devel wrote:
>> From: Jan Kiszka <jan.k...@siemens.com>
>>
>> This brings newer compilers, relevant - or challenging - for yocto
>> builds, and otherwise just minor dependency adjustments.
>
> This brings memories back: When switching from bullseye to bookworm, I
> noticed that many of the kas forks reverted the change as Yocto did not
> support the platform (yet).
>
> Back then I started working on multi-image support, but the differences
> between bullseye and bookworm were big and testing this remained a
> blocker.
>
> I just gave the old series a revive and tested it on trixie - which
> seemed to work out of the box. In addition, we now have a significantly
> better CI coverage of the container, so testing is hopefully not a
> blocker anymore.
>
> I'll send out the series by today.

I thought about that a bit, but I failed to imagine a handy naming
scheme if a single kas version will have kas and kas-isar in two flavors
for that same version.

>
> If you are interested in multi-distro (version) support as well, please
> speak up. This helps us to prioritize things.
>

I just started inside Siemens a questionnaire about the same topic,
please answer here as well:

Is there a need for multiple kas release lines?

1. Yes, I need newer kas features in older Debian containers

2. Yes, but I only need stable updates (bug fixes, security updates) for
kas and the related Debian container

3. No, I'm only updating kas in lock-step with isar and do not change
the build container for older versions anymore

Only few replies internally yet, but all for option 3 so far.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center