test: Update ubuntu runner as 20.04 is going away

[rfay]

Ubuntu 20.04 is going to be turned off shortly as a host runner.

Use 22.04 instead. The note though may imply problems:

# An old release of Ubuntu is chosen for glibc compatibility

IMO it might be better to just use ubuntu-latest and remove the comment?

[jandubois]

IMO it might be better to just use ubuntu-latest and remove the comment?

I disagree; we want the release to maintain as much backwards compatibility as possible.

The 20.04 runners don't go away until April 1st (with 4 brown-out periods before to warn people). So we might want to delay merging this PR until later in March, in case we do another patch release before then (I don't expect we will; just in case).

The Ubuntu 20.04 runner image will be fully unsupported by April 1, 2025. To raise awareness of the upcoming removal, we will temporarily fail jobs using Ubuntu 20.04. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:

March 4 14:00 UTC – 22:00 UTC
March 11 13:00 UTC – 21:00 UTC
March 18 13:00 UTC – 21:00 UTC
March 25 13:00 UTC – 21:00 UTC

[rfay]

I just happened to note this since I had a checkout on my machine and grepped for all the ubuntu-20.04 usages :)

[afbjorklund]

What symbols are we requiring? Could we add some hack for backwards compability, in that case?

https://gcc.gnu.org/wiki/SymbolVersioning (I can't seem to find anything but GLIBC_2.3.4 though)

I still think 22.04 is the desired target.

I was just wondering, where it breaks.

---

EDIT: that would be: 2.2.5 - 2.3.4

__vfprintf_chk@GLIBC_2.3.4
pthread_cond_wait@GLIBC_2.3.2

When compiled with glibc 2.31

[jandubois]

What symbols are we requiring?

I don't know, but I think this is because we compile with CGO_ENABLED=1 for access to the glibc host resolver.

[afbjorklund]

I think this is because we compile with CGO_ENABLED=1 for access to the glibc host resolver.

Yeah, the go change was a problem for alpine (since it doesn't use glibc, and didn't have libresolv)

Just wondered if it was a big problem, but then again probably only affects RHEL 8 (2018) and such?

This project had some nice tables and workarounds: https://github.com/pypa/manylinux

[jandubois]

This project had some nice tables and workarounds: https://github.com/pypa/manylinux

My head hurts just looking at that...

I think just building our releases on the oldest Ubuntu version that has supported GitHub runners is good enough. If platforms still need special consideration beyond that, then ideally they should distribute Lima through their package system. Or users can compile it themselves: make && make install.

[AkihiroSuda]

Thanks