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: EDIT: For our use case in , we were able to add compatibility for RHEL 5 .
See for a recent case where supporting such ancient kernels required extra manual work ( to the 2 lines mentioned by above). I am not sure how often that comes up, but probably the hardest part is to even notice that it happens -- and even then those codepaths will likely linger untested.
Yes, but this will still be true in general. If the CI kernel is newer than whatever kernel baseline we choose, it will be possible for newer syscalls to pass undetected. I don't know if we have any control over that -- can we choose a particular VM image? So that leaves us with a stated policy of support. The more that developers are aware of such issues, the better, but I'm the one most likely to notice when my build actually fails. If I come back with a fix, I at least need the project to be receptive. I haven't been in the habit of building nightly on our RHEL6 builders, but maybe I should! Catching this early is better for everyone involved...
That seems reasonable. How quick is the Rust related bootstrapping? Could it be run automatically (or more frequently)? This is an interesting point. If I hadn't made that change, would have kept working on RHEL 5, it just would have leaked an FD. I'm not sure how we would even test for this sort of thing. This isn't a RHEL 5 specific concern, I just don't know how Rust tests these types of resource leak issues in general.
About 2 hours. Automation is harder, since I believe our build system needs my credentials, but I'll look into what is possible here. Yeah, that's a lot more subtle than an !