Application - CUDA Packageset (creation and rights), PPU for ubuntu-drivers-common and dgx-server-defaults - Mitchell Augustin

Community Ubuntu Developer Membership
1

I, Mitchell Augustin, apply for upload rights for ubuntu-drivers-common and for the CUDA package-set (and for the creation of a new CUDA package-set).

Contact Information:
Name Mitchell Augustin
Launchpad Page https://launchpad.net/~mitchellaugustin
Matrix username @mitchellaugustin:ubuntu.com
Email mitchellaugustin@ubuntu.com

I am applying because:

  • I would like to reduce sponsorship delays for ubuntu-drivers-common and the CUDA packages I help maintain

  • I’d like to reduce the number of sponsorship requests I ask of sponsors

  • I’d like to sponsor my teammates’ work

Who I am

I am the Technical Lead of Canonical’s NVIDIA DGX squad and an Ubuntu Contributing Developer. I am based in St. Louis, Missouri. Computers and technology have been my passion for as long as I can remember. I began learning about web design and scripting when I was seven, and I quickly moved on to writing desktop software with Java around age ten. During my teenage years and into adulthood, I created and maintained a plethora of different applications for various platforms, which collectively acquired several thousand users, and allowed me to gain some experience as the leader of my own app/project communities. Many of these applications were developed or hosted on Ubuntu systems. Prior to joining Canonical, I was a student at Purdue University, where I received my B.S. and M.S. in Computer Science in '22 and '23 (also focused mainly on operating system development and research).

Outside of technology, I am also an avid rock climber. :man_climbing:

My Ubuntu story

I’ve been an Ubuntu user since around 2014, when I first installed Trusty on an old computer that I wanted to repurpose into a server. From around 2014-2019, I continued to daily drive Ubuntu as my server operating system of choice, and from 2019 onward, I became a more active user of various Linux desktops, eventually resulting in all of my devices running Ubuntu as their primary OS after a bit of distro-hopping.

In 2024, I joined Canonical as a software engineer on our Nvidia DGX squad in Partner Engineering, where I am now the technical lead. Earlier this year, I became an Ubuntu Contributing Developer.

CUDA Packageset

CUDA packages in Ubuntu originate from source packages whose names include their major and minor version, in order to enable us to distribute multiple simultaneous CUDA version tracks in a single Ubuntu release. Thus, today, this package set should consist of the following source packages:

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

with this list expanding with new CUDA major/minor version additions.

Examples of my work / Things I’m most proud of

Areas of work

Working on the DGX PE squad, most of my work is focused on fixing bugs and implementing enhancements that impact users of Nvidia’s DGX server hardware (and more recently, the DGX Spark).

Individually, I am also deeply interested in improving the state of the Ubuntu desktop and gaming stories, which has aligned well with our priorities of improving the Ubuntu desktop experience on DGX Spark. Since becoming an Ubuntu Contributing Developer, I have ramped my efforts in the desktop space further (especially arm64 desktop), by contributing more to gnome-shell bug fixes, and via my leadership on the Steam snap enablement for arm64.

Things I could do better

I am making an effort to be a bit more patient, and to ping the sponsors and SRU team less frequently unless it is really truly urgent that an upload happens quickly. (thanks for all you do, sponsors and SRU team!)

Improvements since my Contributing Developer application:

Sometimes, I’ll forget to update the version code correctly on a development release upload that has just recently become a stable release.
I think I can continue to work on double- and triple-checking the version codes for my PRs for cases like this.

  • I have not made this mistake since before I mentioned this as an area of improvement

Every once in a while, I’ll also run into some edge case with the SRU process that I didn’t realize was documented somewhere - so I’m always making sure to add that to my personal knowledge doc to create less unnecessary back-and-forth.

  • Continuing to do this

Plans for the future

General

  • I’m continuing to work heavily with other arm64 developers in Canonical to improve arm64 game/application compatibility in the distro. The Steam snap for arm64 has been a great success story for our arm64 offering, so I’m making sure to keep that up-to-date and to respond to user feedback quickly.

  • I’d like to get back to fixing the version of asusctl that I packaged originally for Oracular, since the end goal was for this to be part of a larger effort to improve accessibility of hardware control applications for various OEMs. (However, this has taken a backseat to my other priorities, since it requires some significant reworks that weren’t present when were initially building in a PPA).

What I like least in Ubuntu

