| 31 Jan 2026 |
 Austin Horstman | cuz i have a m4 max 64gb and mine took much longer last time... | 00:58:04 |
| Austin Horstman | but i always did it as part of a config build | 00:58:25 |
 Ihar Hrachyshka | $ cat /etc/nix/nix.conf | grep 'core\|max'
cores = 0
max-jobs = 5
it's a 10core machine
| 00:58:43 |
| Austin Horstman | Hmm wonder if i'm hurting myself by setting cores.. | 00:59:20 |
 hexa | yeah, that's easily bigger than all the builders we have | 01:04:08 |
| Ihar Hrachyshka | in infra config, we have max-silent-time = 7200; # 2h for all macs.
the PR that added support for passing these overrides from untrusted clients is: https://github.com/NixOS/nix/pull/7079
which has been there for a long time...
$ git tag --contains 6e049ae607b53eba3c9c6bed260a0b39a3f73a70 | sort | head -n 1
2.12.0
| 01:15:47 |
| Ihar Hrachyshka | https://github.com/NixOS/nix/blob/77b6b01b727f0cd1324e431a32a8854768b957ef/src/nix/nix-store/nix-store.cc#L903
so Hydra calls to remote via ssh, runs nix-store --serve there, nix-store then calls to local nix-daemon. When it does this call, apparently it doesn't propagate the settings? | 01:38:31 |
| Ihar Hrachyshka | actually, second rebuild of firefox took even quicker...
$ head -n 1 build.log ; tail -n 1 build.log
[2026-01-30 19:53:47] warning: Git tree '/Users/ihrachyshka/src/nixpkgs/ff-timeouts' is dirty
[2026-01-30 20:39:10] firefox-unwrapped (post)> ✅ All done! (2 already cached, 19 in upstream)
| 02:10:40 |
| Ihar Hrachyshka | ah I see. the previous 2h result was on ... macbook air. the second one that completed in 46 mins is the actual mac mini m4 run. | 02:14:02 |
| Ihar Hrachyshka | https://github.com/NixOS/nix/pull/15125 | 03:56:06 |
| Ihar Hrachyshka | hexa: if my theory ^ is correct (which is hard to believe), then I'd advise to bump max-silent-time settings on infra to 4h. all nixpkgs cases where maxSilent is overridden in meta are for 4h. | 03:59:00 |
 Martin Häcker | Anyone at FOSDEM and would like to meet? | 10:12:16 |
 WeetHet | Why if there no command not found database in the nixpkgs-* tarballs only in the nixos-* ones? | 17:56:35 |
 K900 | Some stupid channel scripts thing | 18:03:10 |
| K900 | Didn't we drop it anyway | 18:03:17 |
| K900 | Please just use nix-index | 18:03:22 |
| 1 Feb 2026 |
| WeetHet | Erm, no? It's good enough if I don't want to pull in nix-index | 14:14:12 |
| WeetHet | Just because it is only included in tarballs and not on github doesn't make it a stupid channel thing | 14:14:39 |
|  Ducky changed their display name from mrdukydev to Ducky. | 23:10:59 |
| Ducky changed their profile picture. | 23:11:28 |
| Ducky changed their profile picture. | 23:14:54 |
| 2 Feb 2026 |
 Randy Eckenrode | aaaaaaaaaaaaah | 00:55:27 |
| Randy Eckenrode | I’ve been trying to make sure that Swift uses the real path to the stdlib when it sets the rpath. Apparently it’s mpv’s Meson that does that. | 00:55:57 |
| Randy Eckenrode | Blah | 00:55:58 |
| Randy Eckenrode | My code seems to work though. If you use the hidden -toolchain-stdlib-rpath argument, it resolves the rpath to the stdlib path of /nix/store/ss85ygcfnr99yjdk23li8v8s56ngvcl3-stdlib-6.2.3-dev/lib/swift/macosx. Which is wrong, but its heart is in the right place. | 00:58:29 |
| Randy Eckenrode | I patched the mpv derivation to use the right path. I’m going to punt on fixing the above until it affects the Linux build. | 03:13:49 |
| Randy Eckenrode | Before doing that, I want to revist the Swift package stuff. It’s too magic. I’m thinking now of just putting stuff in an attribute that you reference, so to set up SwiftPM, you add foo-package.sdist or something to buildInputs. | 03:14:47 |
| Randy Eckenrode | Is there any precedent for doing a vendor tarball as a derivation for each piece of the tarball? | 03:15:03 |
| Randy Eckenrode | I am also considering reintroducing fetchSwiftPMDeps or something to that effect. | 04:29:41 |
 debtquity | oooh, the swift compiler error is fixed, yay | 04:43:33 |
