Skip to content

Comments

haskellPackages: stackage LTS 24.10 -> LTS 24.12#445213

Merged
wolfgangwalther merged 114 commits intostagingfrom
haskell-updates
Oct 15, 2025
Merged

haskellPackages: stackage LTS 24.10 -> LTS 24.12#445213
wolfgangwalther merged 114 commits intostagingfrom
haskell-updates

Conversation

@sternenseemann
Copy link
Member

@sternenseemann sternenseemann commented Sep 22, 2025

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

nixpkgs-ci bot and others added 9 commits September 21, 2025 00:22
@nixpkgs-ci
Merge 7b38f24 into haskell-updates
e7f9748
@sternenseemann
haskellPackages.dunai: drop obsolete workaround
5a2cfde 
The issue has been resolved upstream as reported by krank.
@sternenseemann
haskellPackages.HsSyck: remove obsolete workaround
6592fef 
The issue has been resolved upstream as reported by krank.
@sternenseemann
haskellPackages.lvar: drop obsolete override
014307e 
The issue has been resolved upstream as reported by krank.
@sternenseemann
haskellPackages.glualint: drop obsolete override
aa39e97 
The issue has been resolved in the last two releases, however glualint
is still transitively broken by
<UU-ComputerScience/uuagc#20>.
@sternenseemann
haskellPackages.aeson-schema: drop obsolete override
e03351f 
aeson-schema has been marked broken due to unrelated issues:
ocramz/aeson-schema#26
@nixpkgs-ci
Merge 6d7dc31 into haskell-updates
9dd4e71
@sternenseemann
haskell.compiler: remove references xattr missing flag issues
ce72c74 
darwin.xattr used to be a fork of python3.pkgs.xattr.
bafc6ff switched darwin.xattr to Apple's new
C implementation of the tool.

When I originally packaged darwin.xattr (283d622),
I linked tickets on the original tool's issue tracker suggesting to
add support for flags added by Apple in their fork. This has since
happened, so we could possibly switch to python3.pkgs.xattr.

However, I think it's no longer a good idea:

- Bootstrapping-wise a C tool is considerably simpler.
- GHC upstream tests against Apple's xattr(1) implementation in their
  CI. Especially now, since they no longer share a direct ancestry,
  it seems unwise to assume the tools will behave the same.
@sternenseemann
haskellPackages: stackage LTS 24.10 -> LTS 24.11
98830a9 
all-cabal-hashes: 2025-09-14T21:34:10Z -> 2025-09-21T18:48:01Z

(generated by maintainers/scripts/haskell/update-package-set.sh)
@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 Sep 22, 2025
@nixpkgs-ci nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Sep 22, 2025
@mpscholten
Copy link
Contributor

mpscholten commented Sep 22, 2025

When building the network package on macOS I always run into the following error:

2025-09-21T22:50:13.5432710Z network> Failures:
2025-09-21T22:50:13.5434300Z network> 
2025-09-21T22:50:13.5436440Z network>   Network/Socket/Types.hsc:1162:33:
2025-09-21T22:50:13.5436950Z network>   1) Network.Socket.bind successfully binds to a unix socket
2025-09-21T22:50:13.5440500Z network>        uncaught exception: ErrorCall
2025-09-21T22:50:13.5442330Z network>        pokeSockAddr: path is too long in SockAddrUnix "/nix/var/nix/builds/nix-build-network-3.2.8.0.drv-26832-1945523993/haskell-network-3bc0b3ce28dae698/socket-file", length 111, unixPathMax 104
2025-09-21T22:50:13.5445280Z network>        CallStack (from HasCallStack):
2025-09-21T22:50:13.5446450Z network>          error, called at Network/Socket/Types.hsc:1162:33 in network-3.2.8.0-3utn7siwrX632M5MyK6IUr:Network.Socket.Types
2025-09-21T22:50:13.5447490Z network> 
2025-09-21T22:50:13.5448280Z network>   To rerun use: --match "/Network.Socket/bind/successfully binds to a unix socket/" --seed 233786430
2025-09-21T22:50:13.5449180Z network>

Is there a "secret" nix attribute/flag to patch the network package such that the unix socket path is shorter? Or would it make sense to disable tests on macOS?

@sternenseemann
haskell.compiler.ghc902Binary: let krank ignore informational issue ref
344c3ca
@sternenseemann
haskell.packages.ghc902Binary.reflection: make krank ignore closed is…
a11b0c4 
…sues

This workaround is for a GHC bug that has never gotten addressed in GHC 9.0.*.
@sternenseemann
haskell.packages.ghc902Binary.retry: drop obsolete override
22d7eee 
The issues has been resolved in >= 0.9. Note that it's not possible to
test this at the moment since retry (indirectly) depends on
TemplateHaskell which doesn't work with our bindists.
@sternenseemann
haskell.packages.ghc902Binary.inline-c-cpp: remove broken/obsolete ov…
ffd683a 
…erride

This depends on a GHC patch which the only remaining GHC 9.0.*,
ghc902Binary, doesn't have, being a bindist and all.
@sternenseemann

This comment was marked as outdated.

Sign in to view
@sternenseemann

This comment was marked as duplicate.

Sign in to view
@rvl @sternenseemann
haskellPackages.gi-gtk-hs: use gi-gtk3 and gi-gdk3 to fix build
8d1ec1d 
Upstream change that makes this change hasn't been released yet.

