Latest 9.6.x minor release is 9.6.7, which is also in Stackage 22.44.
Thus, dropping according to the GHC Deprecation Policy.
This requires to change the bootstrap for GHC 9.8.x and GHC 9.10.x on
some platforms.
These dependencies need to be pulled from the same unstable commit that
cabal2nix is pulled from, otherwise changes to any of them will not be
in effect and possibly break the build.
(cherry picked from commit 631661e66c)
The contribution guidelines require an unstable version to be leading
with a real version, or if none is available with `0-`.
This is because certain Nix operations split a package's full name into
name and version component starting with the first section starting with
a digit.
(cherry picked from commit 453d0f8eab)
Our wrapper for lib.makeOverridable wraps the underlying function which
means the wrapper function doesn't replicate the same set pattern.
We can, however, tell lib.functionArgs about the permissible arguments
by making the function a functor and adding __functionArgs.
- Cabal prefers picking the newest available version of a package when
configuring, so we need to explicitly pass --constraint since Cabal
>= 3.12 is in bounds for the packages we want to use the older
version for.
- stack's source files from the sdist have DOS line endings for some
reason, so we need to a) convert the patch to DOS line endings and
b) prevent patch(1) from implicitly converting the patch to unix
line endings.
Alternative solution would be to build stack with GHC 9.8 which still has
Cabal == 3.10.*.
all-cabal-hashes: 2025-09-11T15:33:02Z -> 2025-09-14T21:34:10Z
(generated by maintainers/scripts/haskell/update-package-set.sh)
haskell.packages.ghc9{6,8}.ghc-lib-parser: 9.10.2.* -> 9.10.3.*
ghc-lib-parser-ex doesn't have a new upload (yet?). ghc-lib == 9.10.* is
currently unused, but will presumably be required for HLS.
Bump the LLVM version used by our GHC packages in preparation for
the LLVM drops. This breaks the LLVM backend; it will be fixed soon
by backporting patches, but that will require a mass rebuild.
Needs nix-instantiate(1) to compare evaluation against upstream Nix, though some
tests are not possible to run without a Nix daemon and will fail while trying to connect
to the daemon socket.
These are the only versions of these packages that are compatible with
hnix 0.17.0, pending https://github.com/haskell-nix/hnix/pull/1112.
Since hnix has more reverse dependencies, it is easier to make its
requirements the default. Since Stackage LTS no longer tracks hnix-store-*,
the overridding situation is less hairy than it used to.
All hnix-store-* packages except hnix-store-core and hnix-store-remote
have been introduced after hnix-store-core >= 0.8 and need to be overridden
to use that.
This partially reverts commit 330ee35adb.
It looks the package expression was not correctly merged in 6047f7d6d6:
While the version number was updated, the actual update of the source
URL from fab98a0dca was reverted.
Fixed by running the update script.
- The LLVM backend always needs an LLVM specific assembler, i.e. clang
that ideally matches the version of LLVM actually used for codegen.
- The LLVM backend on Darwin requires some version of clang to be
available. In light of LLVMAS, using a matching version seems to be
best though this does risk messing with clang used for compiling C
in the derivation.
This mess can be avoided by compiling GHC with useLLVM = true which
sets absolute paths in GHC's settings file. Due to closure size
constraints, we can't really do that if NCG is available.
There’s no sensible notion of a Haskell package set’s LLVM, only a
GHC’s LLVM. `haskellPackages.ghc.llvmPackages` is still accessible,
although you probably don’t actually want to use it very often.
Co-authored-by: sternenseemann <sternenseemann@systemli.org>
