repro: Windows vcpkg fresh install fails on blosc/msys2-pkgconf 404 (do not merge)

[Fedr]

Purpose

Minimal reproduction PR (branched from current master, no overlay changes) demonstrating that a fresh Windows vcpkg install fails in blosc:x64-windows-meshlib with a 404 download error during vcpkg_fixup_pkgconfig().

Do not merge. This PR exists only to isolate the failure on master (not on a feature branch) and confirm that it is independent of any other in-flight changes.

What the PR changes

A single line in .github/workflows/build-test-windows.yml:

-          key: vcpkg-cache-${{ matrix.vcpkg-version }}
+          key: vcpkg-cache-${{ matrix.vcpkg-version }}-repro-blosc-msys2-2026-04-20

The new cache key has never been populated, so actions/cache will produce a cold miss on the first run of this PR. install.bat then runs vcpkg install ... against an empty C:\vcpkg\installed\, and every port in requirements/windows.txt (plus transitive deps) is built from scratch — which is the trigger for the bug.

What to expect in CI

• windows-build-test matrix legs should fail in the Update vcpkg packages step, with output shaped like:

  -- Fixing pkgconfig file: C:/vcpkg/packages/blosc_x64-windows-meshlib/lib/pkgconfig/blosc.pc
  -- Downloading https://mirror.msys2.org/.../mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst ...
  error: Missing msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst
  error: https://mirror.msys2.org/.../mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst: failed: status code 404
  error: https://repo.msys2.org/.../mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst: failed: status code 404
  error: https://mirror.yandex.ru/...:                                                    failed: status code 404
  error: https://mirrors.tuna.tsinghua.edu.cn/...:                                        failed: status code 404
  error: https://mirrors.ustc.edu.cn/...:                                                 failed: status code 404
  error: https://mirror.selfnet.de/...:                                                   failed: status code 404
  error: building blosc:x64-windows-meshlib failed with: BUILD_FAILED
  

• Non-Windows matrix legs are disabled via labels (disable-build-macos, disable-build-ubuntu-x64, disable-build-ubuntu-arm64, disable-build-linux-vcpkg, disable-build-emscripten) so the CI surface is just the three Windows matrix legs.

Root cause (from the zlib-ng PR investigation, run 24653463132)

• blosc's upstream vcpkg portfile calls vcpkg_fixup_pkgconfig() which invokes vcpkg_acquire_msys(PKGCONFIG) → downloads a specific pinned version of mingw-w64-x86_64-pkgconf (currently 1~2.2.0-1).
• msys2 mirrors retain only the latest version of each package in their live repos. Older versions that vcpkg still pins are pruned from every mirror, producing hard 404s.
• Stale vcpkg pin × msys2 pruning = fresh installs 404. Cached installs work because the download step is skipped.

Why master itself doesn't show this

Master's Windows vcpkg cache is a consistent hit every run (cache key is just vcpkg-cache-${{ matrix.vcpkg-version }}, nothing varies between runs). No port ever rebuilds, vcpkg_fixup_pkgconfig() is never re-invoked, and the 404 never fires. Any change that busts the cache will expose this — including PR #5932 (zlib-ng overlay) and PR #5934 (principled cache-key invalidation on overlay changes).

Possible paths forward (not proposed here, for discussion)

1. Bump Windows matrix vcpkg-version pins past the broken pkgconf pin. A newer vcpkg release that pins a still-available pkgconf solves the root cause.
2. Overlay the blosc port (and any other port calling vcpkg_fixup_pkgconfig()) to skip the call on Windows. Whack-a-mole.
3. Pre-download the msys2 pkgconf package into a private mirror / S3 asset store and point vcpkg at it via x-asset-sources. Robust but operationally heavier.
4. Upstream fix — a vcpkg issue filed at microsoft/vcpkg to update the pkgconf pin. Passive.

[Fedr]

Closing — the repro approach in this PR doesn't actually trigger the bug.

Run 24662333477 (this PR's first CI run) succeeded on all three Windows matrix legs, including fresh-install ones (msvc-2019 @ 2024.10.21 and msvc-2022 Debug @ 2026.03.18 both hit 'Cache not found' on the GHA cache layer). The reason it still succeeded: MeshLib's Windows 'install.bat' uses vcpkg's S3 binary caching with '--write-s3'. vcpkg checks the S3 binary cache by per-package ABI hash, and all unchanged packages (blosc, freetype, zlib, zstd, etc.) have prebuilt archives there — blosc installed in 38 ms, no build-from-source, no 'vcpkg_fixup_pkgconfig()' call, no msys2 pkgconf download, no 404.

The failure first observed on PR #5932's branch is narrower than I originally described: it only happens when a change invalidates ABI hashes of ports that call 'vcpkg_fixup_pkgconfig()'. PR #5932 does that because swapping 'zlib' → 'zlib-ng-compat' shifts zlib's ABI hash, which cascades to every transitive dependent (zstd, blosc, libzip, openvdb, …), and none of those new ABIs are in S3. So vcpkg builds them from source, where 'vcpkg_fixup_pkgconfig()' runs and hits the msys2 pin 404.

A GHA cache miss alone does not trigger this failure. An ABI-hash change does.

Implication for PR #5932: still real, still blocks that PR. Implication for master: not an immediate risk — master's Windows CI is safe as long as S3 has a prebuilt for every current ABI.

Not a good place to track this further. If follow-up investigation is wanted, a more faithful repro would bump 'vcpkg-version' in the matrix past an ABI-affecting upstream change, or overlay a port whose ABI change cascades. Neither is worth doing here proactively.