From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH] ci: bump debian-11 job to debian-12
Date: Mon, 7 Sep 2026 08:03:27 +0200 [thread overview]
Message-ID: <ap5TrxRXrYZzwMN2@pks.im> (raw)
In-Reply-To: <20260906151137.GA328152@coredump.intra.peff.net>
On Sun, Sep 06, 2026 at 11:11:37AM -0400, Jeff King wrote:
> 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?).
I agree that in the best case we'd find an alternative that works on 32
bit. But as you say, the list of x86 distros that still have support for
32 bit is shrinking quite a bit these days.
One of the bigger distros that still supports it properly is Alpine
Linux. We already support it via linux-musl-meson, so it should be easy
enough to extend. In theory, we could even merge these two jobs into a
single job. We'd of course lose 32 bit glibc support, but that might be
fine.
> 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.
Yeah, might be worth it. It would've been great if they had a tag for
this so we odn't have to bump ourselves, but on the other hand it's only
a small bit of churn.
Patrick
next prev parent reply other threads:[~2026-09-07 6:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 13:58 [PATCH] ci: bump debian-11 job to debian-12 Jeff King
2026-09-05 16:32 ` Junio C Hamano
2026-09-06 15:11 ` Jeff King
2026-09-07 6:03 ` Patrick Steinhardt [this message]
2026-09-07 6:03 ` Patrick Steinhardt
2026-09-11 2:19 ` Jeff King
2026-09-11 5:09 ` Patrick Steinhardt
2026-09-11 15:42 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ap5TrxRXrYZzwMN2@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.