DevOps Weekly Log, 2024-01-31

[chreekat]

It’s the weekly log!

The last week had some variety due to competing deadlines and emergent issues. In terms of issues, I had three different things to deal with. First, I wrapped up my recent work with mitigating spurious failures in GHC CI, which had gotten unbearable lately. Things are looking better now:

(The last week’s numbers are better for job failures and master-branch pipeline failures! But still not great, obviously…)

Then, I got a couple reports of trouble receiving email from gitlab.haskell.org. I was able to track down the reason for both of them. I was pretty happy to be able to fix one of them by emailing the admins for icloud.com, who addressed our issue in under a couple hours! I’m still kind of amazed by that. Thank you to whoever made that happen. The other email issue wasn’t so easily resolved. In fact, it still isn’t resolved. Email is hard.

The third emergent issue was the discovery that a bunch of macOS CI runners had become unresponsive. Luckily I was still able to log in and clean things up.

…But hey, look at that. I just went to check on the runners again, and a different set of macOS runners are now unresponsive. I really can’t wait to have the time to fix these issues properly.

Luckily I did still have time for my main task, which is the migration of Stackage services to Haskell Foundation servers. I wrote automation: prep for using new bucket by chreekat · Pull Request #7299 · commercialhaskell/stackage · GitHub, which adds support for the new Haddock bucket, and began preparing to run a new Hackage mirror that will replace the long-serving mirror hosted by FP Complete. Last but not least, I drafted a project to include in Summer of Haskell - ideas that I hope to have posted by tomorrow.

That’s all for now!

And here’s the list of issues triaged yesterday. Like usual, I could not stay till the end of the call, so my notes are incomplete.

GHC Issue Triage Notes

• #24369: CI: ensure more tests are run using LLVM
  • A bunch of hard work on CI to enable testing more specific combinations of the huge matrix of combinations
• #24370: SPECIALISE rule desugaring fails unnecessarily
  • Has a fix already
• #24371: Wanted: better arity analysis
  • Some potential improvement in the optimizer
• #24372: Annoying but possibly harmless errors in test log
  • not sure what’s going on here, but it seems harmless
• #24373: ghcjs: Intermittent failures in test process005
  • being worked on
• #24374: GHC 9.10.1 tracking ticket
  • work in progress!!
• #24376: Template Haskell not working with WASM backend
  • yes.
• #24377: Wrong type signature for JavaScript asyncCallback in document
  • being handled by js team
• #24380: Build alpine bindists on more recent alpine release (3.18)
  • will be added to the exsiting set
• #24382: Hadrian "resource busy" errors are more frequent
  • not in ci, but in local VMs it seems pretty common there
  • Zubin sees it as well in HLS CI, and in many Windows versions
  • Maybe something changed in Windows?
• #24383: T24171 segfaults on AArch64 with GHC HEAD:
  • unfortunately --flavour=release is not supported(?)
  • Because split-sections isn’t supported on aarch64, and release enables it, so on aarch64 you have to run --flavour=release+no_split_sections
  • some push back on whether or not “release” should mean “release” or if it means a specific set of arguments that may or may not (in fact, does not) work on every platform.
  • Basically just need to treat release as “release_base” because that’s what it is. But we might be stuck with the name now.
  • Still need to double check that it’s not an actual bug unrelated to split sections.
• #24384: Support for external build system from MkDepend mode, i.e. ghc -M or equivalent
  • Related to similar past attempts
  • More thought needed perhaps, and clarification of what the goals are and how they are achieved
• #24385: Bootstrapping GHC via c
  • Would be nice if it was a possibility
  • In particular, the idea is to compile GHC to C, which can be moved to another system and built there. But it has been broken for a while.
  • Maybe not that difficult to implement!?
• #24386: Provide a way to desugar without inlining in the GHC API
  • Already quite a lot of discussion
  • The use case is LiquidHaskell
  • May end up being a simple flag
• #24387: Hadrian uses deprecated way to set project file.
  • Ben is already working on it, but it looks like it can’t be fixed due to backward/forward compat issues with Cabal
• #24388: Argument size computation for foreign ffi exports is likely wrong.
  • Seems to be a problem that will affect very few people
• #24389: error: ld: unknown option: -no_warn_duplicate_libraries on macOS with GHC 9.6.4
  • There’s some trouble getting this to duplicate. Matt will attempt.
• #24390: Implement multiline strings
  • I’m excited about this
• #24391: Add hadrian option for rerunning failed test
  • If someone wants to do it, go for it
• #24392: GHC 9.8.1 crashes with heap overflow while deriving Data on Windows if both -O -XHaskell2010 are enabled
  • Very interesting.
  • Needs more data
• #24393: Using -Dn can lead to segfaults
• #24394: -Dn is missing from user guide
• #24395: Profiled GHC flavour segfaults when building a target project with TH or GHC plugin
• #24396: Namespacing for WARNING/DEPRECATED pragmas