Vendor pinned GNU config scripts for Autoconf image

[Copilot]

Autoconf image builds were failing while BuildKit fetched pinned config.guess / config.sub from Savannah’s gitweb endpoint. Related upstream PRs showed the same shared download failure, not an action-specific regression.

• GNU config inputs

  • Vendor config.guess and unpatched config.sub from GNU config revision 00b15927496058d23e6258a28d8996f87cf1f191.
  • Keep the existing pinned revision documented in the Dockerfile.

• Docker build path

  • Replace remote Savannah ADD downloads with local executable COPY steps.

  COPY --chmod=755 config.guess /usr/local/share/autoconf/build-aux/config.guess
  COPY --chmod=755 config.sub /usr/local/share/autoconf/build-aux/config.sub

• Patch behavior

  • Preserve the existing config.sub.patch flow for arm64_32 normalization and Apple simulator triples.

[brettcannon]

Why is this file being added when it wasn't necessary before?

[brettcannon]

Why is this file being added when it wasn't necessary before?

[brettcannon]

Always download the file, don't check it in. Changing the environment variable should be all that's needed to update these files.

[brettcannon]

@copilot address the review comments

[Copilot]

@copilot address the review comments

Addressed in ce00f70. The vendored files were removed, and the PR now keeps CONFIG_GIT_REV as the update point while switching the two downloads from gitweb to cgit. Local pre-commit and focused BuildKit URL checks passed; the new CI runs are awaiting approval.

[brettcannon]

@copilot CI still fails

[Copilot]

@copilot CI still fails

Addressed in f77c1e5. The failing job was still hitting BuildKit remote ADD cache-key fetches (config.sub returned 502), so I replaced the remote ADD steps with a pinned git fetch from the authoritative Savannah repo using CONFIG_GIT_REV, with bounded retries. The new workflow run is awaiting approval.

[Copilot]

Copilot review overview

🟡 Changes recommended

The PR title/description claims the scripts are vendored and copied via COPY, but the implementation still downloads them at build time via git fetch, so the PR metadata and code are materially out of sync.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Lite
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	autoconf/​Dockerfile — PR metadata says the pinned GNU config scripts are vendored and copied via `COPY --chmod=755…

What changed in this PR

Updates the Autoconf devcontainer image build to avoid failures when downloading pinned GNU config scripts from Savannah’s gitweb “blob_plain” endpoint, while keeping the pinned config.git revision and the existing config.sub patch flow.

Changes:

• Replace remote ADD downloads of config.guess / config.sub with a git fetch-based retrieval and install into Autoconf’s build-aux directory.
• Add a small retry/backoff loop around fetching the pinned CONFIG_GIT_REV.

File	Description
autoconf/​Dockerfile	Switches pinned GNU config script retrieval from ADD-from-gitweb to git fetch + install, preserving the pinned revision and downstream patch step.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[brettcannon]

@copilot why the retries? Is that really the cause of the failures, or you're assuming and actually just using Git directly is enough?

[Copilot]

Good call — the original failure was BuildKit ADD returning 502 while loading cache keys, not a proven transient git fetch issue. I removed the retry loop and kept a single pinned git fetch so the fix is just switching away from remote ADD behavior (8e3699d).

[brettcannon]

@copilot should a sparse checkout be used?

[Copilot]

Not necessary here. We already fetch a single pinned commit (--depth=1 + CONFIG_GIT_REV) and only check out config.guess/config.sub, so sparse checkout would add setup complexity without meaningful benefit.