| 22 Jan 2025 |
 emily | no, it's just broken because we haven't bumped libgit2 in Nixpkgs yet | 23:20:48 |
| emily | that's why I had to test with --override-input | 23:20:53 |
| emily | it's a catch-22 since by the time it hits the channels nix-init will be broken | 23:21:03 |
| emily | so ideally we'd get a nix-init release cut before the staging-next (as the main consumer of releases is presumably Nixpkgs) | 23:21:29 |
| emily | I could pin the flake input to the PR I suppose 😅 | 23:22:25 |
 Mic92 | emily: you mean staging-next? | 23:23:01 |
| Mic92 | I think I would prefer pinning that over breaking ci | 23:23:13 |
| emily | it's not in -next yet (it's not even in staging) | 23:23:32 |
| emily | we could merge into staging and then pin staging, but then CI would be building stdenv | 23:23:41 |
| emily | pinning to the PR head produces a working build though | 23:23:48 |
| Mic92 | Ok. I guess it would be fine to bump a nix-init release once we it hits staging-next. | 23:25:44 |
| Mic92 | No one will be mad if it's broken in staging for a while. | 23:26:51 |
| emily | fair enough | 23:28:24 |
| emily | pinning staging-next in the flake feels a bit weird though | 23:28:40 |
| emily | I probably will not remember to unpin it once the cycle is over | 23:28:44 |
| emily | I was hoping to get this addressed before merging the libgit2 bump as otherwise we are going to have ~0 regressions | 23:29:04 |
| 23 Jan 2025 |
| Mic92 | pinning staging-next is a bit weird but I also don't expect too many people to use the github version over the nixpkgs version of nix-init | 00:08:22 |
| emily | fair | 00:17:05 |
| emily | could just pin the PR head for now to unblock CI in that case? | 00:17:11 |
|  bumperboat joined the room. | 08:38:03 |
| Mic92 | emily: Is the the merge-base on something that has a reasonable amount of packages cached? | 09:31:39 |
| Mic92 | We have github actions in their, so I don't want to block runners in nix-community for half a day. | 09:32:14 |
