Open simonpj opened 5 months ago
I expect running the curl https://ghc.gitlab.haskell.org/head.hackage/cabal.project >> cabal.project.local
command from https://ghc.gitlab.haskell.org/head.hackage/ twice is not an uncommon pitfall nowadays, so it would be useful if cabal errored out early or reacted more gracefully than racing with itself. :)
I've run into this too, except that I didn't repeat the repository head.hackage.ghc.haskell.org
stanza, and running cabal update
failed very deterministically for me. The only way I was able to fix the error was to delete ~/.cache/cabal/packages/head.hackage.ghc.haskell.org
and run cabal update
afterwards.
I get this every so often as well. I think it usually happens when I switch cabal version, but am not certain.
@Mikolaj It happens to me too, it's indeed something to do with switch cabal versions. Here are some ways I manage to reproduce it, but it's not deterministic when the error happens.
In a haskell repo with a cabal.project,
1) rm -rf /tmp/cabal 2) cabal clean && rm cabal.project.freeze 3) CABAL_DIR=/tmp/cabal cabal-3.12.1.0 update 4) CABAL_DIR=/tmp/cabal cabal-3.10.3.0 build all --dry-run
Some times you'll already see the error at this point, however at other times you'll have to switch the version again and run update or some other action
5) CABAL_DIR=/tmp/cabal cabal-3.12.1.0 update
In the repo I reproduced this, we have an additional repository in our cabal.project. and the resource busy error always points to this additional repo's 01-index.tar
We encountered this when using https://github.com/MangoIV/cabal-audit with setup-haskell actions as the actions runs update with the latest release cabal, but cabal-audit seems to use an older cabal-install / Cabal library
I removed the directory, typed
cabal update
, and it complained about a locked file in that very directory.Seems non-deterministic. Re-running
cabal update
sometimes works.@Mikolaj found that cabal.project.local had the same entry twice. See below. Maybe that's the reason