haskellPackages: update hackage #339272
Open
haskellPackages: update hackage #339272
+2,322
−726
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh and maintainers/scripts/haskell/regenerate-hackage-packages.sh.
fixed auto-update, http2, network-control, network-run and time-manager by choosing different version. fixed dejafu and tasty-coverage by jailbreaking. fixed bsb-http-chunked, hinotify and warp by disabling test suite.
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
Builds without problem
|
One thing I noticed with one of the new packages |
|
@collinarnett are you sure this is not fixable by using |
|
I just tried it with In the repo's flake they explicitly override base64 to version 1.0 as well here. https://github.com/Gabriella439/tiktoken/blob/2e66d1e29acf66f08959f86080d53b07bccb5ae4/flake.nix#L18C1-L22C23 |
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
|
Thank you. If you want you can open a PR which does this override in |
This is easy in comparison since these tools won't end up in GHC's settings nor need to be available at runtime, so we can use the *_FOR_BUILD environment variables. It is important to add buildCC to depsBuildBuild to engage the stdenv/wrapper script machinery properly. Co-authored-by: sternenseemann <[email protected]>
1. Explicitly set WITH_TERMINFO. We usually match GHC's behavior well, but it is better to tie the Nix option to make explicitly. Unfortunately, the same is very complicated to achieve with hadrian (iirc). 2. Disable enableTerminfo if we are cross-compiling. This matches the behavior of GHC's build system, so we'll have to match it now. It also reduces the ncurses-related headache a bit. 3. Stop passing --with-curses* flags. Unfortunately, GHC does not account for the fact that different platforms need different ncurses libraries. This is somewhat migitated by the fact that ncurses is only ever needed for the build platform if we are cross compiling, but I seem to remember it leaking into the final GHC somehow. A more reliable alternative is relying on the cc/ld wrapper scripts, as they'll always pull out the correct ncurses out of the environment when GHC's build system passes -lcurses. 4. Unconditionally add ncurses to depsBuildBuild. Stage0 unconditionally builds terminfo (maybe the stage1 compiler needs it?), so we need to make sure that ncurses for the build platform is available. Co-authored-by: sternenseemann <[email protected]>
This was referenced Sep 18, 2024
We reuse the targetLibs logic for this since it is more or less the same story. However, the terminfo library is only built when GHC is neither a cross-compiler nor being cross-compiled. Therefore ncurses (if used) will only ever come from pkgsHostTarget. In the other cases ncurses is still passed via depsBuildBuild for the stage1 compiler. This commit tries to resolve the problem that the package-db doesn't include library and include dirs of ncurses for the terminfo package, causing library loading and linking problems in downstream packages, e.g. dhall-docs and dhall-toml. This problem was introduced in 4b00fbf. With this in mind, not passing --with-curses-* – as long as the terminfo package isn't built – seems fine.
That's a bit cleaner and more robust in case this will be backported to 9.6.7 (should it happen).
|
FTR this is the failure: This doesn't seem to have worked in the last weeks at all which makes me think this could be related to the downgrade of libffi from 3.4 -> 3.3 for GHC 8.10.7. Will need to try and confirm that. |
25 tasks
sternenseemann
added a commit
to AlexandreTunstall/nixpkgs
that referenced
this pull request
Sep 19, 2024
In NixOS#339272, an elusive regression was found where the stage 2 binaries held a reference to the boot compiler in their rpath. This issue only affected GHC 9.6 versions built on aarch64-linux. For still unknown reason, this issue goes away when using a source built GHC instead of the binary GHC we derive from upstream's bindists. Knowing more would be great, obviously, but at least this issue goes away with GHC 9.8.*… Co-authored-by: sternenseemann <[email protected]>
In #339272, an elusive regression was found where the stage 2 binaries held a reference to the boot compiler in their rpath. This issue only affected GHC 9.6 versions built on aarch64-linux. For still unknown reason, this issue goes away when using a source built GHC instead of the binary GHC we derive from upstream's bindists. Knowing more would be great, obviously, but at least this issue goes away with GHC 9.8.*… Co-authored-by: sternenseemann <[email protected]>
This is a safeguard against a problem we had with 9.6. Unfortunately, since the cc wrapper emits `-L` and `-rpath` flags based on platform config (e.g. aarch64-unknown-linux), not platform role (e.g. build), stdenv itself doesn't prevent ghc from being linked against the boot compiler when building a native or cross-compiling GHC (since host == build). With disallowedReferences, the build will fail if such a problem is re-introduced.
perl is only needed in some situations as a build time dependency to run build scripts. The final GHC doesn't require perl.
The stage0 ghc is build->build since it builds the stage1 compiler which has build for its host platform (i.e. is build->target relative to the entire GHC derivation). Also annotate a bit more around the use of pkgsBuildBuild and the boot compiler and make it more explicit where it comes from in the derivation.
1 task
|
GHC 8.10.7 on aarch64-linux has a similar issue to GHC 9.6 used to have: It retains a reference on the stage0 compiler. |
This was introduced in 879556b and 33c0dd6. See: 33c0dd6#r146876310.
|
9.10.1 failures we see sometimes are due to: https://gitlab.haskell.org/ghc/ghc/-/issues/25153 |
The GHC bug isn't fixed, but there has been a workaround added to haskell-gi 0.26.10 to avoid triggering the problem. 1. https://gitlab.haskell.org/ghc/ghc/-/issues/23392 2. https://hackage.haskell.org/package/haskell-gi-0.26.10/changelog
Some GHC bindists have a normal `$out/lib` directory which contains symlinks to all core libs. Because it is a normal lib directory, the bintools setup hook will pick up on it and cause ld to pass the appropriate -L and -rpath flags. We do not want this to happen, especially in the case of the stage2 compiler. Not only will the final ghc have an unnecessary reference (and thus increased closure size) to the binary ghc, but the extra libraries in the rpath mess with the rts and cause e.g. segfaults in GHCi. Unfortunately, there is no way to prevent this. It is a fundamental flaw in the cc and bintools wrappers that they do not actually distinguish between the roles of dependencies (build, host, target). Instead the mangleVar* function will translate the dependencies split up by roles into platforms. This means that the wrappers can't distinguish between depsBuildBuild and depsHostTarget (== buildInputs) when natively compiling. As long as we are natively compiling the wrappers will put the stage0 ghc (be it in depsBuildBuild, nativeBuildInputs etc.) into the linker flags of the final ghc. The solution is to sidestep the issue. We just had ghc in depsBuildBuild to have it added to PATH. GHC itself will pass the appropriate linker flags if necessary. To avoid the setup hooks picking up on the GHC libraries we just don't put it into depsBuildBuild or any other dependency list. Since the GHC build system accepts the GHC binary via an absolute path, we don't even need to add the stage0 GHC to PATH.
This seems to be a build time only dependency as there is no corresponding settings entry.
Ideally we don't want to use bintools.bintools and also not really encode knowledge of what is wrapped and what not in our GHC derivation. Unfortunately, not all tools are part of the wrapper derivation as well. This should be gradually improved (e.g. in the case of the darwin tools and strip).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This Merge
This PR is the regular merge of the
haskell-updatesbranch intomaster.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-updatesintomasterevery 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 #335932. Come to #haskell:nixos.org if you have any questions.
No new version of stackage at this time (2024-09-03)!