-
-
Notifications
You must be signed in to change notification settings - Fork 13.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
haskell: update package set #122719
haskell: update package set #122719
Conversation
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
This commit has been generated by maintainers/scripts/haskell/update-hackage.sh
This commit has been generated by maintainers/scripts/haskell/regenerate-hackage-packages.sh
versions in stackage is too old to support 0.19.5, so we pin futhark to a version that does.
New release 0.13.0.1 introduced support with ref-tf >= 0.5, so we can remove our patch for that purpose.
haskell-nix/hnix#922 removed a few build-depends from hnix.cabal which are still required until the following constraints apply to stackage: * relude >= 1.0.0.0 * semialign >= 1.2 Luckily, we can simply revert a few commits from master and add semialign-indexed to resolve this without too much hassle nor extra-packages (which may cause us trouble through propagation of a newer relude).
Phew, conflicting files Edit: Ah, that was my fault I merged the taffybar change into master. Mea culpa. I’ll merge master into haskell-updates and resolve the merge conflict manually. |
Anyways I think our aim should be that our last merge before branch-off will have (nearly) 0 failing builds on all platforms. |
Does this mean that you definitely think we should have at least one more merge to |
Well, when I merged everything was fine on x86 but the other platforms had still a lot of failing builds. I think we should fix or disable those on the release branch. We now have two options.
I think 1) is better because we have our hydra-job to see the progress we are making. But I am okay either way. We just probably need a decision soon because people who do PRs right now want there fixes in the stable release so we need to tell them which branch to target. Of course, it would also be okay if we can‘t fix all builds before branch-off. Then we just backport them. But that wouldn‘t be less work. |
I assume that a query like https://hydra.nixos.org/eval/1669648?filter=haskellPackages on an evaluation of https://hydra.nixos.org/jobset/nixpkgs/trunk will give us basically the information we want. |
Okay, that sounds good. Let's aim for 1) then. I'll try to post a Hydra build report in on this PR in the next day or two. I probably won't have much time to focus on this until the weekend. If the branch off happens on the 21st, let's try to merge this PR on the 20th just in case. |
Yeah, no hurries. I didn‘t expect you to pick up on this before the weekend. There will still be plenty of time to fix everything starting on saturday. |
Depends on zlib somehow (https://hydra.nixos.org/build/143009645/nixlog/1) which is not declared in the cabal file.
haskell.compiler.ghcHEAD: disable DWARF on non x86
This should conclude a pass of direct aarch64-linux failures related to this issue on hydra. Subsequent evaluation may of course reveal more.
All of these packages use x86 intrinsics-related headers and don't compile on non x86 platforms as a result. These overrides should be refactored into the yaml configuration at some point. Resolves #122014.
x86 assembler doesn't compile on aarch64 of course.
* charsetdetect: dependency library which is vendored fails with a cpp failure on aarch64. Could probably theoretically support aarch64, but doesn't in practice. * persist-state: aarch64 (no UNALIGNED_MEMORY) and armv7l (32 bit) fail in cpp.
Main executable uses x86 assembler, so we can't build it anywhere at all.
Requires x86 assembler, so no luck building it anywhere else.
New hydra evaluation brought some additional intstances of this happening to light.
I've been trying to run the maintainer script to update one of my haskell pacakges but maintainers/scripts/haskell/regenerate-hackage-packages.sh fails with from nixpkgs be1e5f9 :
I didn't want to open an issue but if the error is LGTM I might. |
@teto Feel free to open an issue about this in Does nixpkgs/pkgs/stdenv/generic/default.nix Line 167 in a8f71f0
|
as well. I am on x86 but with nixExperimental. I've disabled the overlay so it's strange you can't reproduce. EDIT: I've created #123600 not to pollute this more. |
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh
I've merged @jonringer Just FYI for 21.05, this will be the last time We still have about 250 failing packages, all of which are either on darwin or aarch64-linux. All of our x86_64-linux packages are either correctly marked broken, or can be built successfully. |
This Merge
This PR is the regularly merge of the
haskell-updates
branch intomaster
.This branch is being continually built and tested by hydra at https://hydra.nixos.org/jobset/nixpkgs/haskell-updates.
I will aim to merge this PR by 2021-05-28. If I can merge it earlier, there might be successor PRs in that time window. As part of our rotation @sternenseemann will continue these merges from 2021-05-28 to 2021-06-11.
haskellPackages Workflow Summary
Our workflow is currently described at
pkgs/development/haskell-modules/HACKING.md
.The short version is this:
haskell-updates
(normally at the beginning of a merge window).haskell-updates
intomaster
every two weeks.mergeable
job is succeeding on hydra.This is the follow-up to #122510.