Skip to content
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

haskellPackages: update stackage and hackage #129606

Merged
merged 51 commits into from
Jul 17, 2021
Merged

Conversation

expipiplus1
Copy link
Contributor

@expipiplus1 expipiplus1 commented Jul 8, 2021

This Merge

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

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-06-12. If I can merge it earlier, there might be successor PRs in that time window. As part of our rotation @cdepillabout will continue these merges from 2021-07-12 to 2021-07-26.

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 master 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!)

This is the follow-up to #128993.

nh2 and others added 8 commits July 4, 2021 22:15
`glibcLocales` only exists when glibc is used.

Similar to commit:

    8727284 - haskell: only use glibcLocales when using glibc
Fixes `pkgsMusl.elfutils` failing with `recompile with -fPIC`.

This was discovered trying to build `pkgsMusl.haskell.compiler.ghcHEAD`.
The library override that was present in the code referred to a
name that isn't even used in current GHC bindists.

Tested with:

    NIX_PATH=nixpkgs=. nix-build --no-link -A haskell.compiler.ghc8102Binary --argstr system i686-linux
This commit has been generated by maintainers/scripts/haskell/update-stackage.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
sternenseemann and others added 4 commits July 8, 2021 12:35
Upstream introduced too strict lower bounds in a new release. Since it's
too much hassle to create a new account in their redmine just for this
issue, I've used asserts to indicate when this will be able to be
removed.
This commit has been generated by maintainers/scripts/haskell/mark-broken.sh
@expipiplus1
Copy link
Contributor Author

haskell-updates build report from hydra

evaluation 1685002 of nixpkgs commit a7aded3 as of 2021-07-09 08:50 UTC

Build summary

Platform Failed ❌ DependencyFailed ❗ TimedOut ⌛🚫 Success ✔️
aarch64-linux 📱 32 67 6562
x86_64-darwin 🍎 77 41 2 6499
x86_64-linux 🐧 12 1 1 6690

Maintained packages with build failure

Maintained packages with failed dependency

Unmaintained packages with build failure

103 job(s)

Unmaintained packages with failed dependency

116 job(s)

Report generated with maintainers/scripts/haskell/hydra-report.hs

@expipiplus1
Copy link
Contributor Author

expipiplus1 commented Jul 9, 2021

@sternenseemann: rel8 is failing because the (only) version of opaleye we have is too new. Should we add an older opaleye to non-hackage-packages or look at patches for rel8?

Also I didn't realise that the mark-broken script marked maintained packages broken, should this be something done manually instead?

@maralorn
Copy link
Member

maralorn commented Jul 9, 2021

Also I didn't realise that the mark-broken script marked maintained packages broken, should this be something done manually instead?

We can have discussions about this, but the intention was to only ever run the script when either a) no maintained packages are broken or b) get manually exempt or c) have been broken for 7 days.

In general the idea is to post the highlight report early in the process and mark broken only directly before merge.
The main reason for the report is to alert maintainers early to the fact that their packages are broken. (So I’ve seen you post the report directly before merges. That’s not wrong, but we should be careful with this. Highlighting people to notify them that we are breaking their packages right now, is not very useful.)

Again, this process is fresh, if there are arguments to improve on any of this, I am all ears.

PS: In the past hackage2nix threw an error when a maintained package got marked broken. I have silently broken that feature with a recent PR to cabal2nix. But this was accepted on purpose because we want to be able to mark maintained packages broken. We want more packages to be maintained, we have a clear policy how to mark them broken and removing maintainers when their package breaks seems to me to be a) in contradiction to the aim to have more maintainers also b) it seems a bit rude.

@sternenseemann
Copy link
Member

@sternenseemann: rel8 is failing because the (only) version of opaleye we have is too new. Should we add an older opaleye to non-hackage-packages or look at patches for rel8?

Yeah, I've looked into it, but the upstream patch doesn't apply cleanly on the last release. I'm unsure, but I think downgrading opaleye globally may be fine (or bugging upstream for a new release).

The source tarball now has DOS line endings for some reason, requiring
the use of dos2unix. Also needs a jailbreak since the template-haskell
bound has become too strict.
@sternenseemann
Copy link
Member

We can have discussions about this, but the intention was to only ever run the script when either a) no maintained packages are broken or b) get manually exempt or c) have been broken for 7 days.

Running the script early is bad in short, because it hides new regressions we may want to fix.

@sternenseemann
Copy link
Member

sternenseemann commented Jul 14, 2021

Upstream issue for cedille: cedille/cedille#162

@github-actions github-actions bot added 6.topic: agda "A dependently typed programming language / interactive theorem prover" 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS labels Jul 15, 2021
@cdepillabout
Copy link
Member

cdepillabout commented Jul 16, 2021

Now that the Agda stuff is fixed, I'd like to merge this in the next day or so. Here's what I'm planning on marking broken (unless they get fixed in the next 24 hours, or someone absolutely needs me to hold off):

@sternenseemann
Copy link
Member

sternenseemann commented Jul 16, 2021

IMO, there is no need to, there is no strong promise that stuff in pkgsMusl works and it fails quite quickly.

It's an odd one to be sure. Seems like the binaries produced by the writer are killed with SIGKILL upon startup on macOS for some reason I haven't been able to pinpoint yet. I guess we can remove the darwin job from mergeable if you want, but please do not mark it as broken.

Also this is quite serious and I would appreciate if someone more familiar with darwin could have a look at that.

@nh2
Copy link
Contributor

nh2 commented Jul 16, 2021

IMO, there is no need to, there is no strong promise that stuff in pkgsMusl works and it fails quite quickly.

I'm fine with having it marked as broken; we know it currently doesn't work, might as well tell the user at evaluation time that there's work to do in nixpkgs, perhaps they'll contribute vs being disappointed by a compile failure :)

I've looked into it shortly, but not figured out how to convince the build to find in which directory to look for -lgmp. --with-gmp-libraries seemed ineffective for this.

So this will need some deeper investigation.

@cdepillabout
Copy link
Member

It's an odd one to be sure. Seems like the binaries produced by the writer are killed with SIGKILL upon startup on macOS for some reason I haven't been able to pinpoint yet. I guess we can remove the darwin job from mergeable if you want, but please do not mark it as broken.

No problem.

Are you thinking that this is something that is only failing on Hydra, but works normally if you run it yourself?

@sternenseemann
Copy link
Member

Are you thinking that this is something that is only failing on Hydra, but works normally if you run it yourself?

It happens locally as well, but I have no idea why.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: agda "A dependently typed programming language / interactive theorem prover" 6.topic: haskell 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: clean-up 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants