Regarding the remaining 21 eval errors:

• 13x cuda-samples depends on freeimage which is technically insecure. I am not 100% sure, if we should just filter all of the cuda-samples packages using the new filterPackagePredicates mechanism or if it might be better to do

  freeimage.overrideAttrs { meta.knownVulnerabilities = [ ]; }
  

  specifically for cuda-samples. Since cuda-samples isn't really "production-facing" anyway, so the users should only really care that the samples compile. The security risk of distributing sample code that technically has some vulnerabilities should be minimal.

• colmap also depends on freeimage, this issue should be probably raised upstream

• boxx and bpycv haven't been updated upstream in the last 11 months and they seem to not support any of the python versions that are currently supported in nixpkgs. So we should probably check in with the nixpkgs maintainer and remove these packages if they aren't required by something important.

• pixinsight is (and always was) unfree, but it is explicitly listed in release-cuda.nix for some reason. Should it be removed?

• tts because it depends on a -bin version of pytorch for some reason, which is "unfree" (bsd3 issl unfreeRedistributable). Is it possible to make it depend on a non-binary version of pytorch or should it be removed from release-cuda.nix?

• mxnet is "actually" broken since #173463

• truecrack-cuda is "actually" broken since #167250

• pymc depends on pytensor is "actually" broken since #373239

Regarding the remaining 21 eval errors:

• 13x cuda-samples depends on freeimage which is technically insecure. I am not 100% sure, if we should just filter all of the cuda-samples packages using the new filterPackagePredicates mechanism or if it might be better to do

  freeimage.overrideAttrs { meta.knownVulnerabilities = [ ]; }
  

  specifically for cuda-samples. Since cuda-samples isn't really "production-facing" anyway, so the users should only really care that the samples compile. The security risk of distributing sample code that technically has some vulnerabilities should be minimal.

• colmap also depends on freeimage, this issue should be probably raised upstream

• boxx and bpycv haven't been updated upstream in the last 11 months and they seem to not support any of the python versions that are currently supported in nixpkgs. So we should probably check in with the nixpkgs maintainer and remove these packages if they aren't required by something important.

• pixinsight is (and always was) unfree, but it is explicitly listed in release-cuda.nix for some reason. Should it be removed?

• tts because it depends on a -bin version of pytorch for some reason, which is "unfree" (bsd3 issl unfreeRedistributable). Is it possible to make it depend on a non-binary version of pytorch or should it be removed from release-cuda.nix?

• mxnet is "actually" broken since #173463

• truecrack-cuda is "actually" broken since #167250

• pymc depends on pytensor is "actually" broken since #373239

Thanks for the summary!

tts because it depends on a -bin version of pytorch for some reason, which is "unfree" (bsd3 issl unfreeRedistributable). Is it possible to make it depend on a non-binary version of pytorch or should it be removed from release-cuda.nix?

Definitely shouldn't be removed, tts is a package we want maintained, and when it's broken we want to see it's broken. It was probably made to use torch-bin at some point when source build was broken? If we can move it to torch, we probably should.

colmap also depends on freeimage, this issue should be probably raised upstream

Indeed

13x cuda-samples depends on freeimage which is technically insecure. I am not 100% sure, if we should just filter all of the cuda-samples packages using ...

For the Hydra job we might as well allow the insecure freeimage? It's ok to test and cache it, we just don't want people to copy the allowInsecurePredicate configuration

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