| 6 May 2025 |
 alexfmpe | This here: https://gitlab.haskell.org/ghc/ghc/-/issues/23415 | 22:27:07 |
| 7 May 2025 |
|  Aerden joined the room. | 08:03:34 |
 sterni | There is some kind of race condition in the install of cross compiled riscv64 ghc948 which is bizarre since I don't think we have the issue with the regular ghc | 09:30:23 |
 Alex | How frequently does it occur?
What does the error(?) look like? | 10:44:43 |
 maralorn | The Data.Text.show business is definitely aggravating. | 11:14:15 |
| maralorn | I have no clue how many ours of work and how many delays this will cost us … | 11:16:49 |
| maralorn | srsly, hackage needs a validator which plain forbids implict imports on packages without tight bounds. | 11:17:42 |
| maralorn | Although that wouldn’t help us much either … | 11:17:57 |
 teo (they/he) | Are the broken packages on stackage? Or is it stuff in nixpkgs that's not on stackage? At some point I want to put some effort into improving our ecosystem testing code in head.hackage and making sure we test as much as possible before we cut a release of GHC | 11:32:06 |
| maralorn | Yes: https://hackage.haskell.org/package/http-link-header which was affected is on stackage apparently. | 11:36:20 |
| maralorn | Although they already fixed it in their newest release. | 11:36:47 |
| maralorn | Besides that I only encountered problems in more or less local code. | 11:37:08 |
| maralorn | So maybe its not going to be as bad as I am fearing. | 11:37:22 |
 chreekat | https://github.com/commercialhaskell/stackage/issues/7743 is the Stackage coordination point | 11:39:18 |
| chreekat | I count 48 packages dropped, and Jens said at least 18 of them are direct dependents of text | 11:41:54 |
| chreekat | Luckily it was "just" nightly, so snapshots continue to be released. Just with fewer packages | 11:42:34 |
| teo (they/he) | Thanks! We have a draft PR to run head.hackage against stackage snapshosts somewhere. I want to tidy that up and merge that at some point. And then we could run that before a every release and have a better understanding of these things | 11:44:34 |
| teo (they/he) | Btw I'll be at Zurihac this year and I'd be keen to have a chat about how we can improve GHC/head.hackage processes to make things like this less painful in the future | 11:49:33 |
| sterni | i would guess more than 1/10; IIRC it is something like install: could not create file …: no such file or directory. Happens on Hydra, so you probably need a reasonable high -j (is marked big-parallel) and a busy machine | 11:52:58 |
| maralorn | I’ll be there, too. Let’s do that! | 12:33:02 |
| chreekat | I'm also in! | 12:53:01 |
 hellwolf | nice, I will be there too :) | 13:54:00 |
|  Brendon A Kay joined the room. | 15:00:46 |
|  Ethan joined the room. | 16:02:37 |
| maralorn | Does hydra kill jobs which need to much memory? | 21:15:38 |
| maralorn | Because the build I am currently trying is roughly at 100G RAM right now, so even if it succeeds, which seems unlikely, it doesn’t seem like a viable solution. 😄 | 21:16:51 |
| Alex | The kernel can if the overall system is low on memory (OoM killer). | 21:40:09 |
| Alex | I don't know if Hydra specifically is designed to limit memory usage. I don't recall such an option being very prominent in the configuration section of the Hydra manual. | 21:41:01 |
 Alyssa Ross | In reply to @maralorn:maralorn.de
Because the build I am currently trying is roughly at 100G RAM right now, so even if it succeeds, which seems unlikely, it doesn’t seem like a viable solution. 😄 that's same ballpark as linking firefox so it might be fine if it's tagged as big-parallel | 21:42:24 |
| alexfmpe | That....not.....what | 21:46:05 |
