> Debian 11 just recently went out of its LTS period, and is unmaintained
> by the project (there is "Extended LTS", but it is a paid service
> provided by a third party).
>
> The point of the debian-11 job was to cover older releases in the LTS
> state, per ac112fd4f0 (Add additional CI jobs to avoid accidental
> breakage, 2024-10-31). Bumping to debian-12 will cover us there for the
> next 2 years.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I started looking at this because I got an apt failure on a debian-11
> job today. It might have just been a transient mirror failure (although
> it reproduced for several minutes afterwards). But this seems like the
> right step forward anyway.
>
> I tested the GitHub job, but not the GitLab one. They should be pulling
> the same docker images, though, so I would expect it to Just Work.

>
>  .github/workflows/main.yml | 6 +++---
>  .gitlab-ci.yml             | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 205325eb33..a0c3f53c6d 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -411,9 +411,9 @@ jobs:
>          # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>          - jobname: almalinux-8
>            image: almalinux:8
> -        # Supported until 2026-08-31.
> -        - jobname: debian-11
> -          image: debian:11
> +        # Supported until 2028-06-30.
> +        - jobname: debian-12
> +          image: debian:12
>      env:
>        jobname: ${{matrix.vector.jobname}}
>        CC: ${{matrix.vector.cc}}
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 0242283c3c..cd6fd4a504 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -71,9 +71,9 @@ test:linux:
>        # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>        - jobname: almalinux-8
>          image: almalinux:8
> -      # Supported until 2026-08-31.
> -      - jobname: debian-11
> -        image: debian:11
> +      # Supported until 2028-06-30.
> +      - jobname: debian-12
> +        image: debian:12
>    artifacts:
>      paths:
>        - t/failed-test-artifacts

> On Sat, Sep 05, 2026 at 09:58:22AM -0400, Jeff King wrote:
> 
> > I started looking at this because I got an apt failure on a debian-11
> > job today. It might have just been a transient mirror failure (although
> > it reproduced for several minutes afterwards). But this seems like the
> > right step forward anyway.
> 
> BTW, I noticed that the linux32 build is using ubuntu 20.04, which has
> been out of LTS for a year. But bumping isn't really an option; they
> dropped i386 platform support, and so has Debian.
> 
> I'm mostly inclined to leave it unless/until it starts creating
> headaches. To some degree, if we cannot even find an image to test
> again, it might not be an important enough platform to care about. But I
> can also imagine there is a long tail of oddball 32-bit platforms that
> Git does run on (like small ARM chips), and it's nice to at least have
> some coverage. Possibly there's an ARM image we could use (looks like
> armhf?).

> We also seem to use 20.04 for linux-TEST-vars. On the surface there's no
> reason it couldn't be using ubuntu-latest, though I think this may be
> one of those cases where it's doing double duty as "test exotic configs"
> and "test on an older platform". But might be worth bumping to the
> oldest in-scope LTS.

> Debian 11 just recently went out of its LTS period, and is unmaintained
> by the project (there is "Extended LTS", but it is a paid service
> provided by a third party).
> 
> The point of the debian-11 job was to cover older releases in the LTS
> state, per ac112fd4f0 (Add additional CI jobs to avoid accidental
> breakage, 2024-10-31). Bumping to debian-12 will cover us there for the
> next 2 years.
> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I started looking at this because I got an apt failure on a debian-11
> job today. It might have just been a transient mirror failure (although
> it reproduced for several minutes afterwards). But this seems like the
> right step forward anyway.

> diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> index 205325eb33..a0c3f53c6d 100644
> --- a/.github/workflows/main.yml
> +++ b/.github/workflows/main.yml
> @@ -411,9 +411,9 @@ jobs:
>          # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>          - jobname: almalinux-8
>            image: almalinux:8
> -        # Supported until 2026-08-31.
> -        - jobname: debian-11
> -          image: debian:11
> +        # Supported until 2028-06-30.
> +        - jobname: debian-12
> +          image: debian:12
>      env:
>        jobname: ${{matrix.vector.jobname}}
>        CC: ${{matrix.vector.cc}}
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 0242283c3c..cd6fd4a504 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -71,9 +71,9 @@ test:linux:
>        # A RHEL 8 compatible distro.  Supported until 2029-05-31.
>        - jobname: almalinux-8
>          image: almalinux:8
> -      # Supported until 2026-08-31.
> -      - jobname: debian-11
> -        image: debian:11
> +      # Supported until 2028-06-30.
> +      - jobname: debian-12
> +        image: debian:12
>    artifacts:
>      paths:
>        - t/failed-test-artifacts

> > +      # Supported until 2028-06-30.
> > +      - jobname: debian-12
> > +        image: debian:12
> >    artifacts:
> >      paths:
> >        - t/failed-test-artifacts
> 
> The changes look good, but I wonder whether we want to swap to the
> "oldstable" tag instead. That points to debian-12, too, and might result
> in less churn going forward.

> On Mon, Sep 07, 2026 at 08:03:34AM +0200, Patrick Steinhardt wrote:
> 
> > > +      # Supported until 2028-06-30.
> > > +      - jobname: debian-12
> > > +        image: debian:12
> > >    artifacts:
> > >      paths:
> > >        - t/failed-test-artifacts
> > 
> > The changes look good, but I wonder whether we want to swap to the
> > "oldstable" tag instead. That points to debian-12, too, and might result
> > in less churn going forward.
> 
> I was all ready to agree and propose a patch, but I think it might be
> more complicated. The "old" flags flip when a new stable version is
> released, but what we really care about is things leaving LTS. And the
> two are not really aligned.
> 
> So if we wanted the oldest supported Debian release, that would have
> been "oldoldstable" (debian-11) until August 31st of this year. But
> after that, we want "oldstable" (debian-12), which is now the oldest
> thing under LTS. And that will be true until probably next summer, when
> debian-14 is released, at which point we'd want to stay on it by
> switching to "oldoldstable" again for another year.
> 
> The offset comes from the fact that Debian releases approximately every
> 2 years, but with a 5-year LTS, and they never align.
> 
> If we track oldstable, then every other year we're not using the oldest
> supported release (because the prior release is still in LTS). Or we
> track oldoldstable, which means every other year we're using a release
> that's no longer supported. Or we flip-flop between them once a year,
> when oldoldstable goes out of support.
> 
> Which makes me inclined to just keep the current scheme: use the numeric
> codes and just bump them every 2 years or so when they go out of
> support. And we can even put it off until the out-of-support release
> starts causing problems like it did here.

> If we track oldstable, then every other year we're not using the oldest
> supported release (because the prior release is still in LTS). Or we
> track oldoldstable, which means every other year we're using a release
> that's no longer supported. Or we flip-flop between them once a year,
> when oldoldstable goes out of support.
>
> Which makes me inclined to just keep the current scheme: use the numeric
> codes and just bump them every 2 years or so when they go out of
> support. And we can even put it off until the out-of-support release
> starts causing problems like it did here.