| 12 Oct 2025 |
matthewcroughan | Didn't know this room existed, I do now, sorry | 17:01:25 |
matthewcroughan | Yureka (she/her): Can't we merge that patch now that it is conditional on musl? | 17:04:24 |
matthewcroughan | Sorry I didn't spot that, I thought all the patches were conditional on musl even | 17:04:34 |
matthewcroughan | Like you say it's more proper to apply the patch unconditionally, but I thought we always make it conditional | 17:05:54 |
Yureka (she/her) | that was the idea | 17:08:12 |
emily | https://github.com/NixOS/nixpkgs/pull/451386 but depends on https://github.com/NixOS/nixpkgs/pull/451385 | 17:08:18 |
matthewcroughan | I know what happened anyway, I had https://github.com/NixOS/nixpkgs/pull/451274 open and mistook the tags when I moved to the other tab | 17:08:25 |
Yureka (she/her) | we usually don't want patches to be conditional on something because the people doing the updates won't notice when patches no longer apply | 17:08:36 |
matthewcroughan | I see yeah, just like the systemd example | 17:08:49 |
emily | (and because a patch conditional inherently can't be upstreamed) | 17:08:52 |
emily | (so a conditional "inside" the patch is always nicer) | 17:09:05 |
matthewcroughan | Are the rebuild labels based on inherent rebuild cost? Or is it based on whatever hydra/ci has to build? | 17:09:25 |
Yureka (she/her) | I don't understand the question | 17:09:38 |
matthewcroughan | Like I wouldn't have expected the systemd rebuild count to be so low | 17:09:42 |
emily | I wonder if the "backport" flow is nicer for rebuild-avoidance too. | 17:09:43 |
emily | do the nice thing on staging, add the bodges to make it not a mass rebuild when backporting to -next. | 17:09:50 |
matthewcroughan | ah okay it's because it's conditional on musl it avoids the rebuild labels | 17:10:04 |
emily | that way the most you can neglect to do is getting the fix early, rather than neglecting to clean up. | 17:10:12 |
Yureka (she/her) | that's because hydra doesn't build pkgsMusl.systemd | 17:10:12 |
Yureka (she/her) | or anything depending on it | 17:10:16 |
matthewcroughan | What's needed to make hydra keep track of this? :P | 17:10:25 |
matthewcroughan | I wanted to make a flake to keep track of it, I'm in the process of doing that atm | 17:10:34 |
matthewcroughan | hercules is nice but hydra is made for nixpkgs more than hercules is | 17:10:49 |
emily | you can run your own Hydra, building tons of stuff on dynamic Musl isn't a good use of our limited build resources | 17:11:14 |
matthewcroughan | Yeah that makes sense, but I'm happy to put my resources to use on musl | 17:11:38 |
matthewcroughan | My https://github.com/MatthewCroughan/nixos-musl/tree/refactor flake is keeping track of what is necessary in these profiles | 17:12:34 |
matthewcroughan | idea is that musl.nix contains only want is currently necessary to build a nixpkgs.lib.nixosSystem {} on musl, and nothing more | 17:13:00 |
Ihar Hrachyshka | on a relevant point: how do folks feel like about a packaging having a passthru.tests.static = pkgsStatic.<itself> to signal it is desired / expected to build? or is it redundant? | 17:13:05 |
matthewcroughan | * idea is that musl.nix contains only what is currently necessary to build a nixpkgs.lib.nixosSystem {} on musl, and nothing more | 17:13:06 |
emily | can be useful, OTOH is in tension with moving variant package sets to variants.nix which we'd generally like to do. | 17:13:44 |