ci: Update dist-{i686,x86_64}-linux to CentOS 6 #73782
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
This will likely need team signoffs from release and maybe core, and we should check the state of other LTS distros in comparison. In the meantime though, I've enabled @bors try |
|
⌛ Trying commit 2a76497 with merge 77e12497be36e6074af6ef4c6160b2d7bb4f16c1... |
|
💥 Test timed out |
|
Docket rebuilds take a while, but it should be cached now. @bors try |
|
⌛ Trying commit 2a76497 with merge 5511acc2b74d15a455b790c5f3c1062c5d3970e8... |
|
☀️ Try build successful - checks-azure |
|
I agree that this seems like a reasonable step, but I do think trying to conduct some kind of survey would be good as to whether people need these older kernel versions supported. I'm not sure where we would do so, though. Another question is what other languages support. I think the C++ standard library only very recently gained file system support, so maybe asking there isn't too significant. I don't know without doing research what else we could look at. 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. |
Oldest non EOL Ubuntu is 14.04 with glibc 2.19 and 3.13 kernel: https://wiki.ubuntu.com/Releases |
Heh, even RHEL 7 is older than that with glibc 2.17 and kernel 3.10. SUSE would be the other really long-term provider, but I don't know if we have any contacts in the Rust community. SLES 11 SP4 has glibc 2.11.3 and kernel 3.0, so that could be a problem with symbol versions compared to RHEL 6's glibc 2.12. However, in their lifecycle table this is past general support and into LTSS -- if that's like Red Hat's ELS, it wouldn't include any new package versions, only fixes. So I don't know if anyone would need new rustc versions to continue running there.
I'll ask around for other examples. But really, I think Rust is in kind of a special place here compared to other toolchains. Most packages are much more conservative about rebasing at all, but Firefox is special due to its security position and the ever evolving web, so it's not really feasible to maintain longer than ESR already does. And since new Firefox requires new Rust, we end up needing those new toolchain versions even for older systems. |
Mark-Simulacrum
added
S-waiting-on-author
|
SUSE Firefox Maintainer here: I'd like to veto this PR :-) |
|
Hm, does SUSE use binaries from the Rust project for those targets? |
|
Ideally, we want to build a new compiler version with an old one. But sometimes we have to bootstrap, using the binaries from rust-lang.org/dist |
|
@msirringhaus Did I get the versions right for SLES 11 SP4 -- glibc 2.11.3 and kernel 3.0? Then to support both SLES 11 and RHEL6, we'll need to use the least-common versions, glibc 2.11 and kernel 2.6.32.
The build OS shouldn't be directly relevant anymore. They did once use Ubuntu's cross toolchains, but way back in #39382 I switched those to manual cross toolchains, configured as RHEL6-ish for s390x and powerpc/powerpc64(be), and RHEL7-ish for powerpc64le. If you need to push those back further for SLES, it may be possible. If you or someone else at SUSE would like to work on that, I'd be happy to review it. Maybe we could also move i686 and x86_64 to crosstool-ng to get a common baseline of glibc 2.11 and kernel 2.6.32, as mentioned above. I'll look into that as a replacement for this PR. |
|
I'm having trouble with using crosstool for i686/x86_64, being not really a cross build in this case. We've specialized this target to use CC=clang and ThinLTO LLVM builds, which is proving to be a pain to integrate.
It turns out this also matches Debian 6 (squeeze), which has a docker image, so I'll try that. |
Yes that is correct.
I'll try to familiarize myself with the setup and see what I can do. This could take some time, though :-) |
|
Replaced by #74163, which has merged. |
Downgrade glibc to 2.11.1 for ppc, ppc64 and s390x As discussed in rust-lang#73782 I've tested these changes on rust 1.43.0 for all the specified archs and used the resulting binaries to bootstrap building rust 1.43.1. I've also shortly tested these changes on master on ppc64.
Downgrade glibc to 2.11.1 for ppc, ppc64 and s390x As discussed in rust-lang#73782 I've tested these changes on rust 1.43.0 for all the specified archs and used the resulting binaries to bootstrap building rust 1.43.1. I've also shortly tested these changes on master on ppc64.
This has the effect of raising the minimum x86 Linux support to match CentOS 6 / RHEL 6, with kernel 2.6.32 and glibc 2.12.
For my own part as a Red Hat employee, I needed RHEL 5 kernel support so I could run on the builders we use for RHEL 6 packaging, where we are still shipping Firefox updates. That support will end in November, so Firefox 78 ESR is the last rebase it will see, which only needs Rust 1.41. Therefore, we will be fine with Rust raising its minimum to RHEL 6, which I will need for a while yet in building RHEL 7 packages.
Closes #62516.