| 6 Oct 2025 |
 SomeoneSerge (back on matrix) |
acceptably fast
Not that I'm aware of.
Gaetan pointed to ci/eval/compare (would need adjustment) for a derivation-level solution.
I was thinking of building up on top of release-lib.nix.
This one eval-level flat list routine I'd describe as "painfully slow": https://github.com/SomeoneSerge/nixpkgs-cuda-ci/blob/abee609531807217495cd15e6ced14ad0dee5d18/nix/utils.nix#L73-L85
| 10:24:41 |
| SomeoneSerge (back on matrix) | *
acceptably fast
Not that I'm aware of.
Gaetan pointed to ci/eval/compare (would need adjustment) for a derivation-level solution.
I was thinking of building up on top of release-lib.nix.
This one eval-level flat list routine I'd describe as "painfully slow": https://github.com/SomeoneSerge/nixpkgs-cuda-ci/blob/abee609531807217495cd15e6ced14ad0dee5d18/nix/utils.nix#L73-L85. Probably could be made less sequential
| 10:25:22 |
 Daniel Fahey | Build fails with a simple CUTLASS bump https://github.com/NixOS/nixpkgs/pull/448965#issuecomment-3370979611
I suspect yours succeeded because you're using a cudaCapabilities with 8.9 only?
| 10:49:58 |
 lon | Yes, probably that ! | 11:20:56 |
 connor (he/him) | I made a faster diffing thing (but it requires a fair amount of memory): https://github.com/ConnorBaker/nix-nixpkgs-review | 14:33:23 |
| connor (he/him) | As an example:
nix build -L .#diffs.x86_64-linux.pkgs-pre-pkgs-cuda-pre --build-dir /run/temp-ramdisk --builders '' --override-input nixpkgs-pre github:NixOS/nixpkgs
will evaluate a copy of nixpkgs using the nixpkgs-pre input without CUDA enabled and with CUDA enabled, and then diff the results (each step happens in a separate derivation so there's caching)
It's IO and memory hungry though (IO because it's instantiating ~1.5 GB worth of derivations) and memory hungry because it's evaluating all of Nixpksg in a single pass
I've written it so it uses DetSys' parallel eval as well
| 14:39:10 |
| connor (he/him) | Here's the result of that command: https://gist.github.com/ConnorBaker/b1bbb3547d6c15921843ba0e048f94fd | 14:41:08 |
| connor (he/him) | When the evaluations of Nixpkgs instantiations are done in the derivations, the --eval-store argument is set to the evalStore output so we can keep the derivations around. The entries in the packages output of the flake are small wrapper scripts which run a nix build using the added and changed derivations -- the evalStore outputs are used as extra substituters so derivations are copied as needed into the store and we avoid doing evaluation again | 14:44:52 |
| connor (he/him) | Anyway, I built that because I didn't have a way to run nixpkgs-review with content-addressed derivations and got irritated that it kept evaluating the base commit of PRs that hadn't changed (all it needed to do was re-evaluate the head of the PR). | 14:48:28 |
| connor (he/him) | (Using the scripts in packages does require the read-only-local-store feature be enabled, since the evalStore outputs from the reports are just small instances of Nix stores which are inside the Nix store, so they do need to be mounted as read-only.) | 14:51:17 |
| connor (he/him) | But as an example, just with that diff output, if we change python312Packages and versioned package sets to their default, sort and deduplicate, that gives us massively better coverage of the packages which require CUDA that we can build (since allowBroken and allowInsecure are both still false) | 14:54:32 |
| SomeoneSerge (back on matrix) |
~1.5 GB worth of derivations)
LoL can we have evals run on a separate machine from the rest of hydra, and just do tmpfs store there xD
| 16:49:17 |
| SomeoneSerge (back on matrix) |
When the evaluations of Nixpkgs instantiations are done in the derivations, the --eval-store argument is set to the evalStore output so we can keep the derivations around
Cursed
| 16:51:37 |
| connor (he/him) | When I had done something like this a year ago I had to use recursive nix so this is an “improvement” in that it only requires the read-only store experimental feature, which is much more limited | 18:43:17 |
| connor (he/him) | I guess if you don’t mind re-evaluating everything there’s no need for evalStore since we could use an in-memory dummy store (probably wouldn’t need tmpfs build directory then either | 18:44:47 |
| connor (he/him) | * | 18:44:52 |
| SomeoneSerge (back on matrix) | Well the real issue here is that lol why physical realizations of aterm drvs in the first place | 19:44:03 |
