| 11 Sep 2025 |
 Gaétan Lepage | When is the next one? I'll try to join | 10:16:38 |
 le-chat | I've updated the gist with the latest version, it seems to compile and run a pipeline with tensor_filter framework=pytorch accelerator=true:gpu ... ! fakesink, but I haven't got a time to check it really. | 10:45:16 |
| 12 Sep 2025 |
 connor (he/him) | Ugh | 14:02:04 |
| connor (he/him) | https://github.com/NixOS/nixpkgs/issues/442378 | 14:02:06 |
 SomeoneSerge (matrix works sometimes) | Ah nice | 14:18:25 |
| SomeoneSerge (matrix works sometimes) | Let's start adding special branches for nix semvers and for lix | 14:18:38 |
| connor (he/him) | https://github.com/NixOS/nixpkgs/pull/442389 | 14:25:03 |
| SomeoneSerge (matrix works sometimes) | Offtopic but does the original Nix commit not change old nixlang expressions' drvPaths? | 14:40:50 |
| SomeoneSerge (matrix works sometimes) | Ahhh I see, the ATerm repr is still the same | 14:45:15 |
| connor (he/him) | Okay what should nix-community/cuda-legacy look or be structured like? As an example: supporting CUDA 11. NCCL has already cut its last release supporting CUDA 11, so we need a package expression for that in the repo. Then there’s PyTorch: if that’s already cut its last release supporting CUDA 11, we need an expression for that as well. In the case of packages with many dependencies, like PyTorch, I’m not sure how long we’d be able to use upstream to provide dependencies, even if we vendor the package expression in tree, because eventually they’ll get bumped to something too new for the version of the package we’re locked to.
Is it viable for cuda-legacy to just re-expose a copy of Nixpkgs fixed to some point in time? I would think not (at least naively) without a way to deduplicate the number of Nixpkgs instantiated (e.g., providing cuda-legacy as an overlay and having it draw relevant packages from a fixed version of Nixpkgs while somehow using the most of the underlying instance of Nixpkgs). | 19:54:54 |
