| 16 Feb 2023 |
 FRidh | In reply to @connorbaker:matrix.org
It looks like CUDNN 8.8.0 is available as redistributables (https://developer.download.nvidia.com/compute/redist/cudnn/v8.8.0/local_installers/11.8/) but they're no longer providing -archive.tar.xz files. Because I'm trying to update nixpkgs with the new version, should I look into unpacking an RPM or DEB file? posted this at the conda-forge feedstock repo. They typically have some contact with NVIDIA https://github.com/conda-forge/cudnn-feedstock/issues/54#issuecomment-1432630957 | 07:18:10 |
| 17 Feb 2023 |
 Kevin Mittman (UTC-7) | In reply to @connorbaker:matrix.org
It looks like CUDNN 8.8.0 is available as redistributables (https://developer.download.nvidia.com/compute/redist/cudnn/v8.8.0/local_installers/11.8/) but they're no longer providing -archive.tar.xz files. Because I'm trying to update nixpkgs with the new version, should I look into unpacking an RPM or DEB file? ughh sounds like a bug | 16:46:55 |
| Kevin Mittman (UTC-7) | https://developer.download.nvidia.com/compute/cudnn/redist/cudnn/linux-x86_64/ I see the tarballs here ... unless misunderstanding | 16:49:47 |
| Kevin Mittman (UTC-7) | the cuda11 one is meant for all of cuda 11.x | 16:51:05 |
 connor (he/him) | Did they... move the downloads? | 16:52:45 |
| Kevin Mittman (UTC-7) | Yes, this was done for consistency. /compute/<product>/redist/<component>/ https://docs.nvidia.com/cuda/cuda-installation-guide-linux/#tarball-and-zip-archive-deliverables | 17:03:43 |
| 20 Feb 2023 |
| connor (he/him) | How do you all handle PRs which have dependencies on other PRs?
For context, this is related to a PR I made here (https://github.com/NixOS/nixpkgs/pull/215229) which has spiraled into a grab-bag of changes.
As an example, if you have a PR A and a PR B which relies on that changes A has, how do you make that clear?
- Should
B use the branch A creates instead of Nixpkgs' master?
- Should there be notes or warnings in the description of the PRs about the merge order? If so, is there a particular style you'd recommend?
- How do you test multiple PRs which depend on each other with
nixpkgs-review? I had tried specifying multiple PRs as arguments, but it didn't seem like it stacked them.
The closest thing I think I've seen before is PRs against torch (example: https://github.com/pytorch/pytorch/pull/94243). They use this tool: https://github.com/ezyang/ghstack.
| 15:14:57 |
| connor (he/him) | Additionally, when there are no maintainers and a package is failing (because of an unrelated issue) on master, who would you recommend tagging for review? For example, caffe: https://github.com/NixOS/nixpkgs/pull/217330 | 17:21:18 |
 linj | In reply to @connorbaker:matrix.org
Additionally, when there are no maintainers and a package is failing (because of an unrelated issue) on master, who would you recommend tagging for review? For example, caffe: https://github.com/NixOS/nixpkgs/pull/217330 I would tag the people who have contributed to the file in my pr for review. If my pr gets approvels, I would tag currently active committers (people who just merged some prs) for merging. | 17:38:27 |
| FRidh | In reply to @connorbaker:matrix.org
How do you all handle PRs which have dependencies on other PRs?
For context, this is related to a PR I made here (https://github.com/NixOS/nixpkgs/pull/215229) which has spiraled into a grab-bag of changes.
As an example, if you have a PR A and a PR B which relies on that changes A has, how do you make that clear?
- Should
B use the branch A creates instead of Nixpkgs' master?
- Should there be notes or warnings in the description of the PRs about the merge order? If so, is there a particular style you'd recommend?
- How do you test multiple PRs which depend on each other with
nixpkgs-review? I had tried specifying multiple PRs as arguments, but it didn't seem like it stacked them.
The closest thing I think I've seen before is PRs against torch (example: https://github.com/pytorch/pytorch/pull/94243). They use this tool: https://github.com/ezyang/ghstack.
That's always tough. I think your approach here, all in one PR but with clear commits is fine. The thing is, there are just not that many contributors in Nixpkgs to CUDA and it's quite a big PR so it takes some effort to review. | 18:47:27 |
| connor (he/him) | https://github.com/NixOS/nixpkgs/pull/217322 is closer to what I envision doing once I've further split apart that large PR. Does that seem okay? Is there an automated tool I should be using to do something similar to this? | 19:03:27 |
| connor (he/him) | Thank you all for the work you do maintaining the CUDA-accelerated packages. Building jaxlib and tensorflowWithCuda repeatedly is awful. | 21:45:11 |
| 21 Feb 2023 |
 hexa | https://github.com/NixOS/nixpkgs/pull/217497 | 16:55:31 |
| connor (he/him) | Has anyone used or set up CCACHE for any of the CUDA derivations? I know they take a while to build and I'm curious what's been done to try to reduce build times | 21:07:03 |
 SomeoneSerge (matrix works sometimes) | Hi! Thank you for investing your time and work in this right now! | 21:20:45 |
| SomeoneSerge (matrix works sometimes) | Interesting. I just looked up the ccache nixos wiki page, it suggests one can just drop in something called ccacheStdenv | 21:21:46 |
| SomeoneSerge (matrix works sometimes) | Do you know if packages built that way would work as substitutes for normal stdenv ones? | 21:22:59 |
| connor (he/him) | Unfortunately I think it would be a different derivation :l | 21:35:02 |
| SomeoneSerge (matrix works sometimes) | so, no magic( | 21:57:53 |
| connor (he/him) | From a conversation I had, it seems like it's intended more for use as a dev-shell than for the end derivation | 23:00:04 |
| 22 Feb 2023 |
| hexa | so, I have an application that wants tflite_runtime | 00:17:18 |
| hexa | can I substitute that with calls to actual tensorflow? | 00:17:31 |
| hexa | not keen on packaging tflite | 00:18:48 |
| SomeoneSerge (matrix works sometimes) | I'm not familiar with tflite, but good news is it seems that they build it with cmake, not bazel | 08:56:05 |
| SomeoneSerge (matrix works sometimes) | https://www.tensorflow.org/lite/guide/build_cmake | 08:57:43 |
| hexa | tensorflow.life is a thing | 09:38:47 |
| hexa | So no building required i think | 09:39:09 |
| hexa | * tensorflow.lite is a thing | 13:24:36 |
| hexa | -import tflite_runtime.interpreter as tflite
+try:
+ from tflite_runtime.interpreter import Interpreter
+except ModuleNotFoundError:
+ from tensorflow.lite.python.interpreter import Interpreter
| 13:24:53 |
| hexa | this is mostly what I did | 13:24:57 |
