| 13 Mar 2026 |
 K900 | So maybe we can eat the openblas rebuilds on Linux | 06:26:59 |
| K900 | 
Download image.png | 06:27:41 |
| K900 | Like it's bad bad | 06:27:44 |
 vcunat | There's still x86_64-darwin openblas | 06:36:57 |
| vcunat | It's time for some staging-nixos, as discussed in #security:nixos.org | 06:38:30 |
| K900 | Then I guess we have to revert the kernel bump | 06:41:13 |
| vcunat | Darwin builds tend to get stuck now on "sending inputs". (no idea why or what's changed) Maybe that's making things worse. | 06:47:32 |
 Alyssa Ross | Unclear to me what's going on with the kernels because nobody posted what the regression actually is | 07:49:23 |
| vcunat | Simply unblocking the other changes sounds reasonable to me. | 07:57:19 |
| Alyssa Ross | Yeah, I guess. Just a shame to revert the kernels when there could be no significant issue with them. | 07:57:57 |
| Alyssa Ross | Okay the kernels are confirmed fine. | 08:09:44 |
 Ramses 🇵🇸 | is there any docs on how to fix a merge conflict when merging master in -next? I don't immediately find anything by grepping in the repo. Is this just manual merge and push? | 11:29:41 |
| Ramses 🇵🇸 | * are there any docs on how to fix a merge conflict when merging master into -next? I don't immediately find anything by grepping in the repo. Is this just manual merge and push? | 11:30:03 |
| K900 | Yes | 11:31:08 |
| Ramses 🇵🇸 | ok, fix is trivial (go version difference), I'll push the merge then | 11:34:21 |
| K900 | @Ramses 🇵🇸 this is unnecessary, 1.26 is the default Go version on staging-next | 11:45:37 |
| K900 | https://github.com/NixOS/nixpkgs/pull/497493/changes/e190313e265fc4881b05c0f6076d4ab03a0eefa5..e2e702cb4e1e024359e2915862a2ffaa874a305e | 11:45:39 |
| Ramses 🇵🇸 | Yeah, but I noticed that it was explicitly pinned on master, and always have been, so figured that the maintainers have a reason for that | 11:46:19 |
| Ramses 🇵🇸 | * Yeah, but I noticed that it was explicitly pinned on master, and always has been, so figured that the maintainers have a reason for that | 11:46:32 |
| Ramses 🇵🇸 | There is a commit on -next that goes go_1_24 -> go because 1.24 is EOL, and another on master that does 1_24 -> 1_26 | 11:47:49 |
 emily | prophylactic pins are not a great idea absent strong reason IMO | 11:58:37 |
| emily | if we had to bump something because the old version was going EOL and the new one works fine then that's a sign we're failing to keep up and will have less churn if we only pin if something breaks | 11:59:25 |
| Ramses 🇵🇸 | Yeah, but I think that's a question for the maintainers of that package, right? I didn't want to remove a pin behind their back because I'm not familiar with the package | 11:59:29 |
| emily | pinging them is a good idea for sure. but well, if a staging contributor has had to fix it then they get a say too IMO | 12:00:38 |
| emily | in return for the thankless task that I'd triaging these kinds of issues and stepping in for maintainers a lot | 12:01:12 |
| emily | anyway no super strong feelings. I just greatly prefer having only the minimum reactive version pinning | 12:01:52 |
| Ramses 🇵🇸 | I don't disagree. I just wanted to fix the conflict and opted for what I felt was the conservative approach of sticking to what seemed to have been the common practice for this package (I checked quite a bit of the git history to check this). I worried that otherwise I got an annoyed maintainer later on asking why I unpinned their input. | 12:03:02 |
| emily | especially when it's about EOLs. you can have upstreams that stay reasonably in sync with their dependencies' cycles but need manual work for each bump. but less so for supporting only the oldest supported version and still updating in a timely fashion | 12:03:12 |
| Ramses 🇵🇸 | Seems like the kind of situation where you end up annoying someone in any case | 12:03:16 |
| emily | yeah I don't think you did anything wrong :) | 12:03:43 |