As a developer: I don’t like that, while Launchpad is meant to be our central source of truth for the source in Ubuntu, there is no clear indication on Launchpad itself for some major subsystems whose maintainers have different source management preferences. (ex: some maintainers prefer individual bug fixes per upload, some prefer multiple, some have source trees / patch ingress in different locations than LP itself). It would be good if LP had a place on the main landing page for a project (ex: Ubuntu in Launchpad) where maintainers could put their maintenance instructions, and if there was a widespread directive for that to actually be documented there.

As a user: There are some very common GNOME quirks which hinder the UX for desktop users coming to Ubuntu from other OSes. Most notably, I recently realized that creating desktop icons is a rather convoluted process with GNOME. This is because GNOME lacks the concept of a desktop icon, and this is enabled via a gnome extension - but there is no easy way to “right click”->“create icon” from our app launcher, so new users need to manually copy things from an obscure directory (to them) to enable this.

Another area that I think has some potential for optimization is the dual-boot story. In particular, one thing I always do for new users who want to trial-run Ubuntu on a dual-boot environment is to set their personal files and game disks to auto-mount into an easy to find location in Ubuntu, so it feels more at home out-of-the-box. I think it’d be nice if we had a way to do this directly from the installer, so novice users don’t have to know someone who can comfortably manipulate /etc/fstab for them.

4 Likes
Ubuntu Developer Membership Board Agenda
2

I’m glad to see Mitchell applying for upload rights. While I haven’t
worked with him directly on his packaging efforts, I’ve consistently
found him to be responsible and thorough, and I would feel entirely
comfortable knowing he’s maintaining the CUDA packages in Ubuntu.

Beyond his CUDA work, his contributions toward gaming on arm64 via
Steam have been hard to miss and are a great addition to the ecosystem.
I’m looking forward to seeing more of his work in Ubuntu.

1 Like
3

I endorse Mitchell for CUDA packageset upload rights.

Sponsoring feedback

The CUDA stack upload was something a bit special, to say the least. There was a contract to upload more or less exactly what Nvidia provided, so many issues found in those packages where actually tied to that contract, and nothing could really be done about it. Nevertheless, Mitchell made wonderful efforts to provide the best possible packages considering the situation, and recorded many bugs to keep track of the issues and work hand-in-hand with Nvidia to get those fixed upstream. I fully trust him to take good care of those uncommon packages living in multiverse, to iterate and drive improvements there for new releases, but also to see that the upcoming SRUs are prepared with a lot of care.

cuda-cudart-13-1/13.1.80-0ubuntu1
cuda-culibos-13-1/13.1.115-0ubuntu1
cuda-cccl-13-1/13.1.115-0ubuntu1
cuda-crt-13-1/13.1.115-0ubuntu1
cuda-ctadvisor-13-1/13.1.115-0ubuntu1
cuda-nvcc-13-1/13.1.115-0ubuntu1
nsight-systems-13-1/2025.5.2.266-0ubuntu1
cuda-gdb-13-1/13.1.115-0ubuntu2

Specific experiences of working together

There were some last minute NEW review blockers during the Resolute release week, that prevented the whole stack from landing in time. He managed to keep everybody in sync, pulled the right people in, discussed some tricky package versioning situation, and finally forwarded the final ack from Nvidia less than 24 hours before we released Resolute. Later that night, he also made sure everything was tested properly and the release would have no blocking bug.
That might not have been the most impressive technical skill demonstration, but for sure was a really nice show of his communication and coordination capabilities.

For more impressive technical skills demonstration, even if this has nothing to do with the present PPU application, I’d still mention his work on bringing up Steam+FEX on arm64 devices, because I happen to be daily driving a Snapdragon based laptop, and I must say it’s truly impressive to watch the machine run Divinity Original Sin 2 seamlessly with just a snap install steam and a few dumb click-click-click.

Areas of improvement and next steps

I don’t see any major point of improvement, despite broadening and deepening the Ubuntu knowledge to aim at core-dev as soon as possible!

1 Like
4

I endorse Mitchell for per-package upload rights for ubuntu-drivers.

I have worked with Mitchell on ubuntu-drivers and sponsored a number of his uploads. During that time he took ownership of a project that had accumulated a significant amount of technical debt, including legacy code, obsolete functionality, and unmaintained code paths. He quickly developed a solid understanding of the codebase and started the process of cleaning it up and modernizing it.

The SRUs resulting from this work were generally well-prepared and demonstrated a good understanding of Ubuntu’s SRU process and quality requirements.

Beyond individual fixes, he has shown a willingness to take long-term responsibility for the package and drive improvements rather than only addressing isolated issues. Based on my experience working with him, I trust his technical judgement and believe he is capable of independently maintaining and uploading packages within the ubuntu-drivers package set.

