| 26 Jul 2025 |
raitobezarius | given my time budget, i do not think the store solution will be implementable | 21:07:08 |
emily | I worry about things constantly getting slightly slower in ways nobody notices until it all adds up | 21:07:10 |
raitobezarius | we care about sandbox setup times | 21:07:18 |
raitobezarius | but i also need help to make this better | 21:07:33 |
raitobezarius | for example, I'm still seeking someone to package bencher.dev | 21:07:39 |
raitobezarius | if i had that, i would setup continuous benchmark infra | 21:07:47 |
raitobezarius | and we could pile up benchmark targets | 21:07:52 |
emily | FWIW, everything feels mysteriously slow on Darwin in ways that i suspect are trivial and dumb but that nobody has figured out | 21:08:02 |
emily | I forget if I mentioned Randy having compared build times inside a Nix build and out and the latter being way faster | 21:08:15 |
raitobezarius | this is very possible | 21:08:21 |
emily | unfortunately I may end up having to be that person | 21:08:32 |
raitobezarius | i'm happy to make myself available and answer questions and bounce ideas and look beyond the shoulder | 21:08:46 |
raitobezarius | but I think the Lix team has almost no available Darwin expertise these days | 21:08:55 |
emily | oh no Docker | 21:09:05 |
raitobezarius | In reply to @emilazy:matrix.org oh no Docker https://github.com/RaitoBezarius/bencher/blob/main/default.nix | 21:09:19 |
raitobezarius | it's almost done | 21:09:20 |
raitobezarius | just some pnpm & wasm garbage | 21:09:24 |
raitobezarius | but i cannot fix release blockers and do that at the same time [and the 26 bazillion of things] | 21:09:40 |
emily | the Emily team's Darwin expertise is also oversubscribed 😔 | 21:09:41 |
emily | much as I would like to put work in | 21:09:46 |
| 27 Jul 2025 |
aloisw | In reply to @raitobezarius:matrix.org realistically, how often CA certificates changes mid-builds? I think we specifically started copying it to prevent this from causing trouble? | 05:00:45 |
| Puna joined the room. | 06:59:20 |
gilice | Download console.patch | 10:10:18 |
gilice | hi, random guy chiming in here, I got the console output of your default.nix to build. here's a patch: | 10:10:22 |
Puna | Hi! I see there's a host_cpu variable in meson.build where some fixups are being done to turn Meson's cpu_family() results to values that Nixpkgs expects for system parsing. Is that variable actually wired up to anything invisibly, or is it just completely unused right now? I tried to add more fixups to it for POWER CPUs, but the system string stays wrong. Only if i change the host_system below it to actually use it do I get a correct system name printed. | 11:52:13 |
Qyriad | It determines the default builtins.currentSystem value Lix is compiled with, I believe | 11:53:17 |
Puna | I assume it should, but host_system is what's being used for that, and that just used cpu_family() | 11:54:20 |
Qyriad | Oh I see what you mean now | 11:54:40 |
Qyriad | that's a good question then, I'm not suredon' | 11:54:51 |
Qyriad | * that's a good question then, I'm not sure | 11:54:56 |