We distributed the set among the Archive admins and start with two each of those that are dependencies of later builds. I started building and evaluating cuda-cudart and cuda-cupti.
Start with cuda-cudart # License All good AFAICS # Package namespace There are some close misses like: nvidia-cuda-toolkit/resolute 12.4.131~12.4.1-8 amd64 NVIDIA CUDA development toolkit nvidia-cuda-toolkit-doc/resolute 12.4.1-8 all NVIDIA CUDA and OpenCL documentation nvidia-cuda-toolkit-gcc/resolute 12.4.1-8 amd64 NVIDIA CUDA development toolkit (GCC compatibility) No conflict to block you, but I assume those might conflict one day. I know from the tracking document in section "nvidia-cuda-toolkit retirement" that you are after that - so that is even less of a blocker. Timing is extra tight, but ok for the path we are on. # Binary namespace We all have discussed enough about the /usr/lib - it has been accepted for now by the TB with the order to work with Nvidia to get that away in the future. So I first thought the following warning would be non silenced about just that - but it seems to be more on inspection: W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-13-1 cuda-cudart-dev-13-1 usr/local/cuda-13.1/lib64 W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-13-1 cuda-driver-dev-13-1 usr/local/cuda-13.1/lib64 W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-dev-13-1 cuda-driver-dev-13-1 usr/local/cuda-13.1/lib64 But looking into a build that I did I see each of them have 832 lrwxrwxrwx root/root 0 2026-02-06 22:17 ./usr/local/cuda-13.1/lib64 -> targets/x86_64-linux/lib Which is at least unexpected, does that not make all of them conflicting installs? They are not packages that have a "Breaks" or "Conflicts" statement. I test installed this from the PPA and it gladly works these days. I'm sure if those would not be symlinks it would break, but being symlinks makes this ok. Seen in lintian: W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-13-1 cuda-cudart-dev-13-1 usr/local/cuda-13.1/lib64 W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-13-1 cuda-driver-dev-13-1 usr/local/cuda-13.1/lib64 W: cuda-cudart-13-1 source: binaries-have-file-conflict cuda-cudart-dev-13-1 cuda-driver-dev-13-1 usr/local/cuda-13.1/lib64 But it works and after install I see: dpkg -S /usr/local/cuda-13.1/lib64 cuda-driver-dev-13-1, cuda-cudart-dev-13-1, cuda-culibos-dev-13-1, cuda-cccl-13-1, cuda-cudart-13-1: /usr/local/cuda-13.1/lib64 Thereby this is negligible. If you want to resolve it down the road you could be inspired by how this is handled usually when it is a real file. In that case you often have some "foo-common" package that brings the thing everyone need and every package needing it depends on "foo-common". If you decide against resolving consider a lintian override with a comment why the decision was taken. # Misc I can't resist to hate binary-only content, yes I know you target multiverse because you are aware of that. So I can't stop you but let me express my distaste of it, whenever you can have a chance to influence that it becomes a source upload - do it! Making them better serviceable even if we are left alone and inspectable and ... $default-argument :-/ I tried to convince myself to at least appreciate the faster build as it does not build. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2141744 Title: [needs-packaging] cuda-13-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/2141744/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
