| 11 Jul 2025 |
 K900 | I don't think so, really | 07:50:10 |
| K900 | We'd like to not grow more bespoke tooling, generally | 07:50:29 |
| K900 | Though that's often hard to avoid | 07:50:35 |
 jollywater | understandable | 07:50:45 |
| K900 | But I do think we're moving in a direction of working with upstreams more to solve our problems | 07:51:01 |
| K900 | Instead of trying to build around them | 07:51:05 |
| jollywater | loved hearing about the rewrite for nixos-rebuild | 07:51:10 |
| K900 | Which is good | 07:51:17 |
| jollywater | looked over some old articles and blog posts etc trying to figure out how to help out and noticed the bug requests on git just keep getting higher and thought thatd be a good place to start👍 ones that affect usability. | 07:52:43 |
| K900 | The number of open issues is a really bad metric tbh | 07:53:24 |
| jollywater | im aware just gotta sort through to find actual bugs👍 I mainly code in rust though so thats why I was asking about rust | 07:54:25 |
| jollywater | could very easily contribute some rust code | 07:54:53 |
 emily | FWIW I wouldn't necessarily agree with this – sometimes there is just not going to be an upstream thing for what we need | 12:59:17 |
| emily | admittedly systemd is implementing more and more glue stuff, but it's often highly opinionated to the extent that "this doesn't work for NixOS" will just get a "meh" | 12:59:44 |
| emily | we have to take ownership of a lot of glue, it's just that right now a bunch of it is random inlined Bash | 12:59:56 |
|  @m4dc4pxx:matrix.org joined the room. | 15:30:55 |
| @m4dc4pxx:matrix.org | Hello! I'm trying to do some nix hacking on macos. I've built nix successfully, but my changes aren't showing up when I run the binary. (I've added logging I'm pretty sure I should see, and its not there.) I suspect its because my system nix uses the multi-user setup and the daemon is not running the binary I built. Is there any solution besides replacing the system nix? Or am I looking in the wrong direction? Appreciate any help!
| 15:33:39 |
 dramforever | depending on what changes you're looking to do | 15:52:37 |
| dramforever | if it's something you want to change in system nix then of course you have to replace system nix | 15:52:59 |
| @m4dc4pxx:matrix.org | On MacOS is that my only option when I want to run a build with my modified binary? | 15:57:10 |
| @m4dc4pxx:matrix.org | (I'm trying to improve AWS error handling w/ S3 caches FWIW, particularly around expired tokens) | 15:58:09 |
| dramforever | if you just want to test it, you can look into how existing tests work | 16:01:41 |
| dramforever | i'm not sure if there's anything network in it | 16:01:55 |
| dramforever | but there's some scripts that create a local store just for testing purposes | 16:02:09 |
| @m4dc4pxx:matrix.org | Well I need to interact with AWS w/ an expired token to see the behavior. I don't imagine the existing tests are gonna help much, even if they are mocking AWS. | 16:04:44 |
| dramforever | the existing tests handle building in a local store part | 16:05:05 |
| dramforever | oh | 16:05:07 |
| dramforever | by local i mean separate | 16:05:11 |
| dramforever | it doesn't touch the system nix | 16:05:15 |
| @m4dc4pxx:matrix.org | Easiest (for me) would be running the nix binary I built w/ extra logging against real AWS | 16:05:21 |
