`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
1.1.0.0 brings us compatibility with opaleye >= 7.3.0.0, so we can get
rid of the old version as well. tmp-postgres was incorrectly marked as
broken (maybe due to a flaky failure) and can be unmarked.
hnix needs these versions since 0.13, but we previously patched it to
use the versions tracked in stackage because that reduces the risk of
multiple versions of a package being propagated in the dependency tree
and breaking a build.
One major release later, patching hnix has become quite cumbersome, so
we'll bite the bullet for now and return to this approach if any
problems come up.
The source tarball now has DOS line endings for some reason, requiring
the use of dos2unix. Also needs a jailbreak since the template-haskell
bound has become too strict.
Upstream introduced too strict lower bounds in a new release. Since it's
too much hassle to create a new account in their redmine just for this
issue, I've used asserts to indicate when this will be able to be
removed.
Fix instances of tool dependencies coming from `self` or `pkgs`
instead of `self.buildHaskellPackages` or `pkgs.buildPackages`
respectively. This makes sure cross-evaluation and -compilation will
work although their may still be more kinks to work out (or cases I
missed). This change was mostly created by searching for `[tTool]` and
`\${` in the respective files.
Note that this has intentionally not been for test tool dependencies:
Like in `stdenv.mkDerivation` we need to view tests as being executed
on the *host platform* which is why we can't run tests while cross
compiling anyways. In practice this is not an important distinction,
though: `pkgs.buildPackages` and `pkgs` are almost identical in the
native case.
Resolves#127232.
For native compilation, we can just add the intermediary build
directory to `PATH` which allows the test suite to be preprocessed by
tasty-discover itself.
When cross-compiling, `doCheck` will be false anyways and this won't
matter (fingers crossed!).
If we are cross compiling we can't and don't run the tests since they
wouldn't be able to be executed on the host platform.
While native compiling, we need to avoid an infinite recursion.
stackage LTS 18 luckily updated haskell-gi and related libraries to
0.25, so we can remove a lot of overrides. I also unrestricted some of
them in configuration-hackage2nix/main.yml and removed the overrides
updating them in configuration-common.nix (I guess the person doing
the upgrades thought those libraries were also in stackage).
Add assert which will fail when the overrides can be removed. Upstream
has patched the bounds, but hasn't made a new release nor a hackage
revision so far.
Every flag the generic builder receives via `testFlags` is passed via
`--test-option` [1] to `Setup.hs` which in turn passes them to the
underlying test suite binary. These wrapped options are added to
`checkFlagsArray` in `checkPhase`. This needs to be done in bash since
without structuredAttrs in nixpkgs so far, Nix arrays aren't properly
translated into bash arrays, so we'd have all sorts of quoting issues
when spaces are involved.
Re-using `checkFlags` and `checkFlagsArray` from standard stdenv
setup.sh also results in an additional feature: Using `overrideAttrs`
`checkFlags` and `checkFlagsArray` can additionally be overridden,
which allows passing extra flags to `Setup.hs` whithout being wrapped
with `--test-option`.
[1]: See also https://cabal.readthedocs.io/en/3.4/setup-commands.html?highlight=test-option#cmdoption-runhaskell-Setup.hs-test-test-option
According to the cabal-install man page this also allows passing
special variables which are substituted for other values
depending on context.
While diagrams-lib 1.4.4 doesn't per se require us to update any
diagrams lib to 1.5.0 it would require monoid-extras 0.6 which would
force us to update diagrams-core to 1.5.0, thus breaking
haskellPackages.diagrams.
Since we can just keep the patch we fetch and downgrade to 1.4.3, we
can continue sitting out the slow update cycle of the diagrams universe.
This reverts commit 52d69816b0.
Unfortunately there is no way to update to monoid-extras 0.6 yet without
marking some packages as broken. The issue is that not all diagrams*
packages have had an update adding support for GHC 9.x yet (which would
also include monoid-extras 0.6 support). The only alternative to pinning
diagrams* and monoid-extras would be to have mismatched versions between
them which always causes issues with haskellPackages.diagrams.
Note that this commit re-introduces some build failures which are to be
fixed in a follow-up commit.
Seems like the monoid-extras situation wasn't as bad as I thought and
some new releases in the meantime make every diagrams package we had
working previously work again.
* haskellPackages.monoid-extras: 0.5.1 -> 0.6
* haskellPackages.diagrams-lib: remove now unnecessary patch
* haskellPackages.namespace: jailbreak to build with new monoid-extras
