| 17 Sep 2025 |
 raitobezarius (DECT: 7248) | I can help someone deploying one, I cannot take care of this until mid-October with the current load on my plate | 19:05:14 |
 piegames | waiting a month works for me tbh, I won't be doing much Lix in the meantime either | 20:26:04 |
| piegames | thank you for taking care of this | 20:26:41 |
 Winter | is flokli's still basically the best one? | 20:27:35 |
 lillecarl | Ive been looking into building a time based GC, I built a nix-touch command that updates regtime for a storepath and it's dependencies (and optionally build time deps). Next I'm building a nix-gctime (or something) which will just try to remove any storepaths older than $time regtime (using nix subprocess so I don't have to implement liveness checking).
I just wanted to check in and see if either of you guys have thought of this and why it's a bad idea, it feels so stupid redownloading sources and build-time deps from 10 minutes ago because I ran GC. | 20:37:40 |
| lillecarl | --delete-older-than from nix-collect-garbage only kills old gcroots if I understand correctly and doesn't care about regtime when it's time to collect garbage | 20:40:23 |
| lillecarl | (This came up when building a nix-snapshotter clone but on the CSI layer rather than CRI) | 20:41:58 |
 emily | https://github.com/risicle/nix-heuristic-gc but requires atime | 20:46:24 |
| emily | it sounds like you want keep-derivations and keep-outputs mainly thougj | 20:47:01 |
| lillecarl | In reply to @emilazy:matrix.org
it sounds like you want keep-derivations and keep-outputs mainly thougj That's good-enough to start, but it'd keep build deps for all gcroots right?
I'll continue the 3rd party GC impl, it's really just a couple of SQLite statements and some subprocessing :) | 20:56:02 |
| lillecarl | * That's good-enough to start, but it'd keep build deps for all gcroots right?
I'll continue the 3rd party GC impl, it's really just a couple of SQLite statements and some subprocessing :)
Edit: wouldn't wanna rely on atime though :p
| 20:57:07 |
| emily | yes, but I mean it beats losing stuff unless you're low on disk | 20:58:21 |
| emily | and Nix with low disk space is misery | 20:58:44 |
| lillecarl | Agreed 😁 Thanks for the feedback | 21:03:41 |
| 18 Sep 2025 |
 K900 | Feel like I must have asked this before | 06:54:35 |
| K900 | But has anyone looked into what it would take to make negative/fractional speedfactor a thing | 06:54:50 |
|  silent_water joined the room. | 14:43:35 |
| raitobezarius (DECT: 7248) | I think so | 15:00:59 |
| raitobezarius (DECT: 7248) | And flokli just archived it because he's not using it | 15:01:04 |
 Sergei Zimmerman (xokdvium) | Does Lix want a port of https://github.com/NixOS/nix/pull/13987? | 17:32:02 |
| raitobezarius (DECT: 7248) | Would be glad yes :) | 17:54:22 |
 aloisw | emily (@emilazy:matrix.org) what is going on with the toml11 bump? I wasn't subscribed to the latest PR and now it looks to have been merged… into staging? | 18:36:01 |
| emily | yes, it rebuilds all NixOS tests for obvious reasons | 18:36:33 |
| emily | and we need it only in tandem with CMake 4 which is about to land in staging | 18:36:41 |
| emily | so putting it there to avoid unnecessary test rebuilds | 18:36:48 |
| emily | (otherwise it'd need catching the kernel updates train or something which didn't feel necessary) | 18:36:57 |
| emily | I guess the Lix Git bump would have to target staging too then, though. but we're about to start the staging-next cycle, so not too bad, hopefully? | 18:37:23 |
| emily | (well, "obvious". most tests probably shouldn't depend on Nix. but anyway.) | 18:37:37 |
| aloisw | I'll probably update the patch to support both and drop it on unstable on the next update after staging-next merge. | 18:38:02 |
| emily | ok, that works. sorry for the churn, didn't think the couple week's delay would be a big deal | 18:39:04 |
