I, Antoine Lassagne, apply for upload rights for the CUDA package-set (and for the creation of a new CUDA package-set).
Contact Information:
-
Name:
Antoine Lassagne -
Launchpad Page:
https://launchpad.net/~antoinelassagne -
Matrix username:
@antoinelassagne:ubuntu.com
I am applying because:
-
I’d like to help the Ubuntu project live and grow
-
I’d like to reduce the burden on my sponsors, sponsor others, and help with the packages in whatever ways I can.
-
I’d like to reduce the burden of sponsors for CUDA in particular, because it is a lot of work that I am very familiar and confident with
Who I am
I am french and I’m based near Paris. My first linux experience being Ubuntu 11.04, I’ve always be passionate about messing around with computers and hardware in general. I’ve worked in the automotive industry, in robotics, and I’m now working at Canonical. I recently became a Ubuntu Contributing Developer. At Canonical, I’m working in Partners Engineering and I am responsible for the hardware enablement of the workstations based on NVIDIA’s chips (like DGX Spark). This involves a lot of packaging, including CUDA, and requires a good understanding of the separation of Canonical and Ubuntu and the conflicting strategies between them.
On the personal side I’m married to a wonderful wife and I have 3 kids, aged 3, 2 and 0. I’m happy when I’m busy 
My Ubuntu story
My first Ubuntu experience was a triple windows-nattynarwhal-macos boot on a macbook, just for the sake of doing it. I was so amazed to could receive a CD for free at that time. With no wifi drivers out of the box, of course.
Then I never stopped using Linux, and mostly Ubuntu. In personal projects, in containers, in servers, on every computer I have, and of course on anyone’s machine when one dares to ask me (or not) to install it.
Now that I work at Canonical in Partners Engineering, I often need to improve the Ubuntu / Linux experience for specific partners, mine being NVIDIA. That makes me touch a bit of every packages that are customer-facing in the distro, and improving tiny bits of the user experience feels great.
Here is my Ubuntu sponsorship miner page.
Examples of my work / Things I’m proud of
I’ve been working on a little bit of everything, more or less to pursue objectives from my day to day job. This is a list of noticeable packages I’ve been working on.
-
Some package updates: wpa 2.10 to 2.11 was an important one for Wifi 7 support. I was my first update with that many tricky patches. I’ve also done more simple one, sometimes on debian like vulkan-memory-allocator, spirv-reflect
-
A lot of SRUs. Some were by the book, some where a bit more wild. For example on this very uncommon wireplumber one, the impact was visible and the patch required to be entirely rewritten to apply to Noble. All these SRUs showed me how stability is (and should be) the major focus when backporting patches. They also made me build up my experience and confidence with the tooling. It involved alsa-lib, livecd-rootfs, gnome-remote-desktop. I also had SRUs blocked, for livecd-rootfs and wpa, and refusals taught me just as much as accepted ones. I recently resurrected the wpa 2.11 SRU request now that most concerns are addressed, finger crossed. My latest SRU is for autopkgtest, this is in progress.
-
I’ve sometimes helped fix packages without directly being the one working on the update, when I had the opportunity to help, like with network-manager or vulkan-tools
-
Some end-to-end patching. That involved developing the patch, submitting it and having it merged upstream, pushing it to devel, SRU’ing it. For example network-manager, or gnome-shell , or network-manager again
-
I worked on several NEW packages:
-
I added spirv-reflect, vulkancapsviewer, after the organization behind the vulkan SDK (called lunarG) stopped delivering debian packages. directxshadercompiler took a bit longer, but it was accepted in the NEW queue for Stonking in early may.
- I had the 3 vulkan ones open as ITP to debian, with ongoing sponsorship. vulkan-caps-viewer was a funny one, because I first packaged it, then during the review a debian developer developed and uploaded its own packaging, then it was rejected, I fixed it, and now we have the version from debian.
-
dgx-desktop-sbsa-gwdt-loader was an initiative to make the generic images work with DGX Spark. NVIDIA did not care much about this, since these device where running their own OS but it is important to me that the generic image works with all the devices. After it was accepted, I had a MIR request accepted for it. It required some more autopkgtests development. But in parallel I was still looking for a cleaner way to make the devices work without an additional hacky package. I had it fixed at kernel level and was able to retire the package before it was even released in any ISO. It’s a shame that all my packaging effort went to trash but I don’t regret pursuing the better solution in parallel, because the better solution is, well, better.
-
dgx-desktop-defaults contains quite a few binary packages (~15) and some hwe-*-meta that can be picked automatically by ubuntu-drivers during Subiquity. That involved some bugfix in ubuntu-drivers. This package contains some services, udev rules, grub configuration files, etc. and I have an ongoing MIR request for it to enable offline installations (I’d like it in the ISO). The package even required an upstream kernel patch.
-
libnvidia-container and nvidia-container-toolkit are two broadly used golang packages. They enable NVIDIA GPU pass-through within docker containers. I had them accepted in the NEW queue.
-
mig-parted is still in the pipeline, waiting for the reviewer to discuss the applied changes he required.
-
-
I recently did a few reviews, when I felt bad about my sponsors and wanted to reduce their load:
-
xlnx-image-update, fakechroot SRUs
-
slang, waylock, composable-kernel and intel-dcpp NEWs
-
-
I worked on having the cutting edge blender on resolute
-
Blender 4.3 was old and FTBFS
-
Blender 5.0 required an updated dependency stack, a FFE, and an architecture drop
-
opencolorio 2.3 was required and synced with a FFE
- it required a new minizip-ng that was initially break/replace for old minizip, which was bad. this entire story was a mess
- it required a new minizip-ng that was initially break/replace for old minizip, which was bad. this entire story was a mess
-
openimageio and krita where no changes rebuilds
-
Blender was synced from debian. I had to introduce a new patch because architecture-dependant files where in architecture-independant binary packages and path. This is still discussed upstream, and should be properly fixed with 5.3
-
-
I’m now working on Blender 5.1. I have it built on a PPA but it requires libimath to transition. This is not going to be easy but I’m on it.
-
-
And of course; the elephant in the room; CUDA
-
I have my name on a lot of the prior uploads (see any -13-1 package in the sponsoring report), even so that does not mean much, it was a team effort.
-
I led the team through the delivery of the 13-1 version of CUDA. Given the
-
closed source nature
-
amount of packages
-
fact that new minor releases are new source packages,
I made sure we were always working on a packaging framework and not on individual packages. I made our testing strategy, supported by autopkgtests, to give us confidence about the deliveries, and worked a lot on the or maintainers tooling, to automate everything we could
-
-
-
This was a bit wild and I’m well aware that it is probably not a good packaging experience. I have to erase from my brain every memory of a good practice that we had to ignore.
-
I worked on the archive admins reviews to improve our packaging as much as possible for the next upload. With the team we upstream’d 116 issues to NVIDIA. We are also working with them on getting rid of the problematic policy violations (the usr/local installation path)
-
I submitted CUDA 13-2 to the archive, and built a submission framework so that every future submission looks the same.
-
I drafted the CUDA SRU exception request that is under review
-
We are now asking for a CUDA packageset to be created. Every minor version of CUDA is a new source package so, to make this package set even more useful, we are going to request the addition of new packages in the packageset prior to their creation. We would like to mimic how the OEM metapackage works, maybe with a similar (script+PPA)-based mecanism. But this is not the object of this application and will require further discussions.
-
Areas of work
My work on partners machines made me interact with the release management team, to figure out the best way to customize the distro without impacting other users and to build images the right way. It also involves side-by-side work with the OEM team, and understanding their process, since some of the partners machines are packaged by OEMS.
My work on various userspace packages made me interact with the uploaders, sometimes to get some help about how to tune behaviors, sometimes for opinions about bugs, or for their knowledge of a given package, and of course to get sponsored.
Lately I also had to interact with archive admins more, for package removal, architecture removal, universe->main transition, NEW reviews, etc. And of course I have to interact with the SRU team to discuss SRUs and SRU exceptions.
Things I could do better
As I’m getting more and more confident with the packaging itself and the knowledge of the distro, I feel like I still need to do more packaging to encounter more weird cases. There are so many dh_* tools whose documentation I did not have to read yet.
The Blender 5.0 work was quite good for that. I need to work on packages that I haven’t worked before, probably with transitions and merges from debian. libimath will be a great exercise for that.
Plans for the future
General
These permissions will allow me to make the CUDA delivery smoother. This is a very parner-specific problem resolution. Longer term, I will apply for PPU for more packages:
-
the hwe packages that I’m maintaining (dgx-desktop-defaults),
-
the nvidia docker container stack (libnvidia-container, nvidia-container-toolkit)
-
Blender (and maybe a few of its core dependencies? I’ll see which one I have to work on on a regular basis.)
And then, hopefully one day, core-dev
What I like least in Ubuntu
I don’t like that so many of our partner machines are requiring dedicated Ubuntu image, and not the classic ones. the partners are pushing very hard to get dirty stuff in the distro, which we can’t have. We end up having all these custom images. It’s a matter of managing the partners, having packaging resources, having easy and fast sponsoring, and of course there is a bit that is out of our control. I’d like to help this situation not to become completely out of hands.
The second thing I don’t like is the fact that we are all expert users, and not always putting ourselves in the shoes of newbie users. We could instead consider them all newbies and make the system work for newbies. For example we could have an action of writing down every situation where opening a terminal is necessary, and reduce the list one item after the other.
).