Use the upstream release with relaxed dependency bounds and declared
test build tools. Fetch it without IFD and keep the built executable on
PATH during checkPhase.
cabal-fmt now builds well without the override for `Cabal-syntax` ([but
with jailbreaking for other dependencies][cabal-fmt#98]) on GHC versions
9.6 and up (and possibly on earlier versions; I did not test it).
[cabal-fmt#98]: https://github.com/phadej/cabal-fmt/issues/98
IHP needs hasql >= 1.10 via hasql-mapping. Use overrideScope to pin
IHP to the newer hasql versions which are already available as
version-suffixed extra-packages, keeping the Stackage LTS 24 defaults
for the rest of the package set.
The scope renames the hasql-stack attributes for IHP and unmarks
hasql-mapping (which is version-resolution-specific, mirroring the
hasql-notifications entry in the postgrest scope). hasql-mapping
stays in broken.yaml because it genuinely fails against the default
hasql 1.9.3.1 from Stackage LTS 24. dontCheck for the scoped deps
lives in the top-level overlay so it can apply to the versioned
attributes; tests are disabled because they connect to PostgreSQL /
docker at runtime.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
I used
nix-build maintainers/scripts/haskell/test-configurations.nix \
--argstr files configuration-common.nix --keep-going
to find overrides in configuration-common.nix for packages that fail to
build or have a broken dependency. I then went through the list of
overrides this generated and removed them unless I thought it may be
useful too keep them around.
- Overrides that don't contain much information and are easy to add back
if need be, e.g. doJailbreak or dontCheck without further information.
- Workarounds for packages that are unmaintained or have been broken for
a long time. This applies to _a lot_ of the packages in this commit,
so they are likely also good candidates for exclude-packages in the
future.
- Overrides for issues that have since been closed.
- I also dropped overrides for packages that fail due to a new issue
that would require a new release anyways.
- Patches are usually dropped for one of the reasons above, but also
relatively easy to find again and add back.
Supposedly, Mercury are going to release a new version of this package
soon™ after they have been granted maintainership, so there is probably
some value in keeping this around despite the package being broken at
the moment.
Wolfgang Walther