cudaPackages_{11,12_0,12_1,12_2,12_3,12_4,12_5}: drop#434827
cudaPackages_{11,12_0,12_1,12_2,12_3,12_4,12_5}: drop#434827ConnorBaker merged 14 commits intoNixOS:masterfrom
Conversation
b35e0c3 to
804aab7
Compare
|
Looks like |
804aab7 to
c6c85ae
Compare
|
Yes, we have switched to the binary wheels for |
|
But you pointed |
Before libtensorflow = python3.pkgs.tensorflow.libtensorflow;so I explicitly changed this instance of |
|
Fair enough. I see some |
Anyway, all good regarding this PR :) |
|
I mean |
with this PR cupy fails because libcutensor is broken: |
e5026cc to
348dce4
Compare
|
with changes in 348dce4 both |
|
Yes, sorry about that; I messed up removing the obsolete version conditionals. I tried to verify that the derivation hash of Perhaps |
|
NVIDIA does still ship the runfile installer, but I’ll try running another nixpkgs-review later today. |
|
|
348dce4 to
044be1f
Compare
|
(Dropped a few more obsolete constituent package versions and out‐of-tree conditions as a result of looking into that.) |
EOL and out of security support for over half a year; only used by outdated TensorFlow source builds. Since we use `tensorflow-bin` by default now and CUDA 11 and GCC 12 are both being removed, I think it’s okay to mark these broken until updates can be finished and merged.
Only used by the broken TensorFlow source build.
044be1f to
5e733d7
Compare
I think we should do this (not necessarily part of this PR). There is nothing in nixpkgs that depends on it and keeping this makes cuda updates more work (because one has to download the huge runfile and compute a hash to put it in +1 for keeping |
|
Yeah, it sounds good to drop. But I’ll leave that to you guys :) |
|
|
Thank you again for taking this on, @emilazy! |
|
Anything for a diffstat this negative 😆 Seriously though, thanks for the quick and thorough review! I will probably ping CUDA maintainers ahead of time to handle compilers due for removal in future, as it should hopefully be a much more mundane task when done incrementally than when it’s catching up on years of backlog like this. |
|
cudatoolkit-legacy-runfile drop PR in #436150 |
|
If that’s unrealistic the TODO should probably be softened.
It'll become realistic sooner rather than later!
https://github.com/user-attachments/assets/ea4566f0-9b1e-4a99-9126-3d8a8e9bea46
…On August 22, 2025 2:44:47 PM UTC, Emily ***@***.***> wrote:
emilazy left a comment (NixOS/nixpkgs#434827)
`cudatoolkit` itself works fine; there’s just a TODO above it saying that it should be dropped once everything in‐tree has been migrated to split‐out packages. If that’s unrealistic the TODO should probably be softened.
|
Belatedly aligning the CUDA versions we ship with the compilers we expect to take into 25.11, after #342112.
cc @GaetanLepage – do you remember why you explicitly pinned
libtensorflowto use the source build in #345658?cc @de11n for DCGM again.
Things done
aarch64-linux)passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.Add a 👍 reaction to pull requests you find important.