Ubuntu Foundations 25.04 - Plucky Puffin Roadmap

Hello folks, Matthieu here o/. I’m the Engineering Director for the Foundations Team and though I have been pretty quiet in the past, I couldn’t help but get inspired by my friend @local-optimum who recently shared with you the 25.04 Desktop Roadmap .

So I hope you’ll enjoy learning a little more about what we are preparing for Ubuntu 25.04 Plucky Puffin.

Disclaimer: Even though we try our best to meet our commitments, changes happen during any development cycle and that roadmap preview is also subject to changes.

Continue to gain performance improvements

In the last 2 cycles we had a strong focus on raising the bar in terms of understanding performance on Ubuntu. After we enabled frame pointers by default during the Ubuntu 24.04 LTS cycle and included additional performance tooling, we experimented with -O3 optimization flags during the 24.10 cycle. Now we will enable -O3 optimization flags by default on Ubuntu for the Ubuntu 25.04 release.

We won’t simply enable these flags and hope for the best, we will go in and identify packages that really take advantage of these optimizations and make sure they are recompiled while we will also isolate and disable optimization for packages that show reduced performance. We hope this balanced approach will provide the best performance improvement overall without compromise.

What about LLVM ?

Since its creation in 2000 and open-source launch in 2003, LLVM has become a versatile, modular compiler framework known for its architecture-independent IR and JIT capabilities. Widely adopted by companies like Apple and used in languages like Rust and Swift, it powers modern compiler innovations. While it is used in several key components in Ubuntu like Firefox, we would like to evaluate where its support stands for the rest of the Ubuntu ecosystem?

This cycle we plan to perform a full archive rebuild with LLVM and publish the results on this Discourse to allow maintainers and the community to review results and improve the overall LLVM support for Ubuntu.

System Software Updates

We remain committed to delivering the latest system software in every Ubuntu release. Exciting updates coming to Plucky include glibc 2.41, systemd v257, and OpenSSL 3.4.

Dracut

dracut is a tool for generating initramfs in Linux, designed to provide a modular and flexible approach for booting systems.

It’s been awesome to see such interest and feedback to @bdrung’s post last month about dracut and a lot of you have been experimenting with it on Ubuntu 24.10 successfully.

We will introduce dracut as an alternative to manage initrds on Ubuntu 25.04. If things go according to the plan, we should have dracut as the default initramfs generator in the 26.04 LTS.

APT

An important internal part of APT is called the solver . This now 20 years old piece of software requires some tune up as it is reaching its limit. Solving it would drive more predictable results when installing packages, would do a better job at intentionally removing packages and provide additional details into why something can’t be installed.

This new solver remains a priority, we are working on getting it production-ready, and adding mechanisms to record discrepancies with the old solver for evaluation. We are also introducing a way to pass option values to hooks, such as the Pro hook, which allows them to respect options such as --quiet.

Ubuntu release upgrades

The Ubuntu upgrade experience remains a high priority for us. This cycle, we aim to focus on addressing more user-facing issues and covering non-happy paths in our continuous upgrade testing. In particular, we are planning to address common issues such as those caused by third-party packages from PPAs, out-of-date or unsupported mirrors, and more.

Toolchains on Rails

In the last 2 years we have raised the bar on our toolchain support and have been delivering new upstream toolchain versions into Ubuntu with precision and predictability. For example, .NET9, the latest .NET version is already available on Ubuntu.

For 25.04 we are planning the following major toolchain updates:

Toolchain Version
Python 3.13
GCC 15
Java 24, 21, 17, 11, 8
Go 1.24
Rust 1.81, 1.82, 1.83
LLVM 19
.Net 9

More snaps for your toolchains

The much awaited devpack-for-spring snap will be published along with the 25.04 release, allowing spring and spring boot developers to easily set up their environment to develop and build their applications with maven or gradle.

The .NET developer experience is improved a lot with the new .NET snap. With an efficient installer tool, it allows developers to manage their .NET runtimes and SDK estate easily for multiple versions. And in 25.04 it will get an improved CLI as well.

Improvements will also be delivered to the snapcraft plugins for Gradle, Rust and .NET. These are aimed at making it easier for developers to build snaps for applications written in these languages…

RISC-V

We are going to introduce on-demand testing of packages on Risc-V architecture. Full integration with http://autopkgtest.ubuntu.com/ is something we want to scope in the near future. The actual integration will depend upon the hardware availability for the builders.

ARM Desktop

