Skip to content

haskellPackages: update hackage and stackage#278674

Merged
sternenseemann merged 50 commits intomasterfrom
haskell-updates
Jan 7, 2024
Merged

haskellPackages: update hackage and stackage#278674
sternenseemann merged 50 commits intomasterfrom
haskell-updates

Conversation

@sternenseemann
Copy link
Member

This Merge

This PR is the regular merge of the haskell-updates branch into master.

This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates. You may be able to find an up-to-date Hydra build report at cdepillabout/nix-haskell-updates-status.

We roughly aim to merge these haskell-updates PRs at least once every two weeks. See the @NixOS/haskell team calendar for who is currently in charge of this branch.

haskellPackages Workflow Summary

Our workflow is currently described in pkgs/development/haskell-modules/HACKING.md.

The short version is this:

  • We regularly update the Stackage and Hackage pins on haskell-updates (normally at the beginning of a merge window).
  • The community fixes builds of Haskell packages on that branch.
  • We aim at at least one merge of haskell-updates into master every two weeks.
  • We only do the merge if the mergeable job is succeeding on hydra.
  • If a maintained package is still broken at the time of merge, we will only merge if the maintainer has been pinged 7 days in advance. (If you care about a Haskell package, become a maintainer!)

More information about Haskell packages in nixpkgs can be found in the nixpkgs manual.


This is the follow-up to #272097. Come to #haskell:nixos.org if you have any questions.

maralorn and others added 9 commits January 2, 2024 02:28
This commit has been generated by maintainers/scripts/haskell/update-stackage.sh
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
… version

In #278074 I removed `exception`
completely. But `nixpkgs` has a version of `exceptions we could use.
Let's enable that instead.

Co-authored-by: Dennis Gosnell <[email protected]>
…xceptions-restore

haskell.packages.ghc865Binary.exceptions: restore package, use 0.10.7…
Before the change an attempt to instantiate `stm` package failed as:

    $ nix build --no-link -f. haskell.packages.ghcjs.stm
    error:
       … in the left operand of the update (//) operator

         at /home/slyfox/dev/git/nixpkgs-haskell-updates/pkgs/development/haskell-modules/lib/compose.nix:40:7:

           39|     mkDerivation = drv: (args.mkDerivation drv).override f;
           40|   })) // {
             |       ^
           41|     overrideScope = scope: overrideCabal f (drv.overrideScope scope);

       error: attribute 'stm_2_5_1_0' missing

       at /home/slyfox/dev/git/nixpkgs-haskell-updates/pkgs/development/haskell-modules/configuration-ghcjs.nix:29:21:

           28|   # ghcjs/ghcjs#676
           29|   stm = doJailbreak self.stm_2_5_1_0;
             |                     ^
           30|   exceptions = dontCheck self.exceptions_0_10_7;
       Did you mean stm_2_5_3_0?
Files like `pkgs/development/haskell-modules/configuration-ghc-8.10.x.nix`
assume `ghc` always has an `llvmPackages` attribue. Let's expose `null`
value from `ghcjs` to allow it's propagation.

This fixes package evaluation for `ghcjs` packages.
We're opting for the strategy of providing the most up to date version
llvm-ffi supports which works out well enough, as nixpkgs also tries to
be quite up to date with its LLVM version (and also uses LLVM 16 as the
default).
@github-actions github-actions bot added the 6.topic: haskell General-purpose, statically typed, purely functional programming language label Jan 4, 2024
We need this attribute to work for cross compilation. Unfortunately the
updated bounds are not yet released to Hackage.
@sternenseemann sternenseemann changed the title haskellPackages: update stackage and hackage; Stackage LTS 21.23 -> 22.4 haskellPackages: update stackage and hackage Jan 4, 2024
This reverts commit 2e7f09c.

Reason for revert: Due to all-cabal-hashes not updating, we can't at the
moment get a more up to date hackage database the normal way. Let's
revert to the old state, so we can keep working on what we have until a
more up to date snapshot is available.
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
@ofborg ofborg bot added 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 1-10 This PR causes between 1 and 10 packages to rebuild on Darwin. 10.rebuild-darwin: 1 This PR causes 1 package to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Jan 4, 2024
See NixOS/cabal2nix#611 for discussion.

While we're changing things, let's also use the tzdata setupHook for
haskellPackages.tz.
@sternenseemann sternenseemann changed the title haskellPackages: update stackage and hackage haskellPackages: update hackage Jan 4, 2024
sternenseemann and others added 7 commits January 4, 2024 16:57
pandoc: install man pages from pandoc-cli tarball

The pandoc man pages moved from pandoc to pandoc-cli, so we need to
install them elsewhere. The install script for this was emitted by
cabal2nix which we now stop doing for pandoc >= 3.1.10 (so
haskellPackages.pandoc still has man pages). Instead we manually add an
override where it matters to us, namely
pkgs.pandoc (haskellPackages.pandoc-cli is lacking them now, not sure if
we need to care).
dhall suddenly appeared in Stackage LTS 21 at 1.41.* which we don't
necessarily want, as we were using 1.42.* before. It is much easier to
revert this downgrade due to other packages (not in Stackage LTS) we are
shipping, like dhall-nix, dhall-nixpkgs and hnix.
For GHC 9.6 and 9.8 we can use the Cabal library bundled with GHC since
it matches the requested version. This can prevent inconsistent
dependencies later in e.g. haskell-language-server.

For lower versions we may need to jailbreak and downgrade Cabal to which
upstream seems to be open:

> We need to pin a single major version of Cabal here because the main
> reason we use Cabal is for its list of extensions. Later versions have
> strictly more extensions, and we'll have missing patterns if we try to
> support more than one major version. If this causes problems in
> practice let's revisit this decision and come up with another
> approach.

Alternatively, hls-stan-plugin can be disabled.
hls-stan-plugin is not buildable with GHC >= 9.2.4 && < 9.4, so we have
no GHC from the 9.2 series that would support this plugin.
@sternenseemann
Copy link
Member Author

@ncfavier
Copy link
Member

ncfavier commented Jan 6, 2024

Thanks for the heads up.

ncfavier and others added 19 commits January 6, 2024 17:02
The `mueval-core` executable was removed for some reason, so use
`mueval` instead.
All versions have this patch that conditionally enables support for
template-haskell >= 2.16, so we can fold them into one.
Support for GHC 9.0 was dropped in this version, so we can no longer
ship it.
haskellPackages.ircbot, haskellPackages.bytestring-conversion: unbreak
haskellPackages.double-conversion: don't use vendored library
Clean up override for removed version.
Sorry, this is a bit of a draw the rest of the owl commit. Upgraded
where sensible/possible, all jailbreaks note the bounds issues which are
luckily relatively boring (base and friends).

Removed overrides are mostly stale overrides from configuration-head.nix
that don't work anymore and make little sense with the current package
set anyways.
These packages are too tightly coupled to GHC/Cabal
Unfortunately we have a disagreement between Stackage LTS and what
pandoc needs for typst-symbols.
The GHC 9.0 package set uses ghc-lib 9.4.*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6.topic: haskell General-purpose, statically typed, purely functional programming language 8.has: clean-up This PR removes packages or removes other cruft 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 2501-5000 This PR causes many rebuilds on Darwin and should target the staging branches. 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-linux: 2501-5000 This PR causes many rebuilds on Linux and should target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants