Repository navigation
cabal: source pinned to a GitHub auto-generated archive; hash mismatch on a cold fetch (sweep for the class) #756
Description
Found while running a world rebuild on a fresh fleet-prototype host (build-servers#316 round 3), 2026-09-23 21:05Z.
packages/cabal/build.ncl pins a GitHub auto-generated archive:
url = "https://github.com/haskell/cabal/archive/refs/tags/cabal-install-v%{version}.tar.gz"
sha256 = "ae794d9b803b31922a80338f4671a3abd8eba995424db549438ad211f4657193"
On a host with an empty downloads/ the fetch came back with a different hash and the build failed with HashMismatch: want=ae794d…, got=c3d51e…. The API tarball for the same tag hashes differently again today (1a2f53…). Prod does not see this because res-server's persistent downloads/ still holds the archive from the day it was pinned, so the pin is never re-checked against upstream.
GitHub's /archive/... tarballs are generated on the fly and are not byte-stable across their tooling changes; every recipe that pins one is a latent world-rebuild breaker the moment a source cache is cold. The fix is the pattern harfbuzz and most recipes already use: mirror the archive to gs://minimal-staging-archives/ and pin that. Worth a sweep for github.com/*/archive/ in packages/*/build.ncl rather than fixing only cabal.
Related: minimal#1577 (the mismatch is now enforced, which is how this surfaced), pkgs#419 (pinning dep stores as mirrored sources), build-servers#316 (fleet hosts start with an empty source cache, so this class stops being latent).
Activity
bryan-minimal commentedon Sep 23, 2026
Scope of the class:
grep -l 'github.com/.*/archive/' packages/*/build.nclmatches 136 recipes today. Each one is a cold-cache failure waiting for its upstream to regenerate the tarball.