I have bad news, lol

sha=a1e849ff441fa1315afa27e1fd18c791f61de06b
for cuda_ver in 11_0 11_1 11_2 11_3 11_4 11_5 11_6 11_7 11_8 12_0 12_1 12_2 12_3; do
    echo $cuda_ver;
    NIXPKGS_ALLOW_UNFREE=1 NIXPKGS_ALLOW_INSECURE=1 nix build \
        --no-link --print-out-paths --impure \
        "github:NixOS/nixpkgs/$sha#cudaPackages_${cuda_ver}.cuda-samples" \
        >${cuda_ver}.stdout 2>${cuda_ver}.stderr
    echo $? > ${cuda_ver}.exit
done

All cudaPackages*.cuda-samples builds are currently failing for various reasons:

• error: expected initializer before '__s128' in include/linux/types.h:12:27 for CUDA versions 11.0 - 11.3
• cannot find -lcudadevrt: No such file or directory and -lcudart_static for CUDA versions 11.4 - 12.3

I have bad news, lol

sha=a1e849ff441fa1315afa27e1fd18c791f61de06b
for cuda_ver in 11_0 11_1 11_2 11_3 11_4 11_5 11_6 11_7 11_8 12_0 12_1 12_2 12_3; do
    echo $cuda_ver;
    NIXPKGS_ALLOW_UNFREE=1 NIXPKGS_ALLOW_INSECURE=1 nix build \
        --no-link --print-out-paths --impure \
        "github:NixOS/nixpkgs/${sha}#cudaPackages_${cuda_ver}.cuda-samples" \
        >${cuda_ver}.stdout 2>${cuda_ver}.stderr
    echo $? > ${cuda_ver}.exit
done

All cudaPackages*.cuda-samples builds are currently failing for various reasons:

• error: expected initializer before '__s128' in include/linux/types.h:12:27 for CUDA versions 11.0 - 11.3
• cannot find -lcudadevrt: No such file or directory and -lcudart_static for CUDA versions 11.4 - 12.3

This might be a stupid question, but when the nixpkgs manual says

All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit
does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs.

What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).

This might be a stupid question, but when the nixpkgs manual says

All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit

does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs.

What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).

This might be a stupid question, but when the nixpkgs manual says

All new projects should use the CUDA redistributables available in cudaPackages in place of cudaPackages.cudatoolkit

does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs?

What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required binaries/libraries under a single path, but I am not sure if this is the most elegant way to do this (also, it's not immediately clear, how would a single CUDA_PATH interact with cross compilation).

What if the upstream package expects a single CUDA_PATH path containing all the cuda dependencies? I think, I saw some people using buildEnv to collect all of the required

If upstream is co-operative, they need to be contacted and offered a proper solution like FindCUDAToolkit.cmake without any CUDA_PATHs or merged-layout assumptiosn

does it mean that individual derivations from cudaPackages.* should be manually added to buildInputs/nativeBuildInputs. For example, would this mean that I should just manually add cuda_nvcc to nativeBuildInputs?

That's the idea. We could consider an automation more along the lines of propagatedBuildInputs, but symlinks we hope to avoid, because it's hard to prune the references to static libraries after the build

4s
Run # Get the latest eval.yml workflow run for the PR's target commit
Comparing against "https://github.com/NixOS/nixpkgs/actions/runs/13155928895"
Workflow was not successful (conclusion: failure), cannot make comparison

Has anyone encountered this? I've no idea what this workflow is even for