| 8 May 2025 |
 SomeoneSerge (Ever OOMed by Element) | (didn't load all manifests yet tho) | 02:33:21 |
 connor (he/him) (UTC-7) | Fair question; I don’t think we do.
Is there a concern you had in mind?
For what it’s worth, I’ve seen them use the “source” and “linux-all” platform (meta-platform?) to indicate a package works on multiple platforms rather than having an entry for each (all with the same hash). In the rework I give those preferential treatment since they’re agnostic and don’t seem to occur alongside other variants of the package: https://github.com/ConnorBaker/cuda-packages/blob/7731ebdf397c5ce123571abf2dc41ebac86237d3/pkgs/development/cuda-modules/packages/redist-builder/package.nix#L102 | 04:54:54 |
| connor (he/him) (UTC-7) | Okay bed time for me.
Tomorrow will include work on introducing the setup hook changes | 04:59:20 |
| connor (he/him) (UTC-7) | Thank you for the fixes Serge! | 16:07:04 |
| SomeoneSerge (Ever OOMed by Element) | Sure, thank you! | 17:10:55 |
| SomeoneSerge (Ever OOMed by Element) | I avoided force-pushes. Do you think we should squash? | 17:11:27 |
 Kevin Mittman | In reply to @ss:someonex.net
RE: Why
How do we know if we can assume that (pname, version, platform) always corresponds to a unique hash, e.g. that nvidia never publishes two different things under the same (versioned) name? (treating sbsa and jetson as different platforms)
Well so far I haven't found any exceptions: A v. B
There is a policy of version uniqueness. Unfortunately, enforcement is limited | 18:26:54 |
| Kevin Mittman | In reply to @connorbaker:matrix.org
Fair question; I don’t think we do.
Is there a concern you had in mind?
For what it’s worth, I’ve seen them use the “source” and “linux-all” platform (meta-platform?) to indicate a package works on multiple platforms rather than having an entry for each (all with the same hash). In the rework I give those preferential treatment since they’re agnostic and don’t seem to occur alongside other variants of the package: https://github.com/ConnorBaker/cuda-packages/blob/7731ebdf397c5ce123571abf2dc41ebac86237d3/pkgs/development/cuda-modules/packages/redist-builder/package.nix#L102 driver_assistant is a pure Python script, hence linux-all. and cudnn_samples is source code, that would ideally be posted on Github | 18:31:25 |
| SomeoneSerge (Ever OOMed by Element) | Well I want functionality for "merging" a set of manifests, rather than having single cuda manifest first spawn a package set, which is then extended with other components like cudnn. I think that suggests a merged domain of "package( recipe)s" which the future package set can grab stuff from. Finally, if things are to share a scope, how do we know they don't compete for the same spot? ^^^ | 18:35:02 |
| SomeoneSerge (Ever OOMed by Element) | Yeah as long as we ensure observability on our side I'm fine making this an assumption | 18:37:23 |
| connor (he/him) (UTC-7) | Up to you! | 19:30:27 |
| connor (he/him) (UTC-7) | Merging in what sense?
As an example, in cuda-packages I traverse the collection of manifests provided for to an instance of a CUDA package set, creating a arguments to be fed to redist-builder: https://github.com/ConnorBaker/cuda-packages/blob/62a4c5b58eed0038d73ac2b5e6bc151d851c0f81/pkgs/development/cuda-modules/default.nix#L73-L91 | 19:35:23 |
| Kevin Mittman | I can imagine it would be useful to have a list of all cuda12 compatible CUDA-X binary archives | 22:24:06 |
| SomeoneSerge (Ever OOMed by Element) | Merging as in merging manifests into a single manifest, single hierarchy, as opposed to constructing a set of packages from a sequence of overlays | 22:51:35 |
| SomeoneSerge (Ever OOMed by Element) | In particular, I'd prefer there be a single set of "archive"s, all of the same shape, and each have a unique key. E.g. it could be a tree where archives.${pname}.${platform}.${version}.${compatTag} (the tags are for cudnn...) is { relative_path: String, sha256: String, md5: Option<String> }, etc. Note no ${manifest_name} in there. | 22:57:56 |
| SomeoneSerge (Ever OOMed by Element) | So we found a trivial violation:) | 22:58:50 |
| SomeoneSerge (Ever OOMed by Element) | There's also no reason we should assume there's ever at most one compatibility tag... | 22:59:39 |
| 9 May 2025 |
| Kevin Mittman | could you provide a pseudo-code form of what you are asking for? | 00:50:30 |
| Kevin Mittman | specifically trying to ask if there would be one or multiple versions of each component to satisfy the dependency closure? | 00:58:31 |
 Guillaume Desforges | Hey! Has anyone tried to package torchcodec?
https://github.com/pytorch/torchcodec | 17:07:26 |
| Guillaume Desforges | * Hey! Has anyone tried to package torchcodec?
https://github.com/pytorch/torchcodec
(sorry if that's the wrong channel) | 17:22:33 |
| Guillaume Desforges | * Hey! Has anyone tried to package torchcodec?
https://github.com/pytorch/torchcodec
(sorry if that's the wrong channel, afaik it's ok since it's NVIDIA-related) | 17:22:48 |
| Guillaume Desforges | * Hey! Has anyone tried to package torchcodec?
https://github.com/pytorch/torchcodec
(sorry if that's the wrong channel, afaik it's ok since it's torch/NVIDIA-related) | 17:23:13 |
| Guillaume Desforges | * Hey! Has anyone tried to package torchcodec?
https://github.com/pytorch/torchcodec
(sorry if that's the wrong channel, afaik it's ok since it's torch/CUDA-related) | 17:23:25 |
| connor (he/him) (UTC-7) | :L
on master:
nix-repl> legacyPackages.x86_64-linux.cudaPackages.cudnn.src
«derivation /nix/store/7gwjjblxcjxbbj8ry5zir6m35gks3aq6-cudnn-linux-aarch64-9.8.0.87_cuda12-archive.tar.xz.drv»
| 18:01:59 |
| connor (he/him) (UTC-7) | lmao somehow https://github.com/NixOS/nixpkgs/commit/9fd753ea84e5035b357a275324e7fd7ccfb1fc77 caused this | 18:09:44 |
| connor (he/him) (UTC-7) | I'll work on a fix shortly | 18:17:22 |
| connor (he/him) (UTC-7) | hmm, in hindsight the removed and changed packages listed here were a red flag: https://github.com/NixOS/nixpkgs/actions/runs/14912284892/attempts/1#summary-41889732827 | 18:18:44 |
| connor (he/him) (UTC-7) | Okay! https://github.com/NixOS/nixpkgs/pull/405707 should fix it --it also cleans up a fair amount of the logic. | 20:23:06 |
| connor (he/him) (UTC-7) | Also, if someone would mind reviewing https://github.com/NixOS/nixpkgs/pull/405664 | 21:02:13 |
