PR was merged after the switch to haskell.lib.compose by default, but
originally created before that day, so the argument order used was
completely wrong, but CI didn't show it, because its state was stale.
`nix-tree >= 0.19` requires `brick >= 0.64` which is not the default
on the stackage resolver yet. This commit adds an override for the correct
version.
overrideScope applies an overlay that fixes the build error for
libyaml-streamly, however the (correct) broken state of the package in
the normal package set is incorrectly inherited, so a markUnbroken is
required.
Since https://github.com/diagrams/diagrams/issues/26 has been solved,
all diagrams-related libs finally work together in their latest version
and we can remove the constraints on the following updated packages.
* haskellPackages.monoid-extras: 0.5.1 -> 0.6
* haskellPackages.diagrams-lib: 1.4.3 -> 1.4.4
Also allows us to get rid of a patch for optparse-applicative 0.16 support.
* haskellPackages.dual-tree: 0.2.2.1 -> 0.2.3.0
Allows us to drop jailbreak.
* haskellPackages.diagrams-core: 1.4.2 -> 1.5.0
Allows us to drop jailbreak.
Some reverse dependencies of said libraries had too strict bounds, but
fortunately no new regressions (as far as I am aware) have been
introduced. Jailbreaks were needed for:
* diagrams-braille
* Chart-diagrams
* namespace
* plots
* Chart-tests
preCheck should reuse the old preCheck phase, not the postPatch
phase (which for example would contain the jailbreak-cabal call). Also
use overrideCabal which should have less pitfalls in this context.
Fails to compile with stackage's brick version and additionally depends
on packages depending on brick, so overrideScope is necessary. Should be
fine as this is a leaf package.
The first patch we were applying before didn't build on darwin so I created a
new PR building on that, adding a darwin conditional adding the missing flag.
Since this version of haskell-ci is effectively necessary to regenerate
the GitHub workflow for cabal2nix, let's not require contributors to
build this locally using cabal-install.
`ghc-vis` doesn't support library profiling, as noted in:
> http://felsin9.de/nnis/ghc-vis/#installation
This gets the package building and it runs fine when called from ghci as you
normally would, however when you actually try viewing an expression it fails
with the following error message:
```
ghc: Error running utility program: Unable to call the command dot with the
arguments: " -Txdot " because of: dot: runInteractiveProcess: posix_spawnp:
does not exist (No such file or directory)
```
As far as I can tell that is because `ghc-vis` needs to run dot at runtime but
since it's a library adding `graphviz` as a dependency doesn't quite do the
trick.
And while not ideal adding `graphviz` to the shell you're running `ghc-vis` at
works around this issue.
librsvg version 2.51.0 renames librsvg-features.h to rsvg-features.h and with
08fcd73d9d going in svgcairo broke again.
Renaming the library in the call site fixes the build.
Some version upgrades caused attributes to disappear. The upgrade from
language-docker 10.1.2 to 10.2.0 introduces a test failure which is
caused by missing files in the release tarball, so we need to fix this
up manually.
Previously ghcup was failing because of incompatibilities between optics
0.3 and 0.4. I'm personally not sure if hspec-golden-aeson 0.9.0.0 is
strictly necessary, but we may as well use this opportunity to start
ironing out the issues its quirky behavior since 0.8.0.0 causes.
This is fixed properly in candid 0.3 which we'll have soon, but in
the meantime we can just disable the offending warning. A real shame
that doctests are influenced by compiler warnings.
There's an open pull request that fixes the build but it's been sitting there
for a while, the fix is in a single commit so just applying the commit as a
patch. This will also allow us to fix ghc-vis later.
* haskell.packages.ghc884.ghc-api-compat needed us to re-add the 8.6
version of the package.
* haskell.packages.ghc901.ghc-api-compat now points to the newly
released 9.0.1 version of the package.
* haskell.packages.ghc8107.ghc-api-compat now correctly points to
ghc-api-compat 8.10.7.
GHC 9.2.1 is still unsupported (which is to be expected, with it
being a release candidate).
To make sure everything stays working we'll build ghc-api-compat as part
of versionedCompilerJobs.
ats-format has a custom Setup.hs which does the following using cli-setup:
* Add ~/.local/share/man to $MANPATH by editing shell configurations in $HOME.
* Install a man page into ~/.local/share
* Install a shell completion by editing shell configurations in $HOME.
We had a workaround to keep this from failing the build in the nix sandbox, but
this seemingly broke on darwin. To fix this once and forall, we force the use
of only `defaultMain` in Setup.hs and install the man page manually.
Additionally we generate completions and remove unnecessary extra references
from the closure.
We employ a workaround for a GHC bug [1] which has been adopted by both
Debian and Fedora for a eerily similar problem on ppc64le. Hopefully
this fixes our aarch64 issue as well (untested so far). -O0 is not
ideal, but compilation with -fllvm fails when linking (due to an
invalid relocation and passing -fPIC wasn't enough to fix it), so
we're stuck with this for now.
[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/17203
Test suite depends on an old version of base16-bytestring (but has not
set up constraints for it). Can't be bothered to add an old version of
it, let's just disable the test suite for now. This should fix itself
sooner or later.
* no released version of hackage2nix does support distribution-nixpkgs yet.
* hackage-db 2.1.2 fixes an annoying bug introduced in 2.1.1 and also supports
Cabal 3.4: https://github.com/NixOS/cabal2nix/issues/501