I therefore support granting Mitchell per-package upload rights for ubuntu-drivers.

1 Like
5

I endorse Mitchell for ubuntu-drivers-common PPU and CUDA packageset upload rights. As his mentor in the Ubuntu mentorship program, I am confident in his packaging abilities and am impressed by the initiative he’s taken when it comes to difficult packaging tasks.

Though I haven’t sponsored CUDA or ubuntu-drivers-common specifically, I have seen and talked with him about his work related to both and it is substantial. Outside of that, I have sponsored changes for him related to important packages, such as sudo, wpa, edk2, and ipmitool. Likewise, his work on the Lua 5.5 MIR also shows he is well on his way to core dev.

1 Like
6

I have sponsored just a few packages for Mitchel, but reviewed many of the cuda NEW uploads to resolute.

The cuda packaging is challenging for several reasons:

  • it’s not open source
  • ubuntu gets the packaging from upstream and has restrictions on what changes ubuntu can make to them, due to the license
  • many times, making a packaging change involves a roundtrip communication with upstream to get approval

I would recommend the DMB to focus on this part for granting the upload rights to this packageset: the tension between ubuntu packaging quality, and upstream’s packaging.

In my reviews, when I proposed changes, Mitchell was quick to act on them, and get the necessary approval from upstream, or take responsibility to follow-up on those changes if they were not blockers for an upload.

Given those reviews, I expect Mitchell to now know what we care about in this packaging, and he has shown to successfully deal with these requests and the simultaneous restrictions that this work imposes.

Here is an example of the challenges this packageset imposes: the upstream packaging of nsight-systems-13-1: Comment #117 : Bug #2141744 : Bugs : libcufile-13-1 package : Ubuntu and https://bugs.launchpad.net/ubuntu/+source/libcufile-13-1/+bug/2141744/comments/118

A less dramatic example of bad upstream packaging: Comment #57 : Bug #2141744 : Bugs : libcufile-13-1 package : Ubuntu which was sorted.

Mitchell is the best developer we have to handle the CUDA packaging in Ubuntu. He knows how to navigate the tension between best packaging practices and the restrictions upstream imposes on these packages, has a good relationship with upstream, and due to working on this packages has acquired a LOT of experience in some of the most thorny aspects of debian packaging, such as d/copyright, NEW package review process, maintainer scripts. I’m +1 on granting him upload rights to this package set.

1 Like
7

I endorse Mitchell for ubuntu-drivers-common PPU and CUDA packageset upload rights

  • Mitchell has a lot of packaging experience now and has been submitting packages of higher and higher quality. His distro work goes way beyond these per package upload rights.
  • Mitchell has shown very proactive and rigorous initiatives with ubuntu-drivers common. Under the leadership of Foundations, he has been owning this package for a while now.
  • Mitchell has a good knowledge of the CUDA packageset.

In general, Mitchell never does anything without digging into potential trouble, he asks for reviews, and is not afraid to bother people for questions and guidance. Mitchell is eager to learn pretty much anything that comes up, he’s aware of the impacts that mistakes can bring, and knows the policies that Ubuntu enforces.

Overall, I believe the Ubuntu project would benefit from having Mitchell as an uploader, now and in the future (when he’ll be core-dev :upside_down_face: ).

1 Like
8

I sponsored a few packages for Mitchell, some are still in the queue, like recently ‘dgx-server-defaults’. But on top I did many reviews for packages he worked on, that were eventually sponsored by others.
Mitchell, is very thoughtful when it comes to packaging. In his role he has to work on complex packaging cases - sometimes not open source, sometimes torn between partner requests and Ubuntu processes (typical for PE).
We have a department internal packaging MM channel where he is actively participating and asking about special cases, to get a solid understanding before starting the packaging work.
He is also open for feeback (esp. during reviews) and suggestions, willing to discuss, picks up ideas, reaches out to the right people to understand cases properly - and with that he learned and grew a lot in regard to packaging.
What I especially like is:

  • that he is not shy to work on packages that are even a bit outside of his domain and normal working scope, means he’s also working for the benefit of the community
  • and that he is also brave enough to pull back a package, in case that’s really needed
    His track record is amazing (see above), like his work in general,
    hence I feel even a bit honored to endorse Mitchell for the above PPU and CUDA packageset upload rights (which is quite a significant set and mix, that makes me think that it could also be an endorsement for a MOTU application).

I am absolutely convinced that Mitchell will handle his potential new upload rights carefully and responsibly.

Let me also thank Mitchell at this point for his great work in his squad, in PE and in Canonical in general!

1 Like