| 4 Sep 2025 |
|  Puna joined the room. | 21:21:56 |
| 5 Sep 2025 |
 John Ericson | If anyone wants to help me debug https://github.com/haskell-nix/hnix-store/pull/289 that would be great. Just wishing aloud in case I'm lucky | 01:30:55 |
| * John Ericson sleeps now | 01:31:03 |
|  @dmjio:matrix.org left the room. | 02:09:38 |
 maralorn | Aaah, what is the point of having ghc-lib-parser spanning three ghc versions when fourmolu and ormolu track cabal-syntax anyway which is tightly coupled to the ghc release … | 12:16:17 |
| maralorn | I have now the choice of downgrading ghc-lib-parser, fourmolu and ormolu to build hls on ghc 9.10 or to upgrade Cabal/Cabal-syntax. Both either globally or in a quite large overrideScope. | 12:17:35 |
| maralorn | I feel like I am overlooking something because that didn’t feel as painful before … | 12:18:04 |
 Artem | maralorn: the very strict bounds that Ormolu puts on Cabal-syntax look strange. I'd ask on their bug tracker exactly the question you're posing above: if you use ghc-lib-parser, you probably want to span over at least couple of GHC, but you also always limit Cabal-syntax to one version, so this looks like mixed messages... They always bump Cabal-syntax when they bump ghc-lib-parser, so they at least understand some connection they just overly pessimistic about it it looks like. | 15:10:21 |
| maralorn | I guess using ghc-lib-parser might have other advantages than just the compatibility range … | 15:14:22 |
| Artem | maybe, but there seems to be no reason to be as strict about Cabal-syntax bounds: they use just a few basic things from it, and those don't really change | 15:20:45 |
| maralorn | Okay | 15:22:12 |
| maralorn | It seems I am loosing my grip on being the nixpkgs maintainer when I didn’t first check whether a jailbreak works. 😄 | 15:22:36 |
| maralorn | * It seems I am loosing my grip on being a nixpkgs maintainer when I didn’t first check whether a jailbreak works. 😄 | 15:22:44 |
| maralorn | FTR, it didn’t. | 23:05:12 |
| 6 Sep 2025 |
 sterni (he/him) | the answer seems to be: detective work | 10:42:24 |
| sterni (he/him) | it is also extremely annoying to tell what versions of GHC a commit has been backported to | 10:42:49 |
 Teo (he/him) | Once you find the MR then you should be able to know the backporta since release managers leave comments when stuff gets backported, but all of it is so much friction. I occasionally consider writing a little web service to get this type of info | 11:01:37 |
| sterni (he/him) | I guess best bet is to go via the linked issue if there's one in the commit message since that's a requirement now | 11:04:31 |
| sterni (he/him) | maralorn: Cabal-syntax is reinstallable, ghc not; so that's probably the reason | 11:05:00 |
| maralorn | In reply to @sternenseemann:systemli.org
maralorn: Cabal-syntax is reinstallable, ghc not; so that's probably the reason Good point | 11:11:59 |
| sterni (he/him) | emily: would you look at that https://gitlab.haskell.org/ghc/ghc/-/commit/50842f83f467ff54dd22470559a7af79d2025c03 | 17:30:44 |
| sterni (he/him) | though I think it fails at configure time (?) | 17:31:48 |
 emily | 😅 | 17:31:54 |
| emily | good timing I suppose | 17:32:00 |
| emily | I think it was already a warning before | 17:32:33 |
| emily | I guess they made it an error and then reverted that? | 17:32:43 |
| sterni (he/him) | yeah sounds like it, tbh I linked this before I read the diff | 17:37:14 |
| sterni (he/him) | configure would still fail looks like | 17:38:43 |
| sterni (he/him) | but I guess the wording is significant… | 17:38:55 |
| emily | insofar as LLVM support on old GHCs is cared about it still makes sense to backport even the trivial bumps because it shuts up the warning on every single .hs | 18:10:56 |
