| 12 Oct 2025 |
 matthewcroughan | I spent a few hours to build https://github.com/NixOS/nixpkgs/pull/451274 | 19:58:11 |
| 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 |
