Update Glibc Version in Conda Images

[tustvold]

Describe the enhancement requested

As reported on rust-lang/rust#125067 and apache/arrow-rs#5719 the integration test image is running a very old glibc version in particular 2.12 from 2010!

I am not entirely sure why the version is so old, but given the version in question predates both docker and the arrow project I can only guess this must have been intentional at some point? Perhaps for compatibility with RHEL or something that likes to lag miles behind?

We're currently unable to update the Rust toolchain because of this and so it would be good to find some way to perhaps move to a version of glibc from this decade... Rust requires at least 2.17 - https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html

I have confirmed that running conda install sysroot_linux-64=2.28 fixes the ability to compile rust code within the integration image.

Component(s)

Archery

[xhochy]

Two notes on this:

1. conda-forge's Rust still is able to run (compile?) on 2.12: https://github.com/conda-forge/rust-activation-feedstock/blob/d8a9cb920ce297953d3f0d48fad326d0b7493665/.ci_support/linux_64_MACOSX_DEPLOYMENT_TARGET0c_h91081a0724.yaml#L8
2. You should be able to update the conda-image to quay.io/condaforge/linux-anvil-cos7-x86_64 which is the base image used in all of conda-forge. A 2.28 glibc image will be ready in 1-3 months.

[xhochy]

The need for this old version comes from the need to build binaries that can run on a large set of machines and updating the global minimum comes at a cost.

[tustvold]

conda-forge's Rust still is able to run (compile?) on 2.12: https://github.com/conda-forge/rust-activation-feedstock/blob/d8a9cb920ce297953d3f0d48fad326d0b7493665/.ci_support/linux_64_MACOSX_DEPLOYMENT_TARGET0c_h91081a0724.yaml#L8

I suspect it is only a matter of time before that breaks, you will notice the linux aarch64 images have been updated to use 1.17

[workingjubilee]

That can run on RHEL 6, specifically, an EOL distribution.

RHEL 7 is also going to be EOL in 48 days.

[xhochy]

will notice the linux aarch64 images have been updated to use 1.17

aarch64 on conda-forge was started with 2.17, so this is the oldest possible.

[xhochy]

RHEL 7 is also going to be EOL in 48 days.

Yes, this is why there is a move to 2.28 on its way but as all OSS: It depends on someone doing the work.

[tustvold]

A 2.28 glibc image will be ready in 1-3 months.

This sounds good to me, we solely use these images in CI for integration testing and so we can just use an older Rust toolchain until newer images are available.

It depends on someone doing the work

Thank you for working on this, my intent was not to mandate a schedule but rather start the discussion so everyone is on the same page

[xhochy]

Can you point me to the job in question? I feel like we don't actually need the old images in this case but could rather use a cutting edge distribution.

[tustvold]

Can you point me to the job in question

I'm not very familiar with the build process for the arrow images, and therefore where the image actually comes from, but we just use apache/arrow-dev:amd64-conda-integration

[pitrou]

The need for this old version comes from the need to build binaries that can run on a large set of machines and updating the global minimum comes at a cost.

Do we actually build binaries with our Conda images?

[xhochy]

apache/arrow-dev:amd64-conda-integration is probably built from

arrow/ci/docker/conda-integration.dockerfile

Line 20 in 6a9e2d5

FROM ${repo}:${arch}-conda-cpp

and this should be Ubuntu 22.04 if I trace it correctly?

[jleibs]

A 2.28 glibc image will be ready in 1-3 months.

@xhochy it seems like you're in the loop on this stuff. Where can I find out more info? I've tried searching, but I'm struggling to find an authoritative issue somewhere capturing the different workstreams that are required to get to the point where the glibc 2.28 stuff is actually usable.

[xhochy]

This is the conda-forge issue about it: conda-forge/conda-forge.github.io#1941