| 5 Sep 2025 |
 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 |
| emily | but yeah, when I was looking over all the issues and patches and bumps it seemed like the compatibility issues were all "obvious hard error from CLI change" type things (and even some of those only discovered/fixed after the fact) | 18:12:20 |
| emily | there's things like the LoongArch64 -mcmodel stuff that I linked in the file, but those aren't really related to the version | 18:12:48 |
| emily | like there are "non-obvious bugs/infelicities in the LLVM backend" and there are "obvious compat issues with how they invoke it that produce hard errors when bumping the version", but I couldn't really find anything in the intersection of those | 18:14:02 |
| emily | and several of the bump changes make it clear that the QA process is just "make sure it bootstraps" anyway | 18:14:28 |
| emily | er not intersection exactly. you know what i mean :) | 18:15:20 |
| sterni (he/him) | LLVM backend could be totally unusable already now and we wouldn't really know unfortunately. | 18:22:29 |
| sterni (he/him) | technically, this fix would help LLVM 19 compat insofar as it helps LLVM >= 3.4.0 compat :D https://gitlab.haskell.org/ghc/ghc/-/issues/25019 | 18:26:12 |
| emily | well, it works enough on 9.4 with my patches to build GHC itself at least… | 18:29:30 |
