| 6 Sep 2025 |
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 |
emily | but yeah I don't get the impression there is much care for it | 18:29:53 |
emily | even the LoongArch64 person making an mcmodel fix was like "this isn't a good fix because we should just have NCG" | 18:30:03 |
sterni (he/him) | true, but we don't really exercise it with later versions of GHC I think | 18:30:04 |
emily | I did my best, though, in terms of backporting everything LLVM-version-relevant | 18:30:30 |
emily | pretty sure I was more thorough than upstream is when bumping from what i saw | 18:30:52 |
sterni (he/him) | yes, I did not find anything you missed; except for a fix for llvm-ar >= 17, but that's unrelated to the llvmPackages we take as an input | 18:35:04 |
sterni (he/him) | I think worrying about hostPlatform.useLLVM is for some other time | 18:35:24 |
emily | hm would that not be picked up from the wrapping we do? | 18:37:59 |
emily | ah I guess it would still just use the regular ar by default? | 18:38:00 |
emily | not sure what ar we use on Darwin tbh | 18:38:00 |
sterni (he/him) | I think GHC just uses AR, but that's only llvm-ar if useLLVM in nixpkgs (or does darwin use it?). As such it's also controlled by the global default LLVM version, so orthogonal to what we're doing | 19:21:28 |
emily | right | 19:30:57 |
emily | I think we might be switching to using more LLVM bintools on Darwin ~soon | 19:31:05 |
emily | so it would become relevant then I suppose | 19:31:08 |
| 7 Sep 2025 |
emily | a hidden message from the gods, the lost last great GHC version:
pkgs/development/haskell-modules/hackage-packages.nix
115923: sha256 = "06y0pz0rny9pbm5lzc6n64zdf7139dgwbghc908vzndm6pcjrs5h";
| 00:23:53 |
sterni (he/him) | trust me bro 6 more minor releases and GHC 9.0 is going to be good just 6 more | 00:37:44 |
sterni (he/him) |  Download 20250907_02h36m10s_niri.png | 00:37:59 |
sterni (he/him) | do you think this thunderbird bug is trying to tell me something | 00:38:07 |
emily | I looked at that screenshot before seeing the message and was like yeah that's slightly more than I expected but I guess there have been a lot of PR comments today | 00:42:16 |
sterni (he/him) | I do not remember how I fixed this last time and it does not seem to be affected by restarting, so I'm stuck with you indefinitely | 10:50:38 |
Wolfgang Walther | Looks like corruption in the thunderbird profile. What helped me in this case was deleting the respective file in ~/.thunderbird/.../ImapMail/... and downloading it again. Of course.. only do that with IMAP, not with POP3. | 11:00:10 |
sterni (he/him) | Yeah, I think I deleted and redownloaded something last time. | 11:02:01 |