Code change:
<del> FROM centos:5 </del> <ins> # We use Debian 6 (glibc 2.11, kernel 2.6.32) as a common base for other # distros that still need Rust support: RHEL 6 (glibc 2.12, kernel 2.6.32) and # SLES 11 SP4 (glibc 2.11, kernel 3.0). FROM debian:6 </ins> WORKDIR /build <del> # Centos 5 is EOL and is no longer available from the usual mirrors, so switch # to http://vault.centos.org/ RUN sed -i 's/enabled=1/enabled=0/' /etc/yum/pluginconf.d/fastestmirror.conf RUN sed -i 's/mirrorlist/#mirrorlist/' /etc/yum.repos.d/*.repo RUN sed -i 's|#(baseurl.*)mirror.centos.org/centos/$releasever|1vault.centos.org/5.11|' /etc/yum.repos.d/*.repo </del> <ins> # Debian 6 is EOL and no longer available from the usual mirrors, # so we'll need to switch to http://archive.debian.org/ RUN sed -i '/updates/d' /etc/apt/sources.list &&  sed -i 's/httpredir/archive/' /etc/apt/sources.list </ins> <del> RUN yum upgrade -y && yum install -y  curl  </del> <ins> RUN apt-get update &&  apt-get install --allow-unauthenticated -y --no-install-recommends  automake  </ins> bzip2  <ins> ca-certificates  curl  file  g++  g++-multilib  </ins> gcc  <del> gcc-c++  </del> <ins> gcc-multilib  git  lib32z1-dev  libedit-dev  libncurses-dev  </ins> make  <del> glibc-devel  </del> <ins> patch  </ins> perl  <del> zlib-devel  file  xz  which  pkgconfig  </del> <ins> pkg-config  unzip  </ins> wget  <del> autoconf  gettext </del> <ins> xz-utils  zlib1g-dev </ins> ENV PATH=/rustroot/bin:$PATH <del> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib </del> <ins> ENV LD_LIBRARY_PATH=/rustroot/lib64:/rustroot/lib32:/rustroot/lib </ins> ENV PKG_CONFIG_PATH=/rustroot/lib/pkgconfig WORKDIR /tmp <ins> RUN mkdir /home/user </ins> COPY host-x86_64/dist-x86_64-linux/shared.sh /tmp/ # We need a build of openssl which supports SNI to download artifacts from

Related discussion:
text: This issue came up for me when dealing with opening files in , see for more info. No single RHEL 5 issue is that bad, it's mainly just the sum of a bunch of tiny issues.
I'm not on that team, but AFAIK we don't ship Firefox updates for ELS. The last build I see for RHEL 5 was . Maybe there could be an exception for a severe security issue, but I really doubt we'd rebase to newer Firefox for that, which means Rust requirements won't change. New Firefox ESR versions do require a newer Rust toolchain too, which is generally why we have to keep up. Otherwise we could just freeze some older compat rustc while upstream moves on. Rust wasn't required until Firefox 52.
that makes perfect sense to me, thanks for clarifying. So the proposed policy would be: Support RHEL until RHEL is retired (i.e. ends normal support). This would mean: Supporting RHEL 5 (v2.6.18) until November 30, 2020 Supporting RHEL 6 (v2.6.32) until June 30, 2024 Supporting RHEL 7 (v3.10) until May, 2029 This is a much longer support tail than any other Linux distros (that I know of), so it would also be the effective minimum kernel version of , , and their dependencies. How does that sound to people? EDIT: The alternative to this would be Support RHEL until it is retired, taking the table above and incrementing the RHEL versions by 1. It would also mean being able to drop RHEL 5 support now.
Sure, that's ideal for me. :smile: As mentioned, is just needed for kernel support, as far as I'm concerned. Userspace concerns like GLIBC symbol versions can stick to currently supported for my needs.
Red Hat should backport the features we need (CLOEXEC and getrandom, in particular) to whatever kernels that it wants Rust to support. I don't know any good reason why they don't do so, other than it's cheaper to convince the whole world to keep supporting older kernel versions than it is to do the backports. We should change that dynamic.