debian 13 to do

[loosebazooka]

• [x] update bazel deps (except rules_oci)
• [ ] update rules_oci
• [ ] bazel 8.X
• [x] merged usr fs
  • only for debian13 (not 12)
• [ ] ensure no overwrites, all images should have a test that checks for overwrites, update any paths
• [ ] mtime -> 0 (we seem to use a variety of numbers all over the place to minimize diffs)
• [ ] update image diff action

[huakaibird]

when 13 will be released?

[loosebazooka]

I don't have a timeline, hopefully in the next few weeks.

[IanDavey]

Hello,

What is the timeline for release here? My employer is waiting on a production deployment.

Thanks.

[maxime-perocheau-hs]

@loosebazooka is there anything left outstanding for this? Happy to help if I can, would love to see Debian 13 images released!

[jayvdb]

Appears to be happening at https://github.com/GoogleContainerTools/distroless/pull/1850

[harryzcy]

Appears to be happening at #1850

No, it only adds Debian 13 to root-level bazel build. It does not address any of the TODOs listed in this issue.

[nappa85]

Sorry to bother, but any news on this? It's becoming annoying since most of build systems have already increased glibc version and builds won't work with debian 12

[loosebazooka]

I believe @thesayyn is working on it this week

[ndthayer]

@thesayyn , @loosebazooka : Is there an ETA you can share on the debian13 distroless base image being GA?

[loosebazooka]

okay we're buliding static, base, base-nossl debian13 images now -- disclaimer here: https://github.com/GoogleContainerTools/distroless/?tab=readme-ov-file#debian-13-preview

[kyle-leonhard]

@loosebazooka - Thanks for knocking this out! I gave gcr.io/distroless/cc-debian13 a shot. When executing the resulting image, I ran into errors like this: libzstd.so.1: cannot open shared object file: No such file or directory. I was able to apt install bothzlib1g and libzstd1, copy both libz.so.1 and libzstd.so.1 into the final image with cc-debian13 as the base and make things work. With gcr.io/distroless/cc-debian12, the image functioned without separately copying over those shared libraries.

I have no idea whether this is an expected change or not. But I thought I'd report it in case it was unintended! Thanks again

FROM rust:1.90.0AS build
RUN apt-get update && apt-get install -y --no-install-recommends zlib1g libzstd1

# Other stuff...

FROM gcr.io/distroless/cc-debian13
COPY --from=build /lib/*/libz.so.1 /lib/
COPY --from=build /lib/*/libzstd.so.1 /lib/

# Other stuff...

[filipopo]

I tested cc-debian13 on my repo MF-updater and it seems to work, no errors about missing libraries like zlib or whatever

ARG OS_VERSION=13 MODE="standalone"

FROM debian:${OS_VERSION}-slim AS build
ENV DEBIAN_FRONTEND=noninteractive
ARG MODE

COPY updater.py .

RUN apt-get update && \
    apt-get install --no-install-recommends -y \
      ccache \
      gcc \
      make \
      patchelf \
      pipx \
      python3-dev && \
    apt-get clean && rm -rf /var/lib/apt/lists/* && \
    pipx run nuitka \
      --mode=${MODE} \
      --deployment \
      --assume-yes-for-downloads \
      --python-flag=-OO \
      --output-filename=updater-linux-amd64.bin \
      updater.py

FROM gcr.io/distroless/cc-debian${OS_VERSION}:latest

COPY --from=build updater.dist/* /opt/

ENTRYPOINT ["/opt/updater-linux-amd64.bin"]

But since I'm using Nuitka, when python-debian13?

[loosebazooka]

I think for python, maybe we want to try using the python releases from another source (not debian) -- this means we can add support for 3.14 and 3.15 with our debian13 builds. But that might take a little bit.

[piranna]

Deadsnakes, maybe? I like that idea, but then, that would not be the same as a stripped down version of Debian...

[ding-ma]

@loosebazooka can we sync on this? I can show you how we do it at NVIDIA. I'd love to contribute this out so we don't have to maintain the fork. Feel free to shoot my an email ([email protected]) we can setup a quick chat next week. We're also dying to have debian 13 released.

[loosebazooka]

it looks like the folks at astral might have compatible multi-arch builds that we can use. I'll take a look at those in the future or if anyone has time to experiment: https://github.com/astral-sh/python-build-standalone

[ryanli]

One thing that seems to be different between debian12 and debian13 is that the latter doesn't have /lib/x86_64-linux-gnu and there's only /usr/lib/x86_64-linux-gnu. This causes a runtime error in some Python programs who are looking for libc.so.6 (although LD_LIBRARY_PATH is set correctly):

/usr/bin/ld: cannot find /lib/x86_64-linux-gnu/libc.so.6: No such file or directory

Is this intentional (i.e. done upstream)? Seems to be going in the contrary of the trend as Gentoo w/ OpenRC has deprecated the split-usr layout.

[matushorvath]

Debian went through a similar process, https://wiki.debian.org/UsrMerge. There should be a symlink from /lib to /usr/lib to handle your use case:

$  docker run -it -v /usr/bin:/host-bin gcr.io/distroless/base-debian13 /host-bin/busybox ls -ld /lib
lrwxrwxrwx    1 root     root             7 Aug 24 16:20 /lib -> usr/lib
$ docker run -it -v /usr/bin:/host-bin gcr.io/distroless/base-debian13 /host-bin/busybox ls -l /lib/x86_64-linux-gnu/libc.so.6
-rwxr-xr-x    1 root     root       2003408 Aug  5 17:34 /lib/x86_64-linux-gnu/libc.so.6

[ryanli]

Thanks @matushorvath. Confirmed that the issue is with rules_oci rather than the distroless image. I filed https://github.com/bazel-contrib/rules_oci/issues/857 for rules_oci.

[sxyql]

Hello, I currently have the error that when I build my application via a Python builder based on trixie, the run process on distroless fails. It seems that the version of glibc that distroless ships in is lower than the current Debian 13. Debian currently provides 2.41 https://packages.debian.org/trixie/glibc-source. While Distroless seems to be on version 2.38. This is at least what the following error suggests: [PYI-8:ERROR] Failed to load Python shared library '/tmp/_MEIjU829i/libpython3.14.so.1.0': /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.38' not found (required by /tmp/_MEIjU829i/libpython3.14.so.1.0)

Edit: It was my error.

[loosebazooka]

Pretty sure we ship with 3.41 from debian

$ /usr/lib/x86_64-linux-gnu/libc.so.6 

GNU C Library (Debian GLIBC 2.41-12) stable release version 2.41.
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 14.2.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
Minimum supported kernel: 3.2.0
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.