| 11 Mar 2025 |
 ruro | * I just wanted to make sure. You left this comment on the release-cuda issue:
H'm well it seems to make sense at least for
nix eval nixpkgs#cudaPackages.cudnn_8_0.brokenConditions
{ "CUDA version is too new" = true; ... }
Did I understand correctly, that you are okay with
- moving
cudnn.brokenConditions."CUDA version is too old/new" to badPlatformsConditions
- moving
nsight_systems.brokenConditions."CUDA too old (<11.8)" to badPlatformsConditions
- moving
nvidia_driver.brokenConditions."Package is not supported; use drivers from linuxPackages" to badPlatformsConditions
- setting
tensorrt.hydraPlatforms = none (because it can't be built on Hydra)
?
We can keep the Qt 5 missing (<2022.4.2.1)/Qt 6 missing (>=2022.4.2.1) as brokenConditions, because they aren't currently producing eval errors and it makes sense that we want to detect these conditions in CI.
As I've mentioned, you can see the exact changes I am talking about here.
| 19:25:54 |
| ruro | * I just wanted to make sure. You left this comment on the release-cuda issue:
H'm well it seems to make sense at least for
nix eval nixpkgs#cudaPackages.cudnn_8_0.brokenConditions
{ "CUDA version is too new" = true; ... }
Did I understand correctly, that you are okay with
- moving
cudnn.brokenConditions."CUDA version is too old/new" to badPlatformsConditions
- moving
nsight_systems.brokenConditions."CUDA too old (<11.8)" to badPlatformsConditions
- moving
nvidia_driver.brokenConditions."Package is not supported; use drivers from linuxPackages" to badPlatformsConditions
- setting
tensorrt.hydraPlatforms = none (because it can't be built on Hydra)
?
We can keep the Qt 5 missing (<2022.4.2.1)/Qt 6 missing (>=2022.4.2.1) as brokenConditions, because they aren't currently producing eval errors and it makes sense that we want to detect these conditions in CI.
You can see the exact changes I am talking about here.
| 19:26:07 |
| ruro | * I just wanted to make sure. You left this comment on the release-cuda issue:
change brokenConditions to badPlatformsConditions
H'm well it seems to make sense at least for
nix eval nixpkgs#cudaPackages.cudnn_8_0.brokenConditions
{ "CUDA version is too new" = true; ... }
Did I understand correctly, that you are okay with
- moving
cudnn.brokenConditions."CUDA version is too old/new" to badPlatformsConditions
- moving
nsight_systems.brokenConditions."CUDA too old (<11.8)" to badPlatformsConditions
- moving
nvidia_driver.brokenConditions."Package is not supported; use drivers from linuxPackages" to badPlatformsConditions
- setting
tensorrt.hydraPlatforms = none (because it can't be built on Hydra)
?
We can keep the Qt 5 missing (<2022.4.2.1)/Qt 6 missing (>=2022.4.2.1) as brokenConditions, because they aren't currently producing eval errors and it makes sense that we want to detect these conditions in CI.
You can see the exact changes I am talking about here.
| 19:28:07 |
| ruro | * I just wanted to make sure. You left this comment on the release-cuda issue:
change brokenConditions to badPlatformsConditions
H'm well it seems to make sense at least for
nix eval nixpkgs#cudaPackages.cudnn_8_0.brokenConditions
{ "CUDA version is too new" = true; ... }
Did I understand correctly, that you are okay with
- moving
cudnn.brokenConditions."CUDA version is too old/new" to badPlatformsConditions
- moving
nsight_systems.brokenConditions."CUDA too old (<11.8)" to badPlatformsConditions
- moving
nvidia_driver.brokenConditions."Package is not supported; use drivers from linuxPackages" to badPlatformsConditions
- setting
tensorrt.hydraPlatforms = none (because it can't be built on Hydra)
?
You can see the exact changes I am talking about here.
We can keep the Qt 5 missing (<2022.4.2.1) / Qt 6 missing (>=2022.4.2.1) as brokenConditions, because they aren't currently producing eval errors and it makes sense that we want to detect these conditions in CI.
| 19:28:36 |
 SomeoneSerge (matrix works sometimes) | ruro: this sounds great! | 22:02:03 |
|  Adam Neverwas removed their display name adam_neverwas. | 23:24:15 |
|  gumby0811 set a profile picture. | 23:38:53 |
| 12 Mar 2025 |
| ruro | Any preferences on the alternative name for evalPackageSetPlatforms? ))) | 00:42:04 |
| ruro | I am leaning towards packageSetPlatforms... | 00:42:18 |
| ruro | * I am leaning towards just packageSetPlatforms... | 00:42:32 |
| SomeoneSerge (matrix works sometimes) | stick: I was going through the missed notifications today and saw a whole bunch of merged cuda-related fixes and refactorings. That was nice:) | 00:43:02 |
| SomeoneSerge (matrix works sometimes) | Well, looking at the file again, we have packageSets, so the platforms are also of multiple package set<b>s</b>, but that's inconvenient to type, so maybe psPlatforms? | 00:51:57 |
| SomeoneSerge (matrix works sometimes) | And comparing to pkgs/top-level/release.nix they introduce packageJobs, but then just use the in-place map for pkgs | 00:52:26 |
| ruro | Maybe packagePlatforms then? I mean... the attrset specifies the platforms for each package, not for each package set. | 00:54:15 |
| ruro | * Maybe packagePlatforms then? I mean... this attrset specifies the platforms for each package, not for each package set. | 00:54:23 |
| ruro | It's a bit unfortunate that packagePlatforms is a function in pkgs/top-level/release.nix, but eh... | 00:56:23 |
| ruro | Nvm | 00:56:47 |
| ruro | It's also a function inherited from release-lib | 00:57:04 |
| ruro | * packagePlatforms is also a function inherited from release-lib | 00:57:19 |
| SomeoneSerge (matrix works sometimes) | well, platforms for entire sets of packages, and the reason that stuff is in a separate variable is because individual packages are handled differently | 00:57:32 |
| ruro | Yeah... | 00:57:50 |
| ruro | Damn, naming things is hard | 00:58:00 |
| ruro | platformsForPackageSets? | 00:58:36 |
| SomeoneSerge (matrix works sometimes) | Sure. Or... just keep the function application without a name xD | 00:59:21 |
| ruro | Or alternatively, we could rename packageSets to cudaPackageSets and then rename evalPackageSetPlatforms to cudaPackagePlatforms. | 00:59:21 |
| SomeoneSerge (matrix works sometimes) | I guess the thought was we might start being less picky and start adding either subscopes?.. | 01:01:12 |
| ruro | On one hand this isn't very future proof because of potential future rocm and mkl support. On the other hand, the file is already called release-cuda, not release-unfree or something | 01:01:15 |
| SomeoneSerge (matrix works sometimes) | Oh! I think I know why it was ${pset} = ... | 01:01:30 |
| SomeoneSerge (matrix works sometimes) | Uhm no nevermind still doesn't make sense | 01:03:57 |
| ruro | Or maybe s/packageSets/recursivePackages/g and s/evalPackageSetPlatforms/recursivePackagePlatforms/g... | 01:06:25 |
