ci: Update dist-{i686,x86_64}-linux to Debian 6

[cuviper]

This increases the minimum {i686,x86_64}-unknown-linux-gnu platform
from RHEL/CentOS 5 (glibc 2.5 and kernel 2.6.18) to a slightly newer
Debian 6 squeeze (glibc 2.11 and kernel 2.6.32). While that release is
already EOL, it happens to match the minimum common versions of two
enterprise distros that do still need Rust support -- RHEL 6 (glibc 2.12
and kernel 2.6.32) and SLES 11 SP4 (glibc 2.11 and kernel 3.0).

Closes #62516.

[rust-highfive]

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

[cuviper]

This supercedes #73782.
cc @msirringhaus for SLES
r? @Mark-Simulacrum
@bors try

RE: #73782 (comment)

Maybe you could ask internally if there's other things that are dropping support for RHEL 5 now (or in November)? Being able to look at how other's have made that decision would be helpful I think.

• glibc itself evaluates this based on how much emulation code could be removed by a new kernel baseline, and what kernels under support would not meet that baseline. They require Linux 3.2 since glibc 2.26.
• .NET on Linux has a rough policy to drop support for a RHEL version after it leaves Maintenance Support, per the life cycle dates. That would already exclude RHEL 5.
• qemu and libvirt both have a policy of dropping old distro versions 2 years after a new major version is released. Their assumption is that it becomes less likely that anyone will need new workloads/features on the old OS once there's a new release available.

I think we can't make the same argument about new deployments though, since new Firefox ESR builds are required even on older OSes, and that forces Rust forward along with it. Even then, the fact that I needed RHEL 5 support was an oddity of our internal build system, as we're currently only updating Firefox on RHEL 6 and later.

[bors]

⌛ Trying commit cad41f6db84a14edcafb6e1257b64864ef2ea22e with merge 40edca408120f0a8e0b69be3688520c2432b0e7e...

[bors]

💥 Test timed out

[cuviper]

@bors try

[bors]

⌛ Trying commit cad41f6db84a14edcafb6e1257b64864ef2ea22e with merge 4f227e3d5f8a312e5c37bab426c28affad30c73a...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 4f227e3d5f8a312e5c37bab426c28affad30c73a (4f227e3d5f8a312e5c37bab426c28affad30c73a)

[Mark-Simulacrum]

We discussed this in last week's release meeting, and the summary of that discussion was that we plan on posting an RFC formalizing that for the x86_64 linux targets, we plan to have a baseline level of support for the RHEL and SLES versions that are supported (or needed to support current version, due to bootstrapping). Further details will be in the RFC (and to some extent need to be hashed out). In the mean time, though, we will move ahead with this PR through the FCP process.

If people feel that we should wait for the RFC to be posted and approved prior to landing this, please do raise that concern. I personally feel comfortable making a one-off decision to bump support here and then formalizing the process we go through to do so, though.

@rfcbot fcp merge

[rfcbot]

Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BatmanAoD
• @Dylan-DPC
• @Mark-Simulacrum
• @XAMPPRocky
• @cuviper
• @jonas-schievink
• @pietroalbini
• @sgrif
• @tmandry

Concerns:

• SLES-approval resolved by ci: Update dist-{i686,x86_64}-linux to Debian 6 #74163 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Mark-Simulacrum]

@rfcbot concern SLES-approval

I would like @msirringhaus to weigh in before we merge this as well.

[cuviper]

You can inspect the binary artifacts from the try-build above using this tool.

$ rustup-toolchain-install-master 4f227e3d5f8a312e5c37bab426c28affad30c73a

[cuviper]

Side note, this will also affect other tools that piggy-back on Rust CI images -- I know rustup does.

[msirringhaus]

I've downloaded the artifacts and compiled a simple "hello world"-program successfully on SLES-11 SP4

[Mark-Simulacrum]

@rfcbot resolve SLES-approval

[Mark-Simulacrum]

r=me with try builder removed and FCP done

[RalfJung]

Should https://forge.rust-lang.org/release/platform-support.html be updated to reflect the new minimal kernel version? (Might be good to also give the required glibc there.)

[cuviper]

Yes we should update the forge, and I agree glibc should be mentioned too. Plus the lower tier Linux targets aren't mentioning this at all, but probably should.

[newpavlov]

@Mark-Simulacrum

we plan on posting an RFC formalizing that for the x86_64 linux targets

Would it be possible to cover Windows and Mac policy in the same RFC as well (and ideally other OSes)? For example, panic has been long broken on Windows XP and we have to use deprecated API for retrieving OS randomness on all non-UWP Windows targets. So it would be nice if XP and Vista support will be dropped as part of this RFC.

[Mark-Simulacrum]

We'd probably want separate RFCs I think, given that the audience interested in each platform is probably pretty distinct. I imagine once we work through the linux RFC and perhaps land the tier policy RFC @joshtriplett has been working on we can look at Windows and macOS. My impression personally is that we're going to be much more constrained there -- lack of easily available ways of testing older macOS and Windows releases makes it difficult to support those platforms.