| 11 Sep 2025 |
 Tristan Ross | From what I recall, it was something to do with having a legal entity in the US. If the foundation was registered in the US, then it would've been fine. This has been going on since at least Planet Nix, glad to see it finally pull through. | 00:03:41 |
|  @ihar.hrachyshka:matrix.org joined the room. | 00:09:51 |
 connor (he/him) | Will try to take a look later | 00:10:55 |
| connor (he/him) | You’d probably need to override writeGpuTestPython to use the Python package set you specify. It’s inside cudaPackages so it has no way of knowing what scope you’re using it in. | 00:12:26 |
| connor (he/him) | They’re still mostly okay; I’ve been exhausted recently so haven’t been awake too early (I was up at 3am this morning but that’s something else)
If we can do something closer to 8 that might be easier; Kevin Mittman how are you with morning meetings? It’d be good to catch up and discuss what’s been done so far with the database project Serge’s been working on. | 00:14:16 |
| connor (he/him) | NVIDIA’s EULA effectively prohibits running CUDA binaries they release on non-NVIDIA hardware (see 1.2.8: https://docs.nvidia.com/cuda/eula/index.html#limitations) | 00:20:07 |
 Kevin Mittman (UTC-7) | https://developer.nvidia.com/blog/developers-can-now-get-cuda-directly-from-their-favorite-third-party-platforms/ | 01:17:14 |
 SomeoneSerge (back on matrix) | The fact remains: it was amd who shut it down, not nvidia? | 01:26:18 |
| SomeoneSerge (back on matrix) | nvidia playing the "please submit this in paper by post, and attach proofs of your residence such as electricity bills delivered to your address" game (being the bureaucrat and coming up with arbitrary terms as they go) | 01:30:19 |
| SomeoneSerge (back on matrix) | ah yeah, true | 01:33:21 |
 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 (back on matrix) | Ah nice | 14:18:25 |
| SomeoneSerge (back on matrix) | 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 (back on matrix) | Offtopic but does the original Nix commit not change old nixlang expressions' drvPaths? | 14:40:50 |
| SomeoneSerge (back on matrix) | 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 |
| 13 Sep 2025 |
|  ysndr joined the room. | 00:58:03 |
|  oak 🏳️🌈♥️ changed their profile picture. | 09:46:03 |
| 14 Sep 2025 |
|  @emma:rory.gay joined the room. | 08:39:56 |
| connor (he/him) | Duncan Gammiethanks for the PR! I’ll try to review it soon, things have just been | 18:22:54 |
| 15 Sep 2025 |
| connor (he/him) | Gaétan Lepage: as someone who has contributed to nixpkgs-review previously, how difficult do you think it would be to add functionality which tells you if packages were broken on the base commit? As an example, working on foundational CUDA packaging changes the store output paths of basically everything which relies (transitively) on CUDA. That includes a whole bunch of Python packages which are just usually broken but we're unaware of.
I'd like to be able to run nixpkgs-review and have it tell me, in addition to the number of packages which failed to build as a result of the PR, which ones were already broken on the base commit.
Would that involve a secondary stage of builds wherein all the packages which failed to build and already exist on the base commit are tried? | 02:57:42 |
| Gaétan Lepage | This would be an amazingly useful feature. Every maintainer is facing the same issue all the time.
I have certainly already thought about it.
However, this is not too simple. At least, we cannot induce this information from the raw information we have.
nixpkgs-review currently works like this:
- Compute (or fetch) which outPaths have been changed between the base commit and the new one. -> Deduct the set of packages that need to be rebuilt.
- Rebuild those (which are not marked as broken/unsupported) and report the successes/failures.
There is no notion of previous brokenness in what nixpkgs-review knows.
What would be a solution, would be to fetch hydra and gather the latest status of each target package. This would be the easiest way to do it. | 09:52:30 |
| connor (he/him) | Rather than querying Hydra, do you think it would be enough to query all the substitutes the system has configured to see if it’s already cached (indicating success)? That way if it’s something the user has already built on a different machine or has in a different cache, that would be searched. | 14:55:32 |
| connor (he/him) | Lastly, I was looking at the way the list of attributes are generated yesterday. I think I can greatly speed that up and have us benefit from caching.
For example, I was working on an eval-devs CLI addition for Nix based on the parallel evaluator Eelco was working on which also uses the evaluation cache. The idea being that all the evaluation happens in parallel, and the results are cached in the evaluation cache, so if you’re working on your PR and running nixpkgs-review multiple times as you fix things, so long as you keep the same base commit (and use —merge commit or whatever the flag is for nixpkgs-review) you can re-use the evaluation you’ve already compute for the base every time you re-run the review. | 14:58:35 |
| connor (he/him) | Of course, that’s using DetSys Nix, so I’d probably just keep that in my fork to see if it’s worthwhile, but 🤷♂️ | 14:59:22 |
| connor (he/him) | I have so many other un-fun things I have to do 😖 | 15:00:14 |
