| 6 Feb 2025 |
 ruro | * 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 upstreamboxx 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 #173463truecrack-cuda is "actually" broken since #167250pymc depends on pytensor is "actually" broken since #373239
| 06:57:34 |
| ruro | * 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
| 06:57:53 |
| ruro | * 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
| 07:00:28 |
 SomeoneSerge (matrix works sometimes) | 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
| 09:30:54 |
| SomeoneSerge (matrix works sometimes) | Btw, at some point this list was used to build with allowUnfree = true instead of the more conservative allowUnfreePredicate we currently use | 09:32:13 |
| ruro | Alternatively/additionally, we might want to mark torch-bin with the appropriate CUDA-specific license so that it passes the allowUnfreePredicate in release-cuda (assuming that the unfreeRedistributable part of torch-bin does indeed refer to the vendored(?) CUDA. | 13:07:01 |
