| 3 Feb 2025 |
hexa | it is in the current staging cycle | 23:58:18 |
hexa | and it is causing all sort of havoc | 23:58:27 |
hexa | because no fixes were prepared in advance | 23:58:38 |
| 4 Feb 2025 |
connor (he/him) | I apologize, I should have made sure at least stdenvs for {x86_64,aarch64}-{darwin,linux} were working In the case of rebuild-the-world PRs, I'm not sure what is considered sufficient in terms of testing -- is there particular language (or Nix expressions) you'd want to see in the contributing guidelines? | 05:07:55 |
SomeoneSerge (back on matrix) | Oh nice! | 09:46:24 |
SomeoneSerge (back on matrix) | Found it | 09:46:27 |
| afdee1c joined the room. | 20:04:25 |
zopieux | I'm a bit confused about the nix-community cache and I wonder if my system/config is to blame, or the cache. This cuda build succeeded and depends on nixpkgs d0bb46, which I pinned in my flake. Upon building though, nix decides to build fmpz8s6hy3yr8z6kb84h6498437d0xj1-ollama-0.5.7.drv even though per the above and per https://nix-community.cachix.org/8njyvpf8sxh8k61zvnv13cymn7szv63c.narinfo, the output should be available in the cache. nix.conf confirms the substituter/pubkey is present. Am I missing something? | 21:03:07 |
connor (he/him) | I haven't followed too closely how the community Hydra builds cudaPackages, but the first thing that comes to my mind is that perhaps your config.cudaCapabilities doesn't match the default set selected when it's unset? (By default, we build for a number of capabilities.) | 22:28:12 |
| 5 Feb 2025 |
SomeoneSerge (back on matrix) | No, fmpz8s6hy3yr8z6kb84h6498437d0xj1 is the deriver of 8njyvpf8sxh8k61zvnv13cymn7szv63c.narinfo, and cachix knows about it, and if you try wget https://nix-community.cachix.org/nar/77cdeba29947cabc7c880df05f41200e0f9ee711651931ac046e64fcfd52f48b.nar.zst it actually begins to download the blob so it's not GCed | 00:38:31 |
SomeoneSerge (back on matrix) | So Nix does behave weird here? zopieux what's it say if --builders "" -j0? | 00:39:30 |
ruro | Regarding "broken javascript", you can see eval failures on the "Evaluation Errors" tab of the nixpkgs:cuda jobset (but not on individual job pages, not sure why). | 21:37:53 |
| 6 Feb 2025 |
ruro | Here's my attempt at a PR that fixes a bunch of Eval Errors that I've outlined earlier: https://github.com/NixOS/nixpkgs/pull/379768 | 06:38:45 |
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 = [ ]; }
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:56:17 |
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: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 (back on matrix) | 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 (back on matrix) | 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 |
ruro | I am not sure if I like the idea of adding freeimage to allowInsecurePredicate "globally" in release-cuda, as the eval failure is a useful indicator for when some package ends up depending on it. I was thinking of allowing freeimage specifically for cuda-samples. Also, it seems that cuda-samples is only present in CUDA versions <=12.3 for some reason. I wonder, why is that? | 13:18:26 |
| stick joined the room. | 14:20:42 |
stick | Hi team!
I recently managed to update vllm to latest version - https://github.com/NixOS/nixpkgs/pull/379165
I think we should add vllm to release-cuda because it takes long time to compile and it would be great if the nix-community cache was populated with the prebuilt binaries.
What do you think?
I created a PR with the change here: https://github.com/NixOS/nixpkgs/pull/379575 | 14:21:45 |
| stick left the room. | 14:25:25 |
| stick joined the room. | 14:26:27 |
| stick left the room. | 14:27:08 |
| stick joined the room. | 14:29:45 |
ruro | 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
| 14:40:48 |
ruro | * 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
| 14:48:11 |
ruro | * I am not sure if I like the idea of adding freeimage to allowInsecurePredicate "globally" in release-cuda, as the eval failure is a useful indicator for when some package ends up depending on it. I was thinking of allowing freeimage specifically for cuda-samples. Also, it seems that cuda-samples is not present for CUDA 12.4 for some reason. I wonder, why is that? | 14:53:29 |