Error in fail: Repository command failed
No library found under: /nix/store/iq5b0g0md105dsw3zkw07lasaghsy0wq-cudatoolkit-12.0.1-merged/lib/libcupti.so.12.0
ERROR: /build/source/WORKSPACE:15:14: fetching cuda_configure rule //external:local_config_cuda: Traceback (most recent call last)
❯ ldd /nix/store/iq5b0g0md105dsw3zkw07lasaghsy0wq-cudatoolkit-12.0.1-merged/lib/libcupti.so.12.0
ldd: /nix/store/iq5b0g0md105dsw3zkw07lasaghsy0wq-cudatoolkit-12.0.1-merged/lib/libcupti.so.12.0: No such file or directory

In reply to @hexa:lossy.network
we probably need https://github.com/numba/numba/pull/8691

Presently CI will fail due to the lack of NumPy 1.24 packages in Anaconda, but this should be resolved in time.
...
I think all review comments are now addressed and this is just waiting on package availability so as to complete testing.

What the actual fuck, they won't just relax pinned versions?

In reply to @justbrowsing:matrix.org

which presents some questions 

• how are these software releases typically noticed - organically? when something depends on it?
• what sort of translation would be hypothetically needed to convert this or a similar manifest into something automation could pick up
• normally how are changes discovered such as added, removed, renamed, or split components? if this was in the json would that be helpful?

Word of warning, I haven't been working on this too long but here's what I've noticed. All, please feel free to correct if any of this is wrong.

how are these software releases typically noticed - organically? when something depends on it?

I believe it's organic -- outside of https://github.com/ryantm/nixpkgs-update I'm not sure what exists in the way of automation for updating nixpkgs.

what sort of translation would be hypothetically needed to convert this or a similar manifest into something automation could pick up

Given the switch to redistributables and Nix parsing JSON we grab from NVIDIA's website, maybe it'd be easier to automate it now! I could imagine a script which curls their index to see what the latest is, and adds a new copy of the JSON files we need if there's a newer version.

normally how are changes discovered such as added, removed, renamed, or split components? if this was in the json would that be helpful?

I think we find out about it either from breakages or reading the release notes/JSON.

Kevin Mittman I like these questions -- can I add them to the docs tracking issue I have here? https://github.com/NixOS/nixpkgs/issues/217780

In reply to @ss:someonex.net

Personally, I'd prefer that there was only one arch in there by default.

Alt: default to cudaCapabilities = [ "5.0" ] (with PTX); probably cuda works by default for everyone; it's maybe mysteriously slow and people don't know to override the config
Alt: default to cudaCapabilities = [ "8.6" ]; works for DL users, throws an error for lower grade cards, maybe people find out they need to override the config, but maybe they don't and end up feeling overwhelmed with nixpkgs

With respect to specifying capabilities -- some packages (glares at magma) don't support every capability: https://github.com/NixOS/nixpkgs/pull/217410/files#diff-1e7812b78446dca0e64c4bb933e9255fca6f6539ec1ecd610edf1285a3fcbc56R55

Like, the hell? Skipping 8.6, 8.7, and 8.9? Packages like that make me think we need some way for the coda configuration and derivation to interact to agree on a list of architectures to build for. Imaging setting cudaCapabilities = [ "8.6" ]; and getting failures because, while some packages support Ampere, they don't support that capability by name. That'd be annoying right?

Or maybe that's desirable? Maybe it would be more annoying if the package used the greatest common factor (say, 8.0 when 8.6 was requested) and no errors were thrown? Is that misleading the user?

In reply to @connorbaker:matrix.org

Word of warning, I haven't been working on this too long but here's what I've noticed. All, please feel free to correct if any of this is wrong.

how are these software releases typically noticed - organically? when something depends on it?

I believe it's organic -- outside of https://github.com/ryantm/nixpkgs-update I'm not sure what exists in the way of automation for updating nixpkgs.

what sort of translation would be hypothetically needed to convert this or a similar manifest into something automation could pick up

Given the switch to redistributables and Nix parsing JSON we grab from NVIDIA's website, maybe it'd be easier to automate it now! I could imagine a script which curls their index to see what the latest is, and adds a new copy of the JSON files we need if there's a newer version.

normally how are changes discovered such as added, removed, renamed, or split components? if this was in the json would that be helpful?

I think we find out about it either from breakages or reading the release notes/JSON.

Kevin Mittman I like these questions -- can I add them to the docs tracking issue I have here? https://github.com/NixOS/nixpkgs/issues/217780

In reply to @justbrowsing:matrix.org

FYI, CUDA 12.1.0 is now available 

https://developer.download.nvidia.com/compute/cuda/redist/redistrib_12.1.0.json 

Given the switch to redistributables and Nix parsing JSON we grab from NVIDIA's website, maybe it'd be easier to automate it now! I could imagine a script which curls their index to see what the latest is, and adds a new copy of the JSON files we need if there's a newer version.

Been thinking that too. Not even automated PRs, but we could improve visiblity by just making a github workflow that runs on cron schedule, checks published JSONs, and publishes a status report on github pages

In reply to @justbrowsing:matrix.org
is that the nix equivalent of portage's emerge world after changing USE flags?

In reply to @FRidh:matrix.org
Yes, I think this was based on https://github.com/NixOS/rfcs/pull/3

In reply to @connorbaker:matrix.org

With respect to specifying capabilities -- some packages (glares at magma) don't support every capability: https://github.com/NixOS/nixpkgs/pull/217410/files#diff-1e7812b78446dca0e64c4bb933e9255fca6f6539ec1ecd610edf1285a3fcbc56R55

Like, the hell? Skipping 8.6, 8.7, and 8.9? Packages like that make me think we need some way for the coda configuration and derivation to interact to agree on a list of architectures to build for. Imaging setting cudaCapabilities = [ "8.6" ]; and getting failures because, while some packages support Ampere, they don't support that capability by name. That'd be annoying right?

Or maybe that's desirable? Maybe it would be more annoying if the package used the greatest common factor (say, 8.0 when 8.6 was requested) and no errors were thrown? Is that misleading the user?