[needs-packaging] cuda-13-1

[Antoine Lassagne]

CUDA: https://docs.nvidia.com/cuda/

[Antoine Lassagne (antoinelassagne)]

This issue aggregates the need-packaging request for the following packages:

cuda-cccl-13-1
cuda-crt-13-1
cuda-ctadvisor-13-1
cuda-cudart-13-1
cuda-culibos-13-1
cuda-cuobjdump-13-1
cuda-cupti-13-1
cuda-cuxxfilt-13-1
cuda-documentation-13-1
cuda-gdb-13-1
cuda-meta-13-1
cuda-nvcc-13-1
cuda-nvdisasm-13-1
cuda-nvml-dev-13-1
cuda-nvprune-13-1
cuda-nvrtc-13-1
cuda-nvtx-13-1
cuda-profiler-api-13-1
cuda-sandbox-dev-13-1
cuda-sanitizer-api-13-1
cuda-tileiras-13-1
libcublas-13-1
libcufft-13-1
libcufile-13-1
libcuobjclient-13-1
libcurand-13-1
libcusolver-13-1
libcusparse-13-1
libnpp-13-1
libnvfatbin-13-1
libnvjitlink-13-1
libnvjpeg-13-1
libnvptxcompiler-13-1
libnvvm-13-1
nsight-compute-13-1
nsight-systems-13-1
cuda-opencl-13-1
cuda-integrity-tests

* All these packages were built following the same framework, to make the reviewing, sponsoring and maintenance easier.
* They are built from prebuilt binaries from NVIDIA. Per our redistribution agreement, we have to match NVIDIA's own packaging exactly.
* The target pocket is Multiverse on Resolute.
* autopkgtests are implemented to verify that the packages are fine. They are shared between all packages and thus delivered into an additional package, named cuda-integrity-tests.
* We are aware that they install components to /usr/local and we are asking the archive admins for an exception for these packages.

[Antoine Lassagne (antoinelassagne)]

All packages are built for Resolute and delivered in ppa:canonical-nvidia/cuda-ubuntu-proposed:
https://launchpad.net/~canonical-nvidia/+archive/ubuntu/cuda-ubuntu-proposed?field.series_filter=resolute
The noble versions should be ignored.

All packages are also available in git repos following this naming convention:
https://git.launchpad.net/~canonical-nvidia/+git/<package name>-13-1

We assume that the package that provide the autopkgtests, `cuda-integrity-tests`, should be reviewed first. This package is different than the others. It is native, it is a collection of script reused during autopkgtests by all other packages.

[Skia (skia)]

ubuntu-cuda-packaging-tools uploaded:

❯ dput ubuntu ../ubuntu-cuda-packaging-tools_1.0.0ubuntu_source.changes
Uploading ubuntu-cuda-packaging-tools using ftp to ubuntu (host: upload.ubuntu.com; directory: /ubuntu)
running suite-mismatch: check the target distribution for common errors
running releasemismatch: Warn about mismatching suffixesg e.g. focal with a XX.YY not being 20.04
running badauthor: Stop if uploading with root@ or ubuntu@ email adresses.
running commoncachefiles: Stop if uploading with commonly known cache files.
running placeholderbug: Stop if using common placeholder numbers as bug reference.
running updatemaintainer: Stop if ubuntu changes are without ubuntu maintainer.
running supported-distribution: check whether the target distribution is currently supported (using distro-info)
{'allowed': ['release', 'proposed', 'backports', 'security'], 'known': ['release', 'proposed', 'updates', 'backports', 'security']}
running gpg: check GnuPG signatures before the upload
running required-fields: check whether a field is present and non-empty in the changes file
running checksum: verify checksums before uploading
running nobug: Stop if uploading without any bug reference.
running ppaforppaonly: Stop uploads to the archive with or to ppa without ~ppa suffix.
running check-debs: makes sure the upload contains a binary package
running gitubuntu: Warn if uploading without git-ubuntu Vcs-* entries.
WARNING: .changes file does not contain git-ubuntu "Vcs-Git"
WARNING: .changes file does not contain git-ubuntu "Vcs-Git-Commit"
WARNING: .changes file does not contain git-ubuntu "Vcs-Git-Ref"
Check: Upload without git-ubuntu Vcs entries? [yes, NO]: yes
Uploading ubuntu-cuda-packaging-tools_1.0.0ubuntu.dsc
Uploading ubuntu-cuda-packaging-tools_1.0.0ubuntu.tar.xz
Uploading ubuntu-cuda-packaging-tools_1.0.0ubuntu_source.buildinfo
Uploading ubuntu-cuda-packaging-tools_1.0.0ubuntu_source.changes

