[PATCH] Dockerfile: Fix broken bullseye based build

[Mehmet Bulut]

Hi gents,

Building the docker image with DEBIAN_TAG=bullseye-slim, fails with

python3-kconfiglib and python3-shtab packages not available
pip3 install does not know --break-system-packages yet

This change adds two intermediate conditional layers before the kas-base
layer in which the differences are handled based on what Debian version
we're dealing with.

github PR: https://github.com/siemens/kas/pull/119

Cheers
Mehmet

From ecd6008e04aa228c55df9fda7898a15e67890438 Mon Sep 17 00:00:00 2001
From: Mehmet Bulut <ma...@mehmetbulut.de>
Date: Sun, 26 May 2024 06:52:15 +0200
Subject: [PATCH] Dockerfile: Fix broken bullseye based build

---
Dockerfile | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/Dockerfile b/Dockerfile
index dfebca2..1ae3b24 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -23,7 +23,7 @@

ARG DEBIAN_TAG=bookworm-slim

-FROM debian:${DEBIAN_TAG} as kas-base
+FROM debian:${DEBIAN_TAG} as kas-base-conditional

ARG SOURCE_DATE_EPOCH
ARG CACHE_SHARING=locked
@@ -48,10 +48,10 @@ RUN
--mount=type=cache,target=/var/cache/apt,sharing=${CACHE_SHARING} \
localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias
en_US.UTF-8 && \
apt-get install --no-install-recommends -y \
python3-pip python3-setuptools python3-wheel python3-yaml
python3-distro python3-jsonschema \
- python3-newt python3-colorlog python3-kconfiglib
python3-websockets \
+ python3-newt python3-colorlog python3-websockets \
gosu lsb-release file vim less procps tree tar bzip2 zstd pigz
lz4 unzip tmux libncurses-dev \
git-lfs mercurial iproute2 ssh-client telnet curl rsync gnupg
awscli sudo \
- socat bash-completion python3-shtab python3-git && \
+ socat bash-completion python3-git && \
rm -rf /var/log/* /tmp/* /var/tmp/* /var/cache/ldconfig/aux-cache && \
rm -f /etc/gitconfig && \
git config --system filter.lfs.clean 'git-lfs clean -- %f' && \
@@ -59,12 +59,23 @@ RUN
--mount=type=cache,target=/var/cache/apt,sharing=${CACHE_SHARING} \
git config --system filter.lfs.process 'git-lfs filter-process' && \
git config --system filter.lfs.required true

+FROM kas-base-conditional as kas-base-bookworm-slim
+RUN apt-get update && \
+ apt-get install --no-install-recommends -y python3-kconfiglib
python3-shtab
+ENV PIP3_EXTRA_ARGS="--break-system-packages"
+FROM kas-base-conditional as kas-base-bullseye-slim
+RUN curl
http://ftp.de.debian.org/debian/pool/main/k/kconfiglib/python3-kconfiglib_14.1.0-3_all.deb
-o /tmp/python3-kconfiglib.deb && \
+ curl
http://ftp.de.debian.org/debian/pool/main/p/python-shtab/python3-shtab_1.5.5-3_all.deb
-o /tmp/python3-shtab.deb && \
+ dpkg -i /tmp/python3-kconfiglib.deb /tmp/python3-shtab.deb && \
+ rm /tmp/python3-kconfiglib.deb /tmp/python3-shtab.deb
+FROM kas-base-${DEBIAN_TAG} as kas-base
+
COPY . /kas

RUN pip3 --proxy=$https_proxy install \
--no-deps \
--no-build-isolation \
- --break-system-packages \
+ ${PIP3_EXTRA_ARGS} \
/kas && \
install -d /usr/local/share/bash-completion/completions/ && \
shtab --shell=bash -u kas.kas.kas_get_argparser
--error-unimportable --prog kas \
--
2.34.1

[Mehmet Bulut]

Oops, sent it with wrong email account -- here's the right one :)

[Jan Kiszka]

Moin Mehmet,

thanks for your contribution! There are some open points, though.

On 26.05.24 07:16, Mehmet Bulut wrote:

> Hi gents,
>
> Building the docker image with DEBIAN_TAG=bullseye-slim, fails with
>
>     python3-kconfiglib and python3-shtab packages not available
>     pip3 install does not know --break-system-packages yet
>
> This change adds two intermediate conditional layers before the kas-base
> layer in which the differences are handled based on what Debian version
> we're dealing with.
>
> github PR: https://github.com/siemens/kas/pull/119
>
> Cheers
> Mehmet
>
> From ecd6008e04aa228c55df9fda7898a15e67890438 Mon Sep 17 00:00:00 2001
> From: Mehmet Bulut <ma...@mehmetbulut.de>
> Date: Sun, 26 May 2024 06:52:15 +0200
> Subject: [PATCH] Dockerfile: Fix broken bullseye based build
>

You are missing the reason for this change here, in the commit message.

Do you want to build an oldish yocto that doesn't work with gcc from
bookworm, but you also need latest kas features? Can't use a different
toolchain insteand of Debian's? kas officially stopped support for
bullseye with the switch to version 3, and before re-enabling this, even
just for custom builds, we need to understand to motivation fairly well.

And we would need the signed-off here, see CONTRIBUTING.md

This will break once upstream updates the packages and drops these
versions from the archive. You need stable links, e.g. from
snapshot[-cloudflare].debian.org.

> +   dpkg -i /tmp/python3-kconfiglib.deb /tmp/python3-shtab.deb && \

This doesn't validate the signature of the installed packages regarding
authenticity.

> +   rm /tmp/python3-kconfiglib.deb /tmp/python3-shtab.deb
> +FROM kas-base-${DEBIAN_TAG} as kas-base

And this breaks our normal builds because we use snapshots of
debian-slim by now, see e.g.
https://github.com/siemens/kas/actions/runs/9225801944/job/25384197236#step:4:158
("DEBIAN_TAG=bookworm-20240513-slim). Needed for reproducibility.

> +
>  COPY . /kas
>
>  RUN pip3 --proxy=$https_proxy install \
>          --no-deps \
>          --no-build-isolation \
> -        --break-system-packages \
> +        ${PIP3_EXTRA_ARGS} \
>          /kas && \
>      install -d /usr/local/share/bash-completion/completions/ && \
>      shtab --shell=bash -u kas.kas.kas_get_argparser
> --error-unimportable --prog kas \

Jan

--
Siemens AG, Technology
Linux Expert Center

[Mehmet Bulut]

Servus Jan,

yes, indeed I need to build a custom yocto which seems to be based on
kirkstone-4.0.5 or earlier which requires an older version of glibc
(uninative complains) and git (support for git submodule--helper list
was dropped in git).

I didn't know about custom toolchain support in kas, so my toolchain
problem could probably be solved by that but I'd still need to have a
different git version... Of course there are other options to deal with
that but when I looked at the kas Dockerfile I saw the DEBIAN_TAG
argument and thought I could just build the container based off bullseye
but didn't work for reasons stated in the commit message.

I understand that kas has moved on but don't you think that we shouldn't
drop support for distros which are still supported by YP/OE?

[Mehmet Bulut]

That said, to be honest, I did this change to get myself going in the
first place but later thought it could be useful for others, too.

The issues you mentioned below about stable links, deb verification
(tough one as deb packages aren't signed) and
snapshot builds can be solved but before I spend time on that it'd be
cool to know if there's interest at all to merge
this after what you said about not supporting bullseye...

Mehmet

[MOESSBAUER, Felix]

On Sun, 2024-05-26 at 15:04 +0200, Mehmet Bulut wrote:
> That said, to be honest, I did this change to get myself going in the
> first place but later thought it could be useful for others, too.
>
> The issues you mentioned below about stable links, deb verification
> (tough one as deb packages aren't signed) and
> snapshot builds can be solved but before I spend time on that it'd be
> cool to know if there's interest at all to merge
> this after what you said about not supporting bullseye...

Hi, if there is a broader user group needing a bullseye container, I'm
sure we can provide one. A couple weeks ago I discussed the option to
provide backports of the kas container for older distributions with
Jan. For that we basically have two options:

1. Backport new kas features to the existing 3.x releases
2. Take the 4.x releases and make them compatible with bullseye

With the recent improvements o the docker build of the kas container
(reproducible builds, attestations), I prefer to go with option 2.

>
> Mehmet
>
> On 26.05.24 14:25, Mehmet Bulut wrote:
> > Servus Jan,
> >
> > yes, indeed I need to build a custom yocto which seems to be based
> > on
> > kirkstone-4.0.5 or earlier which requires an older version of glibc
> > (uninative complains) and git (support for git submodule--helper
> > list
> > was dropped in git).

Is this a general kirkstone requirement, or just of your layers? As
kirkstone reaches EOL in April 2026, it makes sense to support that
with the most-recent kas version till that date as well.

> >
> > I didn't know about custom toolchain support in kas, so my
> > toolchain
> > problem could probably be solved by that but I'd still need to have
> > a
> > different git version... Of course there are other options to deal
> > with that but when I looked at the kas Dockerfile I saw the
> > DEBIAN_TAG
> > argument and thought I could just build the container based off
> > bullseye but didn't work for reasons stated in the commit message.

The intention of the tag was to just select the bookworm snapshot
version (or just "bookworm"). Maybe we should document that to make it
more clear.

Anyways, I prefer to have a dedicated (and maintained) bullseye branch
instead of sprinkling if/else across the Dockerfile.

> >
> > I understand that kas has moved on but don't you think that we
> > shouldn't drop support for distros which are still supported by
> > YP/OE?

Yes, I agree we shouldn't do that.

Until this is sorted out, I recommend to just use the 3.3 release ;)

Cheers!
Felix

[Mehmet Bulut]

Hey Felix,

thx for the insights, see my comments inline

On 26.05.24 18:57, MOESSBAUER, Felix wrote:
> On Sun, 2024-05-26 at 15:04 +0200, Mehmet Bulut wrote:
>> That said, to be honest, I did this change to get myself going in the
>> first place but later thought it could be useful for others, too.
>>
>> The issues you mentioned below about stable links, deb verification
>> (tough one as deb packages aren't signed) and
>> snapshot builds can be solved but before I spend time on that it'd be
>> cool to know if there's interest at all to merge
>> this after what you said about not supporting bullseye...
> Hi, if there is a broader user group needing a bullseye container, I'm
> sure we can provide one. A couple weeks ago I discussed the option to
> provide backports of the kas container for older distributions with
> Jan. For that we basically have two options:
>
> 1. Backport new kas features to the existing 3.x releases
> 2. Take the 4.x releases and make them compatible with bullseye
>
> With the recent improvements o the docker build of the kas container
> (reproducible builds, attestations), I prefer to go with option 2.

(2) sounds reasonable for me, too.

>> Mehmet
>>
>> On 26.05.24 14:25, Mehmet Bulut wrote:
>>> Servus Jan,
>>>
>>> yes, indeed I need to build a custom yocto which seems to be based
>>> on
>>> kirkstone-4.0.5 or earlier which requires an older version of glibc
>>> (uninative complains) and git (support for git submodule--helper
>>> list
>>> was dropped in git).
> Is this a general kirkstone requirement, or just of your layers? As
> kirkstone reaches EOL in April 2026, it makes sense to support that
> with the most-recent kas version till that date as well.

Later releases of kirkstone have already adopted the git change, however
the project I'm currently working on uses an own "fork" that's not that
far yet -- complicated story...

>>> I didn't know about custom toolchain support in kas, so my
>>> toolchain
>>> problem could probably be solved by that but I'd still need to have
>>> a
>>> different git version... Of course there are other options to deal
>>> with that but when I looked at the kas Dockerfile I saw the
>>> DEBIAN_TAG
>>> argument and thought I could just build the container based off
>>> bullseye but didn't work for reasons stated in the commit message.
> The intention of the tag was to just select the bookworm snapshot
> version (or just "bookworm"). Maybe we should document that to make it
> more clear.

Yeah I figured that after Jan's comment :)

> Anyways, I prefer to have a dedicated (and maintained) bullseye branch
> instead of sprinkling if/else across the Dockerfile.

That's fair enough -- the multistage directives I used to hack the
condition has its limitations and we would probably have to resort to
ugly bash if-else'ing in order to satisfy any DEBIAN_TAG not covered in

the Dockerfile.

>>> I understand that kas has moved on but don't you think that we
>>> shouldn't drop support for distros which are still supported by
>>> YP/OE?
> Yes, I agree we shouldn't do that.
>
> Until this is sorted out, I recommend to just use the 3.3 release ;)

I think I can live with that :)

Enjoy the rest of your Sunday!
Mehmet

[Jan Kiszka]

I would consider doing some kind of LTS for the old branch or even
making the current one longer available also with an older Debian base,
but folks in need of this have to raise their voices. Without users,
even widely automated maintenance is still too much of invest.