2.4.0.0: cabal update: Verification loop. Errors in order: <repo>/timestamp.json is expired

[benz0li]

Your environment

Which OS do you use? Alpine Linux 3.18.4

Which version of GHC do you use and how did you install it? 9.8.1
👉 Docker image glcr.b-data.ch/ghc/ghc-musl:9.8.1 (https://github.com/benz0li/ghc-musl)

Steps to reproduce

On a host with docker installed

docker run --rm -ti glcr.b-data.ch/ghc/ghc-musl:9.8.1 bash

Inside the container

export HLS_VERSION=2.4.0.0 \
  && apk add --no-cache patchelf findutils \
  && cd /tmp \
  && curl -sSL "https://github.com/haskell/haskell-language-server/archive/refs/tags/$HLS_VERSION.tar.gz" \
    -o "haskell-language-server-$HLS_VERSION.tar.gz" \
  && tar -xzf "haskell-language-server-$HLS_VERSION.tar.gz" \
  && cd "haskell-language-server-$HLS_VERSION" \
  && . .github/scripts/env.sh \
  && . .github/scripts/common.sh \
  && sed -i.bak -e '/DELETE MARKER FOR CI/,/END DELETE/d' cabal.project \
  && GHCS="$GHC_VERSION" \
  && export GHCS \
  && ARTIFACT="$(uname -m)-linux-alpine" \
  && export ARTIFACT \
  && cabal update \
  && emake hls-ghc \
  && emake bindist \
  && strip "out/bindist/$ARTIFACT/haskell-language-server-$HLS_VERSION/lib/$GHC_VERSION"/*.so \
  && emake bindist-tar

Expected behaviour

HLS builds successfully. E.g. https://gitlab.b-data.ch/ghc/ghc-musl/-/jobs/84985

Actual behaviour

Script errors at cabal update. E.g. https://gitlab.b-data.ch/ghc/ghc-musl/-/jobs/87062

Debug information

fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/2) Installing findutils (4.9.0-r5)
(2/2) Installing patchelf (0.18.0-r1)
Executing busybox-1.36.1-r2.trigger
OK: 523 MiB in 102 packages
Config file path source is default config file.
Config file not found: /cabal/config
Writing default configuration to /cabal/config
Warning: Caught exception during _mirrors lookup:DnsNoData
Warning: No mirrors found for https://ghc.gitlab.haskell.org/head.hackage/
Downloading the latest package lists from:
- hackage.haskell.org
- head.hackage.ghc.haskell.org
Verification loop. Errors in order:
  <repo>/timestamp.json is expired
  <repo>/timestamp.json is expired
  <repo>/timestamp.json is expired
  <repo>/timestamp.json is expired
  <repo>/timestamp.json is expired

Cross references

Updated: 2023-11-16T05:50+01:00

• https://discourse.haskell.org/t/cabal-install-3-10-2-0-released/8009/11
  • https://github.com/haskell/security-advisories/blob/main/advisories/hackage/cabal-install/HSEC-2023-0015.md

[benz0li]

Your build seems to be affected, too.

❓Because this (errors ignored) results in

Warning: Requested index-state 2023-10-06T06:12:29Z is newer than 'head.hackage.ghc.haskell.org'! Falling back to older state ().

instead of

Warning: Requested index-state 2023-10-06T06:12:29Z is newer than 'head.hackage.ghc.haskell.org'! Falling back to older state (2023-10-05T15:13:19Z).?

[michaelpj]

@wz1000 did you observe this?

[wz1000]

No, but I think index-state doesn't play very well with head.hackage. Perhaps we should move the index-state into a if impl(ghc < 9.7) block.

[benz0li]

Any advice on how to patch cabal.project to enable building HLS 2.4.0.0 with GHC 9.8 again?

[michaelpj]

Could we just set the index-state for hackage.haskell.org? I think you can do that.

[benz0li]

Could we just set the index-state for hackage.haskell.org? I think you can do that.

It used to work. See pipeline from 2023-10-11: https://gitlab.b-data.ch/ghc/ghc-musl/-/jobs/84985

...
Config file path source is default config file.
Config file not found: /cabal/config
Writing default configuration to /cabal/config
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 supports 'ghc' version < 9.8): /usr/local/bin/ghc is version 9.8.1
Warning: Caught exception during _mirrors lookup:DnsNoData
Warning: No mirrors found for https://ghc.gitlab.haskell.org/head.hackage/
Downloading the latest package lists from:
- hackage.haskell.org
- head.hackage.ghc.haskell.org
Package list of head.hackage.ghc.haskell.org has been updated.
The index-state is set to 2023-10-05T15:13:19Z.
Package list of hackage.haskell.org has been updated.
The index-state is set to 2023-10-11T05:00:27Z.
mkdir -p out/x86_64-linux-alpine
mkdir -p out/plan.json
cabal --store-dir=/tmp/haskell-language-server-2.4.0.0/store/x86_64-linux-alpine configure --project-file="cabal.project" -w "ghc-9.8.1" --disable-tests --disable-profiling -O2  exe:haskell-language-server exe:haskell-language-server-wrapper
cabal --store-dir=/tmp/haskell-language-server-2.4.0.0/store/x86_64-linux-alpine build --project-file="cabal.project" -w "ghc-9.8.1" --disable-tests --disable-profiling -O2  --dependencies-only --dry-run exe:haskell-language-server exe:haskell-language-server-wrapper
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.10.1.0 supports 'ghc' version < 9.8): /usr/local/bin/ghc-9.8.1 is version 9.8.1
Warning: Requested index-state 2023-10-06T06:12:29Z is newer than 'head.hackage.ghc.haskell.org'! Falling back to older state (2023-10-05T15:13:19Z).
...

[benz0li]

Issue opened for head.hackage: https://gitlab.haskell.org/ghc/head.hackage/-/issues/94

FYI @hasufell

[benz0li]

Thanks for your report! I've applied a temporary fix, so if you run cabal update again it should work now. We should have a proper fix some time next week 🤞

– #94: cabal update: Verification loop. Errors in order: <repo>/timestamp.json is expired · Issues · Glasgow Haskell Compiler / head.hackage · GitLab

[hasufell]

Thanks for your report! I've applied a temporary fix, so if you run cabal update again it should work now. We should have a proper fix some time next week 🤞

– #94: cabal update: Verification loop. Errors in order: /timestamp.json is expired · Issues · Glasgow Haskell Compiler / head.hackage · GitLab

That link seems broken

[hasufell]

I suggest to stop relying on head.hackage. That seems like a huge can of worms for various reasons.

[benz0li]

That link seems broken

Link fixed. (https://gitlab.haskell.org/ghc/head.hackage/-/issues/94#note_535251)

I suggest to stop relying on head.hackage.

Agreed.

Unless there is a proper fix for head.hackage, building HLS 2.4.0.0 with GHC 9.8 will no longer work.

[mpickering]

If not relying on head.hackage, what is the proposed means to provide HLS support for recently releases GHC versions? Users have regularly commented that they appreciate HLS being available in close proximity to GHC releases.

[hasufell]

If not relying on head.hackage, what is the proposed means to provide HLS support for recently releases GHC versions?

We can provide an experimental configuration in the repo (a separate cabal.project) and then document how to use it with ghcup compile hls (that is easy).

I don't think it's a good strategy to rely on head.hackage at all and build a proper release that depends on partially unapproved/unmerged patches.

[wz1000]

I don't think that the unapproved nature of packages on head.hackage is a serious concern, but I agree that head.hackage is fragile and not ideal to depend on.

For now the plan is to remove the dependency on head.hackage by publishing the outstanding patched packages.

In the future we can use source-repository-packages with patches from head.hackage applied instead of depending directly on head.hackage.

[hasufell]

In the future we can use source-repository-packages with patches from head.hackage applied instead of depending directly on head.hackage.

If someone wants to put in the work, yes. I also want to add that all such source-repository-package stanzas should have a comment with a link to the upstream PR.

[michaelpj]

If someone wants to put in the work, yes. I also want to add that all such source-repository-package stanzas should have a comment with a link to the upstream PR.

💯 same for all allow-newers

[michaelpj]

We removed head.hackage.