Windows CI setup broken: cygwin mirror rotated pkgconf 2.5.1 out, the pinned downgrade 404s

[lukstafi]

Every Windows CI leg that misses the opam cache now fails at setup, in the step Restore cygwin pkgconf 2.5.1 (Windows) of .github/workflows/ci.yml, before a single test runs. First seen on the extended workflow_dispatch run on master@2f640032f: https://github.com/lukstafi/ocannl-staging/actions/runs/33933071706 (both Build (windows-latest, 5.5.x, main) and Build (windows-latest, 5.5.x, train), 14 minutes in).

Cause: the step fetches the pinned downgrade from https://cygwin.mirror.constant.com/x86_64/release/pkgconf/, and cygwin mirrors keep only the current release versions. The directory now holds pkgconf-3.0.4-2, 3.0.5-1, 3.0.6-1 (plus, still, libpkgconf7/libpkgconf7-2.5.1-1); pkgconf-2.5.1-1-x86_64.tar.zst is gone:

curl: (22) The requested URL returned error: 404
/usr/bin/tar: pkgconf-2.5.1-1-x86_64.tar.zst: Cannot open: No such file or directory
expected pkgconf 2.5.1, got '3.0.6' (extraction failed? this needs a tar with zstd support)

The 2026-09-02 scheduled run (33586609266) still fetched it, so the rotation happened between 2026-09-02 and 2026-09-05. The step's own if: skips it on a cache hit, but actions/cache saves only on a green job, so once a Windows leg misses (a pin or solution digest moves, as it did here) every later run misses too. The next scheduled sweep (Sunday 2026-09-06 03:00 UTC) will fail the same way.

Why it matters beyond a red leg: the Windows leg is the explicit verification boundary for #900 / #869 (atomic_file_race's unchanged <1% refusal claim after staging#617); it cannot be measured until this is fixed.

Fix candidates, in order of preference:

1. Fetch the two archives from a dated cygwin time-machine snapshot, which never rotates. Verified serving today (HTTP 200, 40954 and 27775 bytes):
   http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/2026/09/03/134715/x86_64/release/pkgconf/pkgconf-2.5.1-1-x86_64.tar.zst and .../pkgconf/libpkgconf7/libpkgconf7-2.5.1-1-x86_64.tar.zst. One-line change to $base; plain http, so pin the SHA-512 from the .hint files (pkgconf-2.5.1-1-x86_64.hint sits beside each archive in the same snapshot) if the fetch is to stay trustworthy.
2. Vendor the two .tar.zst files (68 KB together) under .github/ and drop the network fetch entirely.
3. Retest whether cygwin's current pkgconf 3.0.6 still has the two --personality regressions the FIXME above the step documents (personality.d lookup path, ignored DefaultSearchPaths). If fixed, the whole three-step downgrade can go, per the FIXME's own exit condition.

Whatever lands, the Windows leg that follows it is the one that finally answers #900.

[lukstafi]

Confirmed: the predicted next scheduled sweep failed exactly as described.

Run: https://github.com/lukstafi/ocannl-staging/actions/runs/34008717573 (schedule, master@df447ccc)

Both Build (windows-latest, 5.5.x, main) and Build (windows-latest, 5.5.x, train) died at Restore cygwin pkgconf 2.5.1 (Windows):

curl: (22) The requested URL returned error: 404
/usr/bin/tar: pkgconf-2.5.1-1-x86_64.tar.zst: Cannot open: No such file or directory
expected pkgconf 2.5.1, got '3.0.7' (extraction failed? this needs a tar with zstd support)

Note the mirror has rotated again since this issue was filed (now serving 3.0.7, not the 3.0.6 seen on 2026-09-05) — consistent with the root cause: cygwin.mirror.constant.com keeps only current releases, so any fetch pinned to $base there will keep breaking regardless of which old version is targeted. This reinforces fix candidate 1 (dated time-machine snapshot, which is pinned to a point in time rather than "current") or candidate 2 (vendor the ~68KB of .tar.zst files) over re-pinning to a different version string on the live mirror.

This routine (CI-red triage) is standing down here since this issue already owns the diagnosis and fix candidates — not opening a duplicate claim or PR. The macOS/ubuntu/train legs on this same run were all green; this is Windows-only, as documented.

---

Generated by Claude Code

[lukstafi]

Fix in lukstafi#676, and it is candidate 3: cygwin's current pkgconf (3.0.7-1, 2026-09-04) loads the x86_64-w64-mingw32 personality again and the mingw depexts install against it — verified on both Windows legs of the extended dispatch run https://github.com/lukstafi/ocannl-staging/actions/runs/34262512499 (Install system dependencies (Windows), the personality check, Install opam dependencies (Windows) all green). So the downgrade goes entirely, per the FIXME's own exit condition; the leg keeps a one-step personality check so a recurrence names itself. Vendoring the 2.5.1 archives (candidate 2) also worked on run 34266955741 and is not landed. Past setup both runs fail two Windows-only test problems unrelated to setup, filed as their own issues.

[lukstafi]

Landed in lukstafi#676 (merge f0b896b): the Windows leg installs the pkgconf cygwin ships (3.0.7-1 loads the mingw personality; verified on both Windows legs of run 34262512499), the 2.5.1 restore step is gone, and a one-step personality check stays so a recurrence names itself. The next scheduled Windows run (Wednesday 03:00 UTC) is the first on the fixed path; it will show the two Windows-only test failures filed as gh-ocannl-957 and gh-ocannl-958, which are not setup.