- git-annex now supports either filepath-bytestring or filepath (>=
1.5.2) with the new OsPath API. For GHC 9.8, we have too stick to
filepath-bytestring and manually disable the OsPath flag. However,
we can already support building git-annex with GHC 9.10 and implement
our overrides in a future proof way.
Due to code changes relating to OsPath, our patch has to be rebased.
- The Utility.* modules gain a few dependencies, but for modules that
aren't used in Setup.hs. Consequently, our approach of reusing the
setup package db in GHC for the installer tool managed by the
git-annex Makefile is no longer enough.
Upstream has addressed the issue we've been trying to work
around (darwin support). The upstream change is different and (iirc)
more correct. We'll have to wait and see if any new issues crop up.
- crypton is maintained, contrary to cryptonite
- since the Hackage scrypt package uses SSE2, we can't build it on
non-x86 platforms (non x86_64 even probably). The best option
is to disable the Scrypt module. To prevent cabal from pulling
in scrypt in spite of that, we need to patch build-depends to
respect the flag.
These packages have been broken since before the 24.05 release. There
is a pull request open to update them to a newer OpenCV and get them
working again: <https://github.com/LumiGuide/haskell-opencv/pull/157>.
(cherry picked from commit 79872e0539)
- Drop patch which was a backport of a now released upstream change.
- Drop scope overrides where upstream constraints are compatible with LTS-20.
haskellPackages.cabal-install-parsers_0_4_5: remove at 0.4.5
No longer necessary for haskell-ci which is why we had it.
Upstream XMonad was using our xmonad patch file for their flake build to
support our nixos module. This would of course break the build upstream
if the version we patched and their master branch diverged. We
[discussed] that it'd make sense to upstream the environment var code.
In the process it seemed sensible to rename the NIX_GHC variable as
well, since it isn't really Nix-specific – it's just a way to set the
GHC binary to execute. This change has been [implemented] upstream in an
unreleased version of xmonad now – meaning we'll be able to drop the
xmonad patch soon!
This also clarifies the situation in nixpkgs a bit: NIX_GHC is easy to
confuse with the environment variable used in the ghcWithPackages
wrapper where it is used to set an alternative prefix for a GHC-wrapper
for applications trying to discover it via e.g. ghc-paths. It is an
implementation detail in this context, as it is in the case of the
xmonad module. Since they are different implementations doing different
things, different names also make sense.
[discussed]: 36d5761b3e
[implemented]: 23f36d7e23
