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.
We don't need to pin the package version from hackage anywhere anymore
since stackage-nightly has arrived at the version we want. The
tasty-discover override is still necessary, but can be applied to the
plain hnix-store-core attribute.
Since the hnix-store-core_0_4_1_0 attribute no longer exists a few
intermittent eval errors where caused by the package set regeneration.
We need to fix two compilation errors caused by breaking changes in
dependencies of idris 1.3.3:
* haskeline >= 0.8
* megaparsec >= 0.9
For both there is a patch on idris master which we can just apply. Both
can presumably removed as soon as the next release of idris 1 hits.
Co-authored-by: Jake Gillberg <jake.gillberg@protonmail.com>
While the dependencies are being released for hls 0.10.0 they break
compatibility with hls 0.9.0 and therefor all need manual intervention
when they get released until hls 0.10.0 get’s released.
co-log fails to compile due to its dependency on chronos, which fails to
compile because the doctests fail with newer GHC versions. So we just
disable the doctests and thus unbreak both.
https://github.com/andrewthad/chronos/issues/62
dhall-json has a dependency on tasty-silver and this in turn only
compiles if we supply a newer version of tasty. We can get around this
issue until stackage has caught up to tasty 1.4 by skipping tests
