feat: bump to stack 3.11.1 in 9.12 and 9.14 images

[jhrcek]

Stack 3.11.1 is now the blessed recommendation of ghcup, so should be safe.

[develop7]

LGTM, thanks for heads up!

[jhrcek]

Hey @develop7
it seems it's not possible to just update the official-images repo, docker-library/official-images#21812 - see "Test PR / Naughty (pull_request)" job failure in that PR.

The failure is caused by the base images having been updated in the meantime - e.g. FROM debian:bookworm@sha256:ed4fcc40bb1162b6d2d32e7bec15044d13963779abbe63f67f1cd62b06220519 - latest debian:bookworm no longer has that digest as the base image content changed.

The issue is that we can't just merge the PRs from renovate like #206, because those only bump the hashes in dockerfiles (as opposed to in nicker configs).

I wonder if you have any general thoughts about making the updates more ergonomic..

[develop7]

Does the Naughty error mean we've been running amd64 images on aarch64 runners all along?

[jhrcek]

@develop7 I don't think it's because of that.
I used claude fable to help me troubleshoot and it managed to reproduce the failure locally by running the naughty.sh script in an environment similar to what's used in CI:

# run this in the docker-library/official-images with PR https://github.com/docker-library/official-images/pull/21812 checked out
nix shell nixpkgs#go nixpkgs#jq --command bash -c '
  go install github.com/docker-library/bashbrew/cmd/bashbrew@v0.1.14
  export PATH="$(go env GOPATH)/bin:$PATH"
  export BASHBREW_LIBRARY="$PWD/library"
  bash -x .github/workflows/naughty.sh haskell
'

The failure comes from this branch of the script naughty-from.sh which doesn't strip the @sha256... part of the FROM and then considers the whole thing as a tag, which it fails to fetch.

Quoting Fable directly:

This confirms the diagnosis from before: the digest-aware branch (/@sha256:*) only matches images with a '/' in the name (external images like mcr.microsoft.com/...), so debian:bookworm@sha256:... falls into the "official image" branch where bashbrew looks up the string bookworm@sha256:... as a literal tag name in library/debian — which can never exist. The minimal repro pair:

bashbrew cat --format '{{ .TagEntry.HasArchitecture arch | ternary arch "" }}' 'debian:bookworm@sha256:30482e87...'   # exit 1
bashbrew cat --format '{{ .TagEntry.HasArchitecture arch | ternary arch "" }}' 'debian:bookworm'                      # exit 0, prints "amd64"

So the local repro fully confirms it: no digest value can pass this check, and un-pinning the FROM lines in docker-haskell is the fix. Once you've regenerated the Dockerfiles there, you can re-run this same command with the updated GitCommit in library/haskell to verify the check goes green before pushing.

END OF QUOTE

So it seems to me we'll have to remove the "@sha256..." digests from the FROMs to fix this..

[jhrcek]

@develop7 now confirmed by one of the official images maintainers:

Unfortunately, we do not support pinning FROM values by digest (it explicitly counteracts one of the primary goals of the program -- proactively rebuilding images when their parent has updates).