The AC_CHECK_TYPE issue was addressed previously: #89886 (comment)

cc. @corona10

Seems our usage of AC_EGREP_*() is pretty safe, so it is not imperative to replace them with more modern equivalents.

Seems our usage of AC_EGREP_*() is pretty safe, so it is not imperative to replace them with more modern equivalents.

Well, the AC_EGREP_HEADER usage is not very clean. We should fix that.

Preparations for GNU Autoconf 2.72 have landed. It looks like Ubuntu 24.04 will ship with GNU Autoconf 2.71, though. @corona10, what do you think of switching to an autoconf docker/podman image again?

@erlend-aasland

Preparations for GNU Autoconf 2.72 have landed. It looks like Ubuntu 24.04 will ship with GNU Autoconf 2.71, though. @corona10, what do you think of switching to an autoconf docker/podman image again?

1. If we decide to use a container image, I would prefer to keep this strategy forever, even if OS provides the specific version.
2. Let's migrate the repository https://github.com/corona10/cpython_autoconf to Python org and publish to the quary.io under python.org to provide images for x86 and aarch64. This repo publish the new image if the autoconf is bumped up :)
   see https://github.com/corona10/cpython_autoconf/blob/main/.github/workflows/manifest-build-push.yml

@corona10, IIRC one of the concerns with the container image, was that our CI relied on an external service; network issues or quay.io downtime can make jobs fail. If we go for such a solution, we should have a broader discussion.

@corona10, IIRC one of the concerns with the container image, was that our CI relied on an external service; network issues or quary.io downtime can make jobs fail. If we go for such a solution, we should have a broader discussion.

@erlend-aasland
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-docker-registry
I didn't take a look at it deeply; If Github provide its own docker registry, it could be one option.
I feel(!) like that it's more reliable than quary.io since GitHub manages both of repository and registry from our side :)

Looks promising!

So, in this case, my suggestion would be.

1. Create a GitHub repository for autoconf under python organization.
2. Publish both of amd64 and arm64 images to the GitHub container registry :)

Great; I say go for it 😀 let's propose it on Discourse.

That would also make it easier for us to update the autoconf-archive macros.

Here is my PoC

• GHCR package: https://github.com/users/corona10/packages/container/package/cpython_autoconf
• Dockerfile: https://github.com/corona10/cpython_autoconf/blob/main/Dockerfile
• Github Action: https://github.com/corona10/cpython_autoconf/blob/main/.github/workflows/manifest-build-push.yml
• Sample command: podman run --rm -v$(pwd):/src ghcr.io/corona10/cpython_autoconf:272-final

PoC is not perfect but that’s why PoC :)

Great; I say go for it 😀 let's propose it on Discourse.

👉 https://discuss.python.org/t/pinning-gnu-autotools-using-the-github-container-registry/47437

A few months later, we've now got the CPython devcontainers 🥳 Switching to 2.72 should be pretty easy now. Let's do it now that we're in 3.14 alpha. I'll prepare a PR a week or so after landing #117815 (I'd like to let that PR live in main for a few days, in case anything breaks.

See erlend-aasland/cpython@859870a for a draft.

I forgot some doc and configure.ac updates; reopening.

so a bit annoyingly this now means that one cannot autoconf on the most popular linux distribution's most recent lts release (which isn't even that old) ubuntu 24.04 which ships with autoconf 2.71

this makes it difficult to package for deadsnakes as well -- I'm hoping to just patch out the autoconf version requirement and continue on as usual. it doesn't seem to actually need the most recent version?

Fedora 40, which is still a supported version, is also affected the same way (autoconf 2.71 still there).
@asottile, were you successful with patching out the autoconf version?