* 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
Compiles with random 1.2.0, but bounds are too strict. Just fully
jailbreak instead of patching the bounds like before (upstream
maintenance seems poor at this point, so this is futile work
unfortunately).
hashable's test suite pins random to < 1.2 even in the latest release on
hackage, but lifting the bound fixes the build without any issues. Using
a patch so we are reminded to remove it when it's unnecessary.
https://github.com/haskell-nix/hnix/pull/922 removed a few build-depends
from hnix.cabal which are still required until the following constraints
apply to stackage:
* relude >= 1.0.0.0
* semialign >= 1.2
Luckily, we can simply revert a few commits from master and add
semialign-indexed to resolve this without too much hassle nor
extra-packages (which may cause us trouble through propagation of a
newer relude).
Compilation failures are related to GHC updates and other issues which
have been resolved on the package's development repository, but not yet
released. Fetching two patches resolves the problems which is probably a
midterm solution since the repository hasn't seen any activity this year
yet.
The mystery build failure was caused by having the same instance as an
orphan and imported from ref-tf 0.5 (why ever that doesn't warrant a
logged error message…). The solution for this is
https://github.com/haskell-nix/hnix/pull/918, which sadly doesn't apply
cleanly on the hnix 0.12.0.1 tarball. Therefore I've backported the
patch until hnix hopefully gets a new hackage release soon.
Introduces a script that can be used to update the Nix expressions for
the Haskell package set. In service of that, also
- introduces cabal2nix-latest, which pins the hackage2nix version used
- changes all-cabal-hashes to use fetchFromGitHub
- adds update-hackage.sh & update-cabal2nix-latest.sh & update-stackage.sh maintainer scripts
No idea why essence-of-live-coding-warp constrains on >= 0.2.5, but if
it breaks something jailbreaking this then it's on them for not
following PVP, I guess.
* Enable exactly one backend (Native seems like the safest choice, but
GMP also seems sane, interested to hear opinions on this!)
* Apply patch which fixes a type mismatch issue between Natural.hs and
Natural.hs-boot.
An upper bound on vector-builder was introduced which includes 0.3.8,
but excludes 0.3.8.1. I don't know why, but the changes between 0.3.8
and 0.3.8.1 look harmless enough to ignore. Possibly the
hgeometry-combinatorial maintainer operated under the assumption that
the author of vector-builder would always use version numbers which only
had 3 components.
The patch I proposed yesterday and vendored in here as a precautionary
measure in case I'd have to amend it in order for it to got merged, has
been accepted without changes.
Thus we can remove the patch file from the tree and just use fetchpatch.
Requires a jailbreak currently because the hackage version bounds are
somewhat outdated. Also regenerate the package set, so the next hydra
evaluation picks up on this.
pandoc 2.12 changed and removed a few exports gitit used. I procured a
patch which fixes those without any refactoring by vendoring in the
removed function from pandoc which is no problem as they are both
available under the GPL 2.0.
This override currently breaks eval, but is probably still necessary in
some form. However the change to fix it is non-trivial and not quickly
actionable as hls-plugins-api currently is broken so the intended target
of the override (haskell-language-server) can't be tested.
Something in a similar spirit would be pinning lsp-test to 0.14.0.0
which would however require to pick this patch from
haskell-language-server master:
6d1f1a55e3
To me this sounds like a promising solution as it also adjusts to lsp
1.2 which we now have in haskellPackages. Supposedly it also fixes some
tests, so maybe we can remove the dontCheck.
cc @maralorn
Getting compatibility with optparse-applicative >= 0.16 only required
pulling in a patch from master which is unreleased unfortunately.
The old overrides were obsolete except for the jailbreak as the test
fixes made their way into the latest release.
hegdehog-classes allows us to build these now, hgeometry-combinatorial
needs disabling of test suite since doctests cause some kind of run time
linking issue.
chatter's latest hackage release still depends on regex-tdfa-text, but
we can apply a patch from master to remove that dependency and jailbreak
to relax the bounds on cereal. Both these issues are already resolved
on master, so the override should only stand until the next release
comes around.
Additionally the test suite needs disabling as it doesn't list all
required modules in other-modules and thus fails to compile. The issue
has been reported upstream.
haskellPackages.fullstop: unbreak
Unfortunately fullstop is practically unmaintained and has no issue
tracker. The build failure is fortunately only affecting the test suite,
so a dontCheck resolves the issue for now.
Add an override to configuration-common.nix adding the following
features to the derivation:
* Let test suite discover the built spacecookie binary, so it doesn't
skip integration tests (which are very cheap and take just over 1s).
* Install man pages shipped in the sdist. (If someone is eager to get
rid of this override feel free to explain to me how to achieve this
without a Custom build-type which pulls in thousands of modules from
Cabal. :p)
The package is missing required files for the test suite. This fixes the
following build error:
```
Building test suite 'regression' for network-2.6.3.1..
[1 of 1] Compiling Main ( tests/Regression.hs,
dist/build/regression/regression-tmp/Main.o )
tests/Regression.hs:12:1: error:
Could not find module ‘Regression.Issue215’
Use -v (or `:set -v` in ghci) to see a list of the files searched
for.
|
12 | import qualified Regression.Issue215 as Issue215
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Previously, cabal-install had a custom Setup.hs which took care of
generating and installing the cabal(1) man page. While this file was a
bit of scary sight, it is certainly nice to have a man page properly
installed. For the 3.2.0.0 release they switched to the default setup
type again, so the man page isn't installed anymore. Fortunately the
cabal cli can generate the man page as well, so the override to add the
man page back is pretty simple.
The commit that introduced this is the following:
91ac075930
I actually made a mental note of this a few weeks ago already, but it
slipped my mind when we updated to cabal-install 3.2.0.0 two weeks ago
unfortunately.
