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.
These were blocked due to mutual desigion during me<>`sternenseemann`
discussion.
https://github.com/haskell-nix/hnix/issues/952
In short:
I shipped my own work (to support GHC 9.0) in the 0.5 releases of
`hnix-store-{core,remote}`.
These packages are really used only by `hnix` itself, and instead of maintaining
them in Nixpkgs & reacting on `hnix` release, we decided to hold them back &
switch to these versions when `hnix` provides support for them.
I just (today) released `hnix` 0.14 & it requires `hnix-store-{core,remote}`
0.5.
If you would look at dependency tree:
https://packdeps.haskellers.com/reverse/hnix-store-corehttps://packdeps.haskellers.com/reverse/hnix-store-remote
It shows that `hnix` currently is the only alive use of these projects.
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.
meta.badPlatforms allows us to exclude specific platforms from the list
of supported platforms without the need to explicitly substract it from
lib.platforms.all (or our inferior equivalent allKnownPlatforms) in
platforms. Thus it'll map nicely to unsupported-platforms in the
hackage2nix configuration in the future.
The tests use pgrep which is not packaged for darwin yet as we are
lacking some private / non open source headers for it to compile.
May be resolvable in the future.
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.
This is a full set rebuild, however it improves the name generation
for the static and cross case since the respective additional
components are now inserted between pname and version instead of after
name like before. This prevents builtins.parseDrvName from mistaking a
platform config string for a version component.
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.
Workaround for https://github.com/NixOS/nixpkgs/issues/82245
Although this doesn't tackle the root cause of a null package sneaking
in (via executableHaskellDepends), it does effectively treat the symptom
by just ignoring any null packages.
Seeing as that issue has been open for more than a year I think this
band-aid is necessary.
stackage has updated to dhall 1.39, so we can update these as well:
haskellPackages.dhall-openapi: 1.0.0 -> 1.0.1
haskellPackages.dhall-nix: 1.1.20 -> 1.1.21
hnix 0.13.* doesn't support hnix-store-* >= 0.5 yet, pending some
refactors to get GHC 9.0.x support working. Until that happens,
we downgrade hnix-store-* since nothing needs the new version yet.
https://github.com/haskell-nix/hnix/issues/952
Linker failure outputs look like they are related to the GClosure stuff,
so lets try disabling that flag on arm — originally the upstream cabal
file disabled that flag by default if arch != x86_64-linux || != sparc64,
so this seems to be actually correct.
Test suite doesn't build with GHC 9.0.1 and since upstream is
currently not invested in fixing it, we (temporarily) disable it.
Upside: we can build hoogle again.
https://github.com/Soostone/retry/issues/71
GHC 9.0.x seems to require that the `Main` module also defines the
`main` IO action and does not just import it. This is the case with
mono-traversable's test suite which is why we (temporarily) disable it.
Stackage Nighly recently upgraded their version of hackage-db from 2.1.0
to 2.1.1. 2.1.1 had a compatibility fix for Cabal 3.4 [1]. However it
did not increase the version bound on Cabal nor fails to compile with
Cabal 3.2, so Stackage was able to update it.
Unfortunately hackage-db with Cabal 3.2 causes observable issues [2]
in cabal2nix, so we need to downgrade it for all compilers that still
ship a Cabal version < 3.4.
Also ideally we should update the constraints for hackage-db 2.1.0 and
hackage-db 2.1.1 on hackage. See also [3].
[1]: https://github.com/peti/hackage-db/pull/12
[2]: https://github.com/NixOS/cabal2nix/issues/501
[3]: https://github.com/peti/hackage-db/pull/14
These attribute names were converted into aliases in the following
changes:
* 62733b37b4
* https://github.com/NixOS/nixpkgs/pull/104776
cabal2nix-unstable has been updated to be aware of these changes in
7a9080d774, so these aliases should no
longer cause issues when evaluating with `allowAliases = false`.
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.