We continue to make great progress on providing a generic Ubuntu Desktop experience on ARM Laptop. @tobhe has been driving a developer preview with the Ubuntu concept image for Qualcomm Snapdragon X Elite laptops. That image has been rebased on the latest Ubuntu 24.10 release and comes with all the great benefits of Oracular Oriole. To date this image has been confirmed to work on 6 different platforms. We’d love to learn more about platforms we don’t have access to, so feel free to join the conversation and provide details about your platform if it isn’t supported yet!

Release and Quality

More details about the release schedule can be found here but in summary we will have 2 releases this development cycle, Ubuntu 24.04.2 LTS and Ubuntu 25.04. Part of the release process, we test the latest development images following our ISO testing plan during some specific testing weeks.

This cycle we will be evaluating openQA for VM based Ubuntu ISO testing. We should have a public instance by the end of it. This should offer much better automation capabilities as well as greater visibility on the overall quality status of the incoming release.

That’s all folks!

I hope you enjoyed that deeper dive into our 25.04 Plucky Puffin roadmap. We’ll make sure to update everyone if things don’t go according to plan or if new things are added to our plan before feature freeze in February next year (2024-02-20)

Thanks,

12 Likes

Great plans, thanks for sharing! I have to questions:

  1. Is there a link or project page to follow the progress with the APT solver? Are you plans aligned with the Debian project?
  2. Half a year ago GNU Automake 1.17 was released but it is still not packaged for Puffin. Automake is still relevant for a couple of fundamental tools. (Related bug)

Seems solid as always! Seems like this will be another solid Ubuntu release, improvements on top of improvements. :smiley:
On a side note… could you please keep the startup sound option and replace the 4.10-6.06 startup sound with the 6.10+ startup sound?
This one: https://www.youtube.com/watch?v=bKOL-ct6VbU
I think a lot of people would love to hear it again. And it’s much more recognizable than the first one.

That would be a question for the Desktop Team rather than for Foundations

1 Like

Ah, I see. Thanks for telling me! :sweat_smile:

Howdy,

these are great questions, let me answer the questions on APT.

For context, I work on APT as part of my work at Canonical (since 2018), but I am also the primary Debian/upstream maintainer of it (started hacking on it in 2007, still in school, became the lead of sorts in I believe 2015). A better solver has been a passion project of mine for as long as I can think back, and I am grateful to get the chance to make this come true as part of my work.

I don’t really have a public status page. What you can monitor if you want to is the solver3.broken file in the repository - it should go down to 0 before switching the default. I also have a test suite of complex real-life cases in https://salsa.debian.org/apt-team/apt-tests which needs to pass, but I may need to actually push some more cases to it. Currently it fails one of the upgrade tests, due to the lack of “conflict-driven clause learning” which is what I am working towards. The recent APT 2.9.17 release contains the first set of changes towards being closer to MiniSAT, which is the reference for everyone, then we can reuse the trusted and proven clause-learning. After that we need to get good error formatting.

As the Debian maintainer of APT, I am receiving feedback on the solver from users testing it, including other Debian Developers. I don’t particularly solicit a lot of feedback on the solver design, but the feedback from users helps make it work correctly. The real test will be when we turn it on by default, and this is where both projects complement each other:

We can enable the solver first in Ubuntu and ship it in a stable release, before turning it on in Debian. This aligns with the timelines of both projects: Debian is about to freeze for the next release, it’s too late to switch the default now (and we’re not ready yet), and we will open our development cycle for the next release around the same time, which is the best time to do a big change.

The biggest regression risk from switching the solver is problems during upgrades, between releases in particular. Consider this: If you have 500 updates available, there are
2**500=3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376 (that’s 151 digits) of possible combinations - each package can be upgraded (or not). There’s generally speaking orders of magnitudes fewer choices when installing packages.

A lot of Debian users run unstable, which has a lot of upgrades all the time, and Debian users also upgrade between releases using pure APT. In contrast, there are very few users of Ubuntu on a development series, and upgrades between stable releases are handled by a dedicated release upgrade tool. As a result, we can fully eliminate the biggest regression risk for Ubuntu users because we can always just use the old solver in the upgrade tool, or work around issues, and therefore, Ubuntu users have a significantly reduced regression risk.

At the same time, Ubuntu users also benefit from it a lot, as the new solver makes it much harder to accidentally uninstall system packages by not closely reading the apt output, as it is safer by default: It never opts to remove manually installed packages of its own volition.

3 Likes

a man wearing headphones stands in front of a microphone with the words secret lab on the bottom

:smiley:

1 Like

Thanks for the comprehensive answer. I am glad to hear that Ubuntu and Debian are not diverging in this aspect!

Probably it is best to follow the project progress by reading the commits in the APT Git repository.