haskellPackages: stackage LTS 24.12 -> LTS 24.16#452254
haskellPackages: stackage LTS 24.12 -> LTS 24.16#452254sternenseemann merged 73 commits intostaging-nextfrom
Conversation
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.
|
|
I fixed Eval, cherry-picked all the recent compiler stuff from staging and then kicked off hydra. |
|
attoparsec failure is haskell/attoparsec#232, probably succeeds after restarting. |
This should only be used to bootstrap source‐built GHCs.
|
The merge queue being enabled for haskell-updates now discourages direct pushes. Why was it enabled? |
|
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...) |
|
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. |
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.
|
Note: Due to the conflicted state of the PR, the |
|
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. |
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh based on *evaluation [1819781](https://hydra.nixos.org/eval/1819781) of nixpkgs commit [52d502c](https://github.com/NixOS/nixpkgs/commits/52d502c55197c8adce03a73bc01a617f7543c286) as of 2025-11-02 21:08 UTC* from the haskell-updates jobset on hydra under https://hydra.nixos.org/jobset/nixpkgs/haskell-updates
|
FYI, this doesn’t eval on top of -next (and nor did it in CI when you merged). |
|
(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. |
This Merge
This PR is the regular merge of the
haskell-updatesbranch intostaging.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-updatesPRs 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:
haskell-updates(normally at the beginning of a merge window).haskell-updatesintostagingevery two weeks.mergeablejob is succeeding on hydra.maintainedpackage 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.