| 10 Jan 2026 |
 vcunat | * In the past few weeks I spent most of my nix* time on darwin, just in order to unblock merger/channels shared with linux. | 07:07:31 |
| vcunat | * In the past few weeks I spent most of my nix* time on darwin, just in order to unblock merges/channels shared with linux. | 07:07:34 |
| vcunat | I believe that users of darwin should do most of such work instead. | 07:07:53 |
| vcunat | (or it shouldn't be done at all if they're not sufficiently interested) | 07:08:35 |
 Grimmauld (any/all) | For the next unstable staging, do we send the glibc update? There is also https://github.com/NixOS/nixpkgs/pull/460515 which may cause some excitement | 16:11:41 |
 leona | glibc was already merged, so yes | 16:12:08 |
| Grimmauld (any/all) | I am tempted to send boost too, but i'll do the sensible thing and run some builds first | 16:14:57 |
|  gluesticks joined the room. | 17:23:04 |
| Grimmauld (any/all) | ding ding ding, fetcher fail on a patch in git{,Minimal}: https://github.com/NixOS/nixpkgs/blob/a99e7fd499bc1d1d164e2076c9ec96deae7d647f/pkgs/by-name/gi/git/package.nix#L134-L138
This one fails to fetch, returns 403 because anubis | 18:30:53 |
 Puna | i'd assume that the patch above it would also fail to fetch then | 18:40:21 |
| Puna | * i'd assume that the patch above it would also fail to fetch then? | 18:40:30 |
| Puna | corresponding commit from the mirror on github, if this needs to be replaced: https://github.com/git/git/commit/fe4e60759bfbf4eaca17949d3bbb204bb5c908a2 | 18:41:21 |
 @ghpzin:envs.net | There are at least another 7 patches that would need replacement: | 18:46:17 |
| @ghpzin:envs.net | * There are at least another 7 patches that would need replacement:
https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+%2Furl.*lore.kernel.org%2F&type=code | 18:46:23 |
| Grimmauld (any/all) | it was the first i ran into when trying to build the next staging | 18:48:19 |
| Grimmauld (any/all) | there may well be more, i did not investigate in detail | 18:48:32 |
 Alyssa Ross | https://social.kernel.org/objects/77946348-da89-4819-aebc-04e19fcd69f9 | 18:55:55 |
| Alyssa Ross | I think helpdesk@kernel.org is the place. You up for reporting? | 18:57:30 |
| Grimmauld (any/all) | Can do, headache permitting. Though i'll probably also post a response to their fedi post, if that is a communication channel they have open ("If you have a legitimate tool that is now suddenly returning 403s, please reach out to me.") | 19:02:01 |
| Alyssa Ross | Didn't know whether you had an account. I'm sure that's fine as well. | 19:02:33 |
| Grimmauld (any/all) | i have a chaos.social, thats good enough :tm:. Compared to matrix, fedi actually works | 19:03:09 |
| Grimmauld (any/all) | https://chaos.social/@grimmauld/115872388773834502
We'll see what happens. We may have to set curlOptsList = [ "--user-agent" "nixpkgs" ]; for lore.kernel.org fetchers, but that would be an acceptable workaround i guess | 19:15:10 |
 K900 | We already do I believe | 19:15:52 |
| Grimmauld (any/all) | (curlOptsList does not cause the hash to change, meaning adding that is a 0-rebuild operation) | 19:16:07 |
| K900 | IIRC our default UA for curl is something like "curl x.y / Nixpkgs yy.mm" | 19:16:33 |
| Grimmauld (any/all) | Uhh, is this documented? Would be good info to have | 19:16:55 |
| Grimmauld (any/all) | I don't see any magic in https://github.com/NixOS/nixpkgs/blob/50563c7a780f9a272145f20b59551c0768eddf0c/pkgs/build-support/fetchurl/default.nix | 19:18:12 |
| Grimmauld (any/all) | Ah found it: https://github.com/NixOS/nixpkgs/blob/50563c7a780f9a272145f20b59551c0768eddf0c/pkgs/build-support/fetchurl/builder.sh#L29 | 19:19:02 |
 emily | https://github.com/NixOS/nixpkgs/pull/478778 should fix this.
of course I care about Darwin and am interested in keeping it working. I have a big local stack of fixes and clean‐ups for LLVM and macOS 26 that I worked on during the testing for the LLVM 21 and CMake 4 bumps a couple months back, but I didn't anticipate stumbling into a governance clusterfuck that sapped most of my energy for technical work, and then prioritizing things like "stopping the Nixpkgs repository from going read-only" and "triaging 4 months of committer application backlog" over pushing non-urgent drafts out, and then I was trying to take a rare break from Nixpkgs over the holidays…
the "having to triage/fix issues with things we don't care about" problems we have in staging-next are a pervasive issue, not just limited to Darwin. we don't complain about "Linux users" not doing enough when a random channel blocker breaks on Linux. I try to take a look at things when I can, but I can't take responsibility for e.g. every random bug in Nix just because it triggers on macOS.
it's not like we have been merging untested stuff with regressions – the builder OS version bumps are essentially getting bumps of a bunch of world-rebuild libraries merged into staging across all release branches underneath us. in the future we should probably make sure to coordinate non-security macOS major version bumps on the builders with Darwin team availability and testing.
I do my best to help reduce the burden; between Randy's SDK rework and dropping support for old versions and x86_64-darwin, Darwin-specific packaging issues are much rarer than they used to be and we should hopefully have much more Darwin builder capacity soon. I also try to reduce the bus factor by encouraging people to get involved (https://github.com/NixOS/nixpkgs/pull/478468 went up just yesterday), but it's hard to recommend the experience of Darwin team to anyone right now.
I understand it is frustrating having to deal with anything in Nixpkgs without personal interest, but it is really demotivating to put in a ton of work taking responsibility for issues across the tree when it constantly gets met with implications that you're not doing enough or that we should drop Darwin. I've thought about quitting the project before because of it. anyway, probably not a useful rant but I think we would have more volunteer resources for Darwin triage if it was less miserable to offer it.
| 19:36:05 |
| 11 Jan 2026 |
|  ivan joined the room. | 01:56:08 |
