Skip to content

haskellPackages: stackage LTS 24.12 -> LTS 24.16#452254

Merged
sternenseemann merged 73 commits intostaging-nextfrom
haskell-updates
Nov 2, 2025
Merged

haskellPackages: stackage LTS 24.12 -> LTS 24.16#452254
sternenseemann merged 73 commits intostaging-nextfrom
haskell-updates

Conversation

@wolfgangwalther
Copy link
Contributor

This Merge

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

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 staging 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 #445213. Come to #haskell:nixos.org if you have any questions.

wolfgangwalther and others added 9 commits October 15, 2025 15:05
all-cabal-hashes: 2025-09-25T14:09:07Z -> 2025-10-15T11:31:05Z

(generated by maintainers/scripts/haskell/update-package-set.sh)
- add patch from fedora (rebase of latest fix from upstream):
https://gitlab.haskell.org/ghc/ghc/-/issues/25662
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13863

ghc versions excluded from patch:
9.10.2 - has previous fix with `extern void* malloc(size_t);`
9.10.3 - has latest fix with `#include <stdlib.h>`
9.12.3 - has latest fix with `#include <stdlib.h>`

Fixes build failure with gcc15, building utils/hp2ps/Utilities.c:
```
utils/hp2ps/Utilities.c:6:14: error:
warning: conflicting types for built-in function ‘malloc’;
expected ‘void *(long unsigned int)’ [-Wbuiltin-declaration-mismatch]
        6 | extern void* malloc();
          |              ^~~~~~
...
utils/hp2ps/Utilities.c:92:18: error:
warning: conflicting types for built-in function ‘realloc’;
expected ‘void *(void *, long unsigned int)’ [-Wbuiltin-declaration-mismatch]
       92 |     extern void *realloc();
          |                  ^~~~~~~
```

(cherry picked from commit 02746ea)
Hadrian is only used for GHC 9.6+ anyway.

(cherry picked from commit 14488d4)
Latest 9.10.x minor release is 9.10.2, which is also in Stackage 24.8.

Thus, dropping according to the GHC Deprecation Policy.

(cherry picked from commit ac5228c)
This bootstraps mostly from ghc984Binary, at least for the major
platforms. The bootstrap paths for darwin become much shorter.
Unfortunately, the bootstrap paths for i686-linux become a bit longer,
so it's a trade-off.

(cherry picked from commit 5df6c9a)
We’d want every version to be able to trace back to 9.4.8 for the
“cross‐compiled GHC bootstrap tarballs” plan, anyway. I’m not
sure whether we’d want a `ghc948Binary` package that also includes
the official tarballs, or just only use our cross‐compiled binary
distributions, but it will make sense to align the version used for
bootstrap regardless.

(cherry picked from commit da915f8)
(cherry picked from commit c9c7344)
ghc902Binary's rts.conf indeed prescribes linking against numa for
aarch64-linux, but this is not the case with the later bindists we have
been providing numa for.

(cherry picked from commit 347062b)
Latest 9.12.x minor release is 9.12.2, which is also in Stackage Nightly
2025-09-01.

Thus, dropping according to the GHC Deprecation Policy.
@maralorn
Copy link
Member

  • This PR should contain the bump to hls 2.12, which will probably need fixing.

@wolfgangwalther
Copy link
Contributor Author

I fixed Eval, cherry-picked all the recent compiler stuff from staging and then kicked off hydra.

@nixpkgs-ci nixpkgs-ci bot added 10.rebuild-linux: 501+ This PR causes many rebuilds on Linux and should normally target the staging branches. 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must target the staging branches. 10.rebuild-linux: 5001+ This PR causes many rebuilds on Linux and must target the staging branches. 6.topic: haskell General-purpose, statically typed, purely functional programming language 4.workflow: package set update Development branch for package set updates (haskell/python) labels Oct 15, 2025
@sternenseemann
Copy link
Member

attoparsec failure is haskell/attoparsec#232, probably succeeds after restarting.

@nixpkgs-ci nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Oct 16, 2025
@sternenseemann
Copy link
Member

The merge queue being enabled for haskell-updates now discourages direct pushes. Why was it enabled?

@wolfgangwalther
Copy link
Contributor Author

wolfgangwalther commented Oct 16, 2025

It was enabled for all staging-esque branches, because it's the only way to make sure that things you merge are actually correct, when merged (linting, formatting, eval, etc.). A PR-based check can always introduce regressions when merging multiple PRs with interactions.

For now, we can still push simple fixes directly. This will not change anytime soon. For that to change, we'd first need to implement all periodic merges as PR, as discussed in #424345.

(Edit: And changing this would also require figuring out a replacement for the merge-base/staging stuff, because that requires the ability to push directly into staging as well...)

@maralorn
Copy link
Member

The number of File not found errors in Setup.hs is quite annoying at this point.

State for HLS: 9.4 needs the deprecation warning. 9.6 (possibly also 9.8) are broken because missing markdown-unlit (no clue yet what that’s about). I hopefully can look into that on the weekand.

sternenseemann and others added 6 commits October 31, 2025 17:31
Using build-tools is somewhat flawed since it relies on the host tools
being executable at build time which is not always the case, e.g. when
cross-compiling. The simplest solution (patching being the alternative)
is to simply use the flag that makes nix-paths use PATH at runtime.
@wolfgangwalther
Copy link
Contributor Author

Note: Due to the conflicted state of the PR, the PR / Eval / compare (pull_request_target) PR / Eval / compare will not go away until.. I don't even know. I guess once the PR becomes unconflicted, in GitHub terms.

@maralorn
Copy link
Member

maralorn commented Nov 2, 2025

Re: markdown-unlit in hls (9.6 + 9.8¥. This is because of a new tutorial executable that we we have no business building. I just need to figure out how to disable building it.

@sternenseemann sternenseemann changed the base branch from staging to staging-next November 2, 2025 22:25
@sternenseemann sternenseemann marked this pull request as ready for review November 2, 2025 22:25
@nixpkgs-ci nixpkgs-ci bot closed this Nov 2, 2025
@nixpkgs-ci nixpkgs-ci bot reopened this Nov 2, 2025
@sternenseemann sternenseemann merged commit 866c9d0 into staging-next Nov 2, 2025
34 of 45 checks passed
@nixpkgs-ci nixpkgs-ci bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Nov 2, 2025
@winterqt
Copy link
Member

winterqt commented Nov 3, 2025

FYI, this doesn’t eval on top of -next (and nor did it in CI when you merged).

@winterqt
Copy link
Member

winterqt commented Nov 3, 2025

(Please don’t bypass the merge queue in the future, it’s there for a reason!)

@wolfgangwalther
Copy link
Contributor Author

wolfgangwalther commented Nov 3, 2025

(Please don’t bypass the merge queue in the future, it’s there for a reason!)

Unfortuantely, because of how things are set up, it's essentially impossible to merge haskell-updates with the merge queue, because GitHub always shows conflicts.

(that being said, it is possible to run eval locally after creating the merge commit)

I will need to wake up first and then look into the Eval failure soon-ish.

Edit: I see this was already fixed last night.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

4.workflow: package set update Development branch for package set updates (haskell/python) 6.topic: haskell General-purpose, statically typed, purely functional programming language 10.rebuild-darwin: 501+ This PR causes many rebuilds on Darwin and should normally target the staging branches. 10.rebuild-darwin: 5001+ This PR causes many rebuilds on Darwin and must 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: 5001+ This PR causes many rebuilds on Linux and must target the staging branches.

Projects

None yet

Development

Successfully merging this pull request may close these issues.