| 11 Mar 2025 |
 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | 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 (back on matrix) | Oh! I think I know why it was ${pset} = ... | 01:01:30 |
| SomeoneSerge (back on matrix) | 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 |
| SomeoneSerge (back on matrix) | Oh! I didn't do it! xD | 01:08:11 |
| SomeoneSerge (back on matrix) | Git blame shows this was inherited from Frederik's refactoring | 01:08:46 |
| SomeoneSerge (back on matrix) |
recursivePackages
Right now the difference isn't just that it's "recursive" but also that we filter out the unsupported platforms, which we don't do for the packageJobs Can't say this was originally intended but you found a use for that 🤷
| 01:11:28 |