[Skia (skia)]

All uploaded: https://paste.ubuntu.com/p/qD8qYgxm7c/

[Jon Seager (jnsgruk)]

> * We are aware that they install components to /usr/local and we are asking the archive admins for an exception for these packages.

This was agreed as a reasonable exception for this release with sabdfl, paelzer and a few others during our virtual roadmap sprint.

We would like to work with Nvidia over time to bring this in line with other packages, but we agreed that for 26.04 LTS at least, this was okay.

[Christian Ehrhardt (paelzer)]

This is a nice try Jon, and while it is true in theory you could just say so :-)

I already reached out to Mark to please add the message here.
He saw the chance of a TB meeting that was already scheduled today to discuss it a bit before the official statement is then done by any TB member here on the bug.

[Sebastien Bacher (seb128)]

Removing sponsors since the packages have been uploaded

[Robie Basak (racb)]

On behalf of the TB as agreed in our meeting today (in Google Meet, not IRC as usual), use of /usr/local/ as a stopgap is approved for these specific uploads that are in the Resolute NEW queue at the moment, for CUDA specific packages only, into multiverse only, on one condition. We expect to move the path from /usr/local/ to regular distro FHS in the future[1]. We do not expect to be limited from doing so by the argument that users will be broken by the path move *because* we published it in the Ubuntu archive in /usr/local/. Mitigations need to be put in place for that now, such as appropriate release notes and documentation.

We did not discuss a specific timeframe for the expected move into regular FHS paths in terms of which future release post-Resolute we expect the move to happen. I think the expectation is "soon after Resolute", otherwise the TB may come knocking :-)

[1] To be clear, once these arrive into Resolute, we expect the paths not to change in Resolute for the lifetime of the Resolute release. The future path change would happen in future Ubuntu releases only.

[Antoine Lassagne (antoinelassagne)]

Hello,

Thank you for your flexibility over this matter. I realize that some details about CUDA are missing from this thread (this is my bad), I'll add them to avoid any surprise.

- Every CUDA minor version is a new set of ~37 packages. There is a minor version every 3 months on average. The next release is expected this month.
- We will keep adding the next minor versions of CUDA following Ubuntu's policy, first to latest, then backport, up until Resolute.
- Every CUDA minor version gets 3 patches on average [1]. Given the prebuilt nature of CUDA, I will submit a SRU exception request to be able to backport these patchs.

I hope these details give everyone more context about what is this particular release, when the next one will come, etc.

As for moving into regular FHS paths, we keep pushing NVIDIA to do so. We did try to make them accept it for this release, which they refused. We suggested a compromise, a temporary symlink approach, which they rejected too.
They did say they agree to work on that, but their next window for delivering such an update is their next major release. Their plan is not to break CUDA on a minor release. The next major release is expected in at least a year, if not two. This means that every 13.x CUDA packages will require the FHS exception. We will continue pushing for 14.x to be compliant.

[1] https://developer.nvidia.com/cuda-toolkit-archive

[Christian Ehrhardt (paelzer)]

Thanks Antoine, we already relayed that general stance in the discussion but your post here is a great summary and breadcrumb for an audit trail.