Co-authored-by: sternenseemann <sternenseemann@systemli.org>
@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 13, 2025

@wolfgangwalther I raised this in the Infrastructure room a while ago. There was a certain point at which this started happening, failures are flaky and usually disappear on restart. I think @nh2 looked into the text file busy issue at some point, but didn't really come to a conclusion nor did I. I also haven't been able to reproduce it.

@wolfgangwalther
Copy link
Contributor

wolfgangwalther commented Oct 14, 2025

So HLS for GHC 9.6.7 and 9.8.4 is still failing on hydra, even after multiple restarts. This time with a GHC error in haskell-language-server directly:

I can build both of them just fine locally, though.

No idea what's going on.

@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 14, 2025

Should rule out corrupted store paths on Hydra, then.

@wolfgangwalther
Copy link
Contributor

wolfgangwalther commented Oct 14, 2025

Should rule out corrupted store paths on Hydra, then.

How would I do that?

sternenseemann and others added 2 commits October 15, 2025 09:09
@sternenseemann
haskellPackages.gi-gtk-hs: Fix build (#451363)
dae2ecd
@wolfgangwalther
haskellPackages: mark builds failing on hydra as broken
e915fbe 
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh based on
*evaluation [1819351](https://hydra.nixos.org/eval/1819351) of nixpkgs commit [e1a3a9d](https://github.com/NixOS/nixpkgs/commits/e1a3a9d50a9412a716451506b981ed5c4544b035) as of 2025-10-15 09:00 UTC*
from the haskell-updates jobset on hydra under https://hydra.nixos.org/jobset/nixpkgs/haskell-updates
@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 15, 2025

How would I do that?

Not so easy because GHC is nondeterministic. I've tried building HLS after a garbage collect which does seem to work for 9.6.

@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 15, 2025

@alexfmpe https://hydra.nixos.org/build/310117246/nixlog/1

@wolfgangwalther
Copy link
Contributor

wolfgangwalther commented Oct 15, 2025

I have now marked packages as broken.

The following two packages fail to build, but I didn't mark them as broken, because we didn't ping maintainers in time:

@alexfmpe @thoughtpolice you'll want to look into fixing your packages on staging.

For the two HLS builds for 9.6.7 and 9.8.4: I am hoping they will build fine on staging-next, when everything is rebuild anyway. If not, we need to look into that later.

Packages marked as broken

@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 15, 2025

We have multiple versions of ghc-exactprint in the dependency closure, though it is a mystery why it consistently works on our machines, but seemingly consistently doesn't on the Hydra builders.

Warning:
    This package indirectly depends on multiple versions of the same package. This is very likely to cause a compile failure.
      package haskell-language-server (haskell-language-server-2.11.0.0) requires ghc-exactprint-1.7.1.0-6x0Lt0OUX1n4DylHihsRdz
      package haskell-language-server (haskell-language-server-2.11.0.0) requires ghc-exactprint-1.7.1.0-6x0Lt0OUX1n4DylHihsRdz
      package haskell-language-server (haskell-language-server-2.11.0.0) requires ghc-exactprint-1.7.1.0-6x0Lt0OUX1n4DylHihsRdz
      package apply-refact (apply-refact-0.15.0.0-BLnycfa0wUu2RI1jkHhjpb) requires ghc-exactprint-1.7.1.0-6x0Lt0OUX1n4DylHihsRdz
      package retrie (retrie-1.2.3-EQ0AT5mQjO4ASN8zJrxz5Z) requires ghc-exactprint-1.7.1.0-kVpEFy1LJ04yZ61cXBTsb

@sternenseemann
Copy link
Member Author

sternenseemann commented Oct 15, 2025

tamarin-prover has been broken for a while and on master already, due to tamarin-prover/tamarin-prover#774.

@wolfgangwalther
Copy link
Contributor

wolfgangwalther commented Oct 15, 2025 •
edited
Loading

We have multiple versions of ghc-exactprint in the dependency closure, though it is a mystery why it consistently works on our machines, but seemingly consistently doesn't on the Hydra builders.

Ah nice find. Should we try to fix this before merging?

Edit: #452213

@wolfgangwalther
haskell.packages.{ghc94,ghc96,ghc98}.haskell-language-server: disallo…
4b3b8a1 
…w inconsistent dependencies

The diff is bigger than it needs to be, because I felt the urge to sort
things as well.

Key changes:
- For GHC 9.8, fix `super` -> `lself` for `extensions`.
- Add the `hls_overlay` to `apply-refact` as well.
- Remove `allowInconsistentDependencies`.
@wolfgangwalther
haskell.packages.{ghc94,ghc96,ghc98}.haskell-language-server: disallo…
44f5c58 
…w inconsistent dependencies (#452213)
@wolfgangwalther wolfgangwalther marked this pull request as ready for review October 15, 2025 11:49
@wolfgangwalther wolfgangwalther merged commit 33735c2 into staging Oct 15, 2025
36 checks passed
@wolfgangwalther wolfgangwalther mentioned this pull request Oct 15, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@wolfgangwalther wolfgangwalther Awaiting requested review from wolfgangwalther

@maralorn maralorn Awaiting requested review from maralorn

Assignees

No one assigned

Labels

2.status: merge conflict This PR has merge conflicts with the target branch 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

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@sternenseemann @mpscholten @maralorn @nixos-discourse @wolfgangwalther @raehik @alexfmpe @emilazy @rvl