| 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 (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 |
SomeoneSerge (matrix works sometimes) | Oh! I didn't do it! xD | 01:08:11 |
SomeoneSerge (matrix works sometimes) | Git blame shows this was inherited from Frederik's refactoring | 01:08:46 |
SomeoneSerge (matrix works sometimes) |
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 |