| 21 Sep 2025 |
 emily | this is not really relevant for the Nix case | 14:55:23 |
 sterni (he/him) | alexfmpe: https://github.com/nixos/nixpkgs/blob/e7f97488c1800dd9ee4316cc1021b751c05ab8f2/pkgs/development/haskell-modules/configuration-ghcjs-9.x.nix?plain=1#L34 i think this should be resolved with 9.12?! | 20:00:28 |
| sterni (he/him) | emily: https://github.com/NixOS/nixpkgs/pull/413450#issuecomment-2941845343 | 20:04:18 |
 alexfmpe | huh probably yeah | 20:05:41 |
| emily | right. I think it is still irrelevant/useless for the source builds though | 20:06:42 |
| emily | because all it can do is strip or fail to strip things that Nix will strip or fail to strip anyway | 20:07:02 |
| emily | in the case on that PR, xattr(1) was dutifully reporting that it failed to strip com.apple.provenance I suppose, and the installation procedure was unhappy | 20:07:21 |
| 22 Sep 2025 |
 Wolfgang Walther | sterni should we cherry-pick all the fixes we're not making to staging-next into haskell-updates? | 11:44:41 |
| Wolfgang Walther | * sterni should we cherry-pick all the fixes we're now making to staging-next into haskell-updates? | 11:44:47 |
 maralorn | My suggestion would be to pause work on h-u until staging-next is merged? | 11:57:22 |
| Wolfgang Walther | For possibly a full week or more? | 12:09:35 |
| maralorn | Is that unreasonable? | 12:15:35 |
| sterni (he/him) | I think it makes sense to stage a bunch of set rebuilding changes on the branch and use a time when the x86_64-linux queue has calmed down a bit to get through it | 12:24:16 |
| sterni (he/him) | 24.11 rebuilds everything again | 12:24:21 |
| Wolfgang Walther | Imho, yes. That's essentially just making the next cycle much longer. | 12:24:21 |
| sterni (he/him) | package set update seems to eval already at https://github.com/NixOS/nixpkgs/pull/445051 | 12:26:38 |
| maralorn | I mean ideally the next cycles will be very quick, anyway. | 12:26:55 |
| maralorn | Well, I mean anything that we want to do we can obviously do on the branch. I was just thinking that it might not be necessary to do the cherry-picks. | 12:28:36 |
| maralorn | * Well, I mean anything that we want to do we can obviously do on the branch. No need to stop working. I was just thinking that it might not be necessary to do the cherry-picks. | 12:29:03 |
| Wolfgang Walther | I'm just worrying about merge conflicts that we would have to resolve later. By picking the commits now, we can probably avoid most of them. | 12:33:01 |
| Wolfgang Walther | But maybe there won't be too many, if we don't have too many changes in the cycle anyway. | 12:33:21 |
| sterni (he/him) | I think it does make sense also just to have visibility on those packages as well | 12:34:11 |
| sterni (he/him) | but may be inconsequential if staging-next is quick… | 12:34:23 |
| maralorn | I mean, tbf. nixpkgs commit history is a mess anyway. So we can probably just do it … | 12:34:58 |
| sterni (he/him) | https://github.com/NixOS/nixpkgs/pull/443159 can also go into haskell-updates | 12:54:47 |
| sterni (he/him) | I think half of all haskell related commits from the last two months exist twice already | 12:55:26 |
| maralorn | You would probably have had it easier to convince me in this discussion if you had informed me that one of the PRs not being able to merge because the missing cherry-picks mad conflicts more likely was mine. | 18:01:25 |
| 23 Sep 2025 |
|  kenji changed their display name from a-kenji to kenji. | 10:39:01 |
 Teo (he/him) | Is there an easy way to create a dev shell where I can use GHC with the llvm backend? Ideally without having to recompile ghc | 12:25:26 |
| Teo (he/him) | Oh wait maybe it's fine with stuff just being on the PATH | 12:27:39 |
