| 12 Oct 2025 |
 matthewcroughan | only thing blocking my little tracking flake, so I'm going to merge it? | 19:58:19 |
| matthewcroughan | and it's conditional on musl, so no mass rebuilds | 19:58:27 |
| matthewcroughan | I don't know if I understand nixpkgs-review though, why does it say it only built the nixpkgs-manual | 19:59:02 |
 Lun | It only diffs things marked recurseForDerivations, pkgsMusl isn't and nothing that is depends on pkgsMusl.systemd. | 20:01:16 |
| matthewcroughan | Yeah I just wanted to use it for concrete testing that merging doesn't break anything by accident, which is obvious based on the diff, but I just do it anyway to check | 20:01:58 |
| Lun | You can -p pkgsMusl.systemd (repeatable arg) to nixpkgs-review to get it to test attrs that the eval compare doesn't find | 20:02:59 |
| matthewcroughan | Ah nice, I was looking for how to tell nixpkgs-review to do it anyway | 20:03:28 |
| matthewcroughan | instead I was just cherry-picking this on staging-next and making a nixos system based on it | 20:03:44 |
| matthewcroughan | and also doing nix build github:yuyuyureka/nixpkgs#legacyPackages.aarch64-linux.pkgsMusl.systemd | 20:03:55 |
| matthewcroughan | But I prefer the nixpkgs-review report | 20:04:03 |
| matthewcroughan | I'll do the -p one too | 20:08:41 |
| matthewcroughan | Lol sneaky, it depends on the iproute2 PR | 20:16:14 |
| matthewcroughan | If I had it my way I'd just merge https://github.com/NixOS/nixpkgs/pull/451338 and then https://github.com/NixOS/nixpkgs/pull/451274, but I'm too scared and don't wanna get yelled at, so I'll wait for Alyssa or someone else | 20:16:57 |
| matthewcroughan | Spent a while building and testing https://github.com/NixOS/nixpkgs/pull/451338 and merged it since it's conditional | 21:43:36 |
| matthewcroughan | * Spent a while building and testing https://github.com/NixOS/nixpkgs/pull/451338 and merged it since it's conditional and seems harmless | 21:44:12 |
| matthewcroughan | IDK how people feel about the systemd vendoring of patches though, so might like someone else to review that first | 21:45:11 |
 emily | fwiw you can add .patch at the end of a PR URL to get the patch series in a single file | 22:13:28 |
| emily | but I don't think it matters either way so I'd go with Yureka (she/her)'s preference | 22:13:48 |
| emily | (as in, it could be vendored as one file) | 22:14:24 |
 Yureka (she/her) | alyssa has specifically asked me not to do that in the past, when the branch the commits are on isn't permanent | 22:14:28 |
| emily | right I didn't mean fetchpatch | 22:14:43 |
| Yureka (she/her) | Oh, I found it much more readable like this compared to one long file | 22:14:44 |
| Yureka (she/her) | I can also locally do git diff A...B | 22:14:59 |
| Yureka (she/her) | and pipe that to a file | 22:15:03 |
| emily | the .patch preserves the commit attribution and messages which is nice, but I'm fine with a bunch of files too | 22:15:17 |
| emily | just figured a single file may be easier to update if it gets force-pushed again etc. | 22:15:23 |
| Yureka (she/her) | or concat the .patch files together afaik? | 22:15:26 |
| emily | yeah I mean https://github.com/systemd/systemd/pull/37788.patch just does the concatenation for you :) | 22:15:44 |
| emily | I think it's fine as-is though, just mentioned it since ^ | 22:15:55 |
| Yureka (she/her) | I explicitly mentioned the vendoring of the patches in the PR, because vendoring them at all (no matter if in one file or several) might be controversial. When the openembedded systemd musl patchset was originally adopted in nixpkgs, being able to fetch the patchset from an existing source was considered a significant advantage. | 22:20:18 |
