# 2025-04-08 CUDA Chat ## Attendees - Connor - SomeoneSerge ## Action Items - Connor - Get `nix-community/cuda-legacy` created (ping Jonas/Mic92/Zowoq) with Connor and SomeoneSerge as maintainers; ping @samuela @prusnak in matrix channel to let them know about the repo and ask if they want to help maintain it - Update draft for `arrayUtilities` - Add option to disable `nvccHook` runpath patching ## Notes - Regular meetings at this time? - Yes, another scheduled for Tuesday, April 15th at 7am UTC-7 - Serge: rough personal agenda through April - Interested in package set metadata independent of host platform - Imagining one import which is the same for all platforms and arranging its use in Nixpkgs such that it is cached for all platforms and phases - Out-of-tree workflow which takes in JSON and generates database for all platforms - Would like to see us store this data in a relational form - Considering integration with nix-index, but want to know more than just which files are present -- want a relational database which maps contents of output paths to DT_RUNAPTHS and exported symbols - See [Fluent Bit Debugging Motivation](#fluent-bit-debugging-motivation) - Connor: would finding diamond dependencies be an instance where one could use this tooling? - Serge: yes, but as an approximate solution one could check for store paths within a closure which have the same `pname` - Connor: need to maintain CUDA 11 support even though will be removed from tree in 25.05 -- what are your thoughts on that Serge? - Serge: maintaining it in the open is advertises broader support. - Nixpkgs has a bar for what is kept in tree, but here is an example of how to do it out-of-tree. - Secondly, some people surely do this already, but having a single, visible repo is a way to inform of best practices for out-of-tree packaging. - Start it under nix-community, comes with usual disclaimer of liability but also a visible place and can benefit from CI. - Connor: need to ask Jonas Chevalier to publish statistics on machine usage, etc., for nix-community infrastructure - Push to get funding allocated - Act on knowledge about load distribution and practicality of dynamic hydra builders either through user instances or spot instances in the public cloud - Serge: had `nix-gl-host` PR for Jetson support, project since rewritten in Rust, need time to revisit that - Connor: high priority work for me is getting [`arrayUtilities`](https://github.com/NixOS/nixpkgs/pull/385960) completed, reviewed, and merged - From there, can begin landing improvements which rely on that functionality for their setup hooks, like the hooks in <https://github.com/ConnorBaker/cuda-packages> - First up would be `nvccHook` - Serge: I had started working on something similar when writing setup hooks! - Serge: understand need for docs for CUDA packages, but it feels like overkill, don't want improvements to be blocked forever on docs - Connor: will focus on docs for how to consume/use the package set ### Fluent Bit Debugging Motivation During the Nix sprint, (arianvp and edef) debugging an issue with Fluent Bit where it was partially reusing `libzstd` from Nixpkgs, but linking statically a copy which was vendored. The OS ended up initializing one version (`systemd` uses Nixpkgs' version) and then when they called into Fluent Bit it would initialize the statically linked version because the way they export their symbols is wrong. If any of the other OS which ship Fluent Bit were using a recent version of ZSTD, they'd run into this issue too. Would have been much easier to debug if they could have compared which symbols are exported by each version of a binary. Related: open issue since 2017 in Nixpkgs, [Binaries are not stripped #21667](https://github.com/NixOS/nixpkgs/issues/21667). If you look at the symbols exported by Nix, `systemd`, or any executable, they export a bunch of symbols from dynamic libraries they use as if they were libraries implementing those symbols. We should track this data as Nixpkgs continues to evolve.