Ubuntu's second Stonking Stingray rebuild clears main. Universe and multiverse still churning
Canonical is roughly a week out from its October 15 final release of Ubuntu 26.10, codename Stonking Stingray, and the most important archive-wide rebuild is largely done. The second test rebuild has finished for the "main" component across every supported architecture except the tiny riscv64 base. What's still running is universe and multiverse, the two components that contain far more community and third-party software, and by far the larger long tail.
If you're not inside Ubuntu's release machinery, an archive-wide rebuild sounds like overkill. It isn't. The main archive holds thousands of source packages, and whenever Canonical swaps out a foundational tool, a new glibc, a changed default compiler, a GCC bump, the release team recompiles basically everything from scratch against that new baseline. The point is to catch packages that break simply because the foundation moved, well before anyone downloads an image. It's the FTBFS ritual, or "Failed To Build From Source," played across the whole distribution.
How the rebuild landed
The status went out on the ubuntu-devel-announce mailing list on October 2. Graham Williams, who maintains Ubuntu's FTBFS reporting infrastructure (his Launchpad handle is "ginggs"), posted the numbers.
The second test rebuild of Stonking Stingray was started on October 2, 2026 for all architectures and all components. The rebuild is finished for the main component on all architectures except riscv64, and still running for universe and multiverse.
The run used the previous release, Questing Quokka, as its reference baseline. Preparing the updated build environments that make a multi-architecture rebuild possible at scale fell to Canonical's CPC and Launchpad teams, and Williams specifically called out both groups in the announcement.
Developers were then told to triage. The primary results live at the standard ginggs report page, with a separate sweep for packages still sitting in stonking-proposed rather than the main archive. The report also points contributors at superseded build snapshots so regressions introduced between runs don't slip by unnoticed.
The numbers
A snapshot of the rebuild taken on October 6 showed the following packages still needing attention:
| Component | Flagged in test rebuild | In live (proposed) archive |
|---|---|---|
| main | 60 | 11 |
| restricted | 0 | 0 |
| universe | 800 | 993 |
| multiverse | 0 | 30 |
Across architectures in the test-rebuild copy, aggregate failure counts came in at amd64 225, arm64 194, ppc64el 249, s390x 176, armhf 153, riscv64 41, amd64v3 112, and i386 15. The proposed archive told a wider story: up to 175 failures on armhf and 163 on s390x in the "failed to build" category alone.
Here's the thing about those two columns. When a maintainer lands a fix, the package drops off the flagged list and moves into the released archive. Main being essentially complete is a good sign the core is ready. Universe and multiverse are the grind, and they're the part that usually decides whether a release ships clean.
What actually broke
The main-archive failures landed across foundational system software, which is exactly where you want trouble to show up: well before release. Highlights included the boot chain including shim, shim-signed, grub2-signed, efibootmgr, efivar, fwupd-signed, mokutil, and core C libraries like glibc itself (2.44-1ubuntu1), libbpf, libnl3, and liberasurecode.
The developer toolchain showed up too: golang-1.26, dotnet10, gettext, devscripts, dput, lintian, m4, and strace. Desktop and networking packages weren't immune either, with gtkmm4.0, gtk4, iptables, openldap, and rsyslog all flagged.
In the proposed archive, the higher-profile losses were the networking and storage stack: ceph, openvswitch, ovn, and upki. These are the components that lean hardest on shared libraries recently changed by the toolswap, so it makes sense they'd take the hit.
Many of these carry existing Launchpad bugs already. gettext has #2167365, liberasurecode has #2169693, and there's a long-running glibc/arm64 issue at #1927192. That tells you some of this is architecture-specific pain surfacing again, not necessarily brand-new damage from this particular rebuild. Worth keeping in mind when you see a failure that looks suspiciously familiar.
Why the rebuild was necessary at all
Stonking Stingray's schedule names two "potentially disruptive archive-wide activities" that made this run unavoidable.
The first was the expected glibc 2.44 merge, slated for the week of August 6. A new C library has a nasty habit of breaking ABI-sensitive and dynamically linked packages, and the archive now carries glibc 2.44-1ubuntu1 to prove it. The second was the expected default LLVM transition the following week, shifting the default compiler to a newer LLVM/Clang build that can change error strictness, code generation, and link behavior all at once.
Rebuilding the entire archive against those new foundations is the only reliable way to find and fix breakage ahead of a release date. It's also why riscv64, which is the newest and smallest architecture support base, was still playing catch-up even as amd64, arm64, and the others crossed the line.
The path to the finish line
The official Stonking Stingray schedule puts the pieces in this order:
- September 24: Beta (mandatory). Already shipped.
- October 1: Kernel freeze plus the final language-pack translation deadline.
- October 8: Final freeze, Release Candidate, and the last translation deadline.
- October 15: Final release.
The second test rebuild sits right in the window between the beta and the final freeze. With main cleared, maintainers have roughly a week to land fixes, re-test, and chew through universe and multiverse before the archive freezes. After that, only bug fixes are accepted ahead of the October 15 go-live.
If you want to help
Ubuntu is inviting developers to open the FTBFS report, check the additional proposed failures at the ubuntuwire QA page, cross-reference the superseded builds to catch inter-run regressions, and then file or update the relevant Launchpad bug. From there it's a fix pushed to stoning-proposed, re-run until the package builds across every architecture.
Not exactly a crowd-sourced effort. But it's the kind of work that quietly decides whether your October upgrade installs cleanly or not.
