haskell-updates build report from hydra

evaluation 1669209 of nixpkgs commit b729cc4 as of 2021-05-11 21:09 UTC

Build summary

Maintained packages with build failure

• ghcHEAD @kosmikus @MarcWeber @peti
  • [:iphone::x:] [:apple::heavy_check_mark:] [:penguin::heavy_check_mark:] haskell.compiler
  • [:iphone::x:] [:apple::no_entry_sign:] [:penguin::heavy_check_mark:] haskell.compiler.native-bignum

Maintained packages with failed dependency

• haskell-language-server @maralorn
  • [:iphone::heavy_check_mark:] [:apple::heavy_check_mark:] [:penguin::heavy_check_mark:] toplevel
  • [:iphone::heavy_check_mark:] [:apple::heavy_check_mark:] [:penguin::heavy_check_mark:] haskell.packages.ghc8104
  • [:iphone::heavy_check_mark:] [:apple::heavy_check_mark:] [:penguin::heavy_check_mark:] haskell.packages.ghc884
  • [:iphone::heavy_exclamation_mark:] [:apple::heavy_exclamation_mark:] [:penguin::heavy_exclamation_mark:] haskell.packages.ghc901
  • [:iphone::heavy_check_mark:] [:apple::heavy_check_mark:] [:penguin::heavy_check_mark:] haskellPackages
• [:iphone::heavy_check_mark:] [:apple::heavy_exclamation_mark:] [:penguin::heavy_check_mark:] ldgallery @pacien
• [:penguin::heavy_exclamation_mark:] mergeable @cdepillabout @maralorn @sternenseemann

Unmaintained packages with build failure

Unmaintained packages with failed dependency

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

That’s it

In my 2 week window May 1st to May 14th I have now merged haskell-updates 4 times into master. I think it’s enough for now. The branch still exists, and I might push one last hackage bump but I wont open a new pull request. @cdepillabout will take over on the weekend. They can decide how and when to procede.

Thanks to everyone who helped in that time, especially @sternenseemann who worked like a bear.

I will take this opportunity to write a short documentation of how the process that I imagined and tried works and what I learned. This should be put into more rigorous documentation, but I think writing it down here is a good first step.

Summary

Step 1) Start stabilization phase.

Checked out haskell-updates and run

maintainers/scripts/haskell/update-stackage.sh --do-commit && maintainers/scripts/haskell/update-hackage.sh --do-commit && maintainers/scripts/haskell/regenerate-hackage-packages.sh --do-commit

push it.

Step 2) Open PR

I basically pasted the same template everytime. I think it’s good practice to link to the previous PR.
The template can certainly be improved I’m looking forward to others iterating on it.
I think it’s convenient to quickly create a first comment which you can later use to paste the build-report there with ctrl+a ctrl+p. Putting the build report as part of the initial comment is a tiny bit more hazzle.

Step 3) Testing

Once hydra built all x86-linux builds you can run

maintainers/scripts/haskell/hydra-report.hs get-report
maintainers/scripts/haskell/hydra-report.hs ping-maintainers | wl-copy

(wl-copy is from pkgs.wl-clipboard so you get the report right into the clipboard. There is xclip when you are not on wayland.)
and then paste it into the above created comment.

Step 4) Fixing the branch

For fixing packages there is obviously a lot to consider and I wont cover all of that here just a few points I noticed.

Relevant scripts are
maintainers/scripts/haskell/{mark-broken.sh, regenerate-hackage-packages.sh, regenerate-transitive-broken-packages.sh}

mark-broken.sh can be run with and without --do-commit which is both very useful, also it is idempotent.
It marks packages from the last pulled hydra report as broken, also it regenerates the packageset and the transitive-broken file and then the packageset again. So when you’ve run it the branch will probably be in a good shape afterwards.

• There are quite a few packages broken for which we have overrides. That’s kinda a mismatch. We should either fix the packages or remove the overrides. Also we haven‘t run krank for quite a while.

• I made the principle of only marking something broken if it’s build directly fails. If it is broken by a dependency we should only disable the hydra build, never mark it broken.

• Not all broken or dontDistribute packages get auto-detected by the tooling:

  • Packages with "unknown" license won‘t get build. So if they are broken and this affects a dependency they need to manually get marked broken.
  • Packages with deprecated or insecure dependencies need to be disabled manually.
  • Packages that depend on a package unsupported on a platforms need to be manually disabled for that platform.
  • Some packages which consistently timed out …
    (I think most of this can be made smoother somehow.)

• Fixing builds can lead to iteration of hydra evals, because their reverse deps get enabled and some may fail. But that’s nothing bad.

• I have pinned the "maintained" and "mergeable" job to my hydra dashboard which is convenient because it gives you a lot of links to easily navigate to places where you wanna go on hydra. Also I often used the search filters .x86_64 and the restart eval button.

• Sadly mergeable is broken because of darwin haskell.tests. We shouldn‘t get used to this to not let the job loose meaning.

Step 5) merging

• This one is straight forward. Besides fixing all eval errors and the build errors we care about I didn’t run any checks. I maybe should have? Not sure. I don‘t know of any issues that would slip through in this process, but I would like to learn about it if there are some.

• Don‘t delete the haskell-updates branch. I did once accidentally. Bad idea.

Final thoughts

I will collect yet another todo list here:

• I didn‘t try yet to update our package list on hackage. I feel like we need another script to do that and for that we need to package https://github.com/peti/package-list.
• We should improve on the unknown license situation.
• Deactivating builds transitively could probably reasonably be done by platform. That would be more principled than what we do now.
• The name of the transitive-broken.yaml feels grammatically dubious and I feel a little bad about that.
• I welcome any improvements to the scripts I wrote. I will have no hard feelings at all if someone finds better solutions to what I did.
• I don‘t expect anyone else to write a summary like this in the future I just felt like it.

I will stop know to not plummet my signal-to-noise ratio.