1 of 33

How GNOME Gets into Ubuntu

Jeremy Bícha

GUADEC 2023, Riga, Latvia, 26 July 2023

2 of 33

About Jeremy Bícha

Lives in Florida, United States
First GUADEC
Packaging GNOME for Debian and Ubuntu starting with 3.0 in 2011
Canonical employee since 2022

3 of 33

Outline

Brief History of GNOME in Ubuntu
How GNOME gets into Debian
Release Schedules
Main Inclusion
Stable Release Updates
Discussion

4 of 33

…

5 of 33

Ubuntu Early Distinctives

Consistent scheduled release every 6 months timed to include the latest GNOME
Brown (later orange) theme

6 of 33

Language Packs

Minimizes the install by only providing needed translations
Allow translations to be added and improved without waiting for translations to be accepted upstream or for upstream to make new releases
Allows translations for Ubuntu-specific features

One idea that Ubuntu developers had from the beginning was increasing accessibility to people who use computers in different languages. By the first year of Ubuntu’s existence, they implemented a major part of this ideal with language packs. For packages that are in main and universe packages that have opted in, the translations are stripped out of the package and are instead provided by separate packages for each language. This minimize’s the space needed to store translations since only language packs needed by users of the system need to be installed. I’ll be honest; I’m not sure whether the space savings are as relevant now 18 years later as they were at the time. The language packs were designed to merge upstream’s included translations with translations submitted by contributors on launchpad.com. This is significant because it allowed for translations to be added or improved without waiting for translations to be accepted into upstream. Even when translations are accepted upstream, they are generally not available for users until upstream makes a new release which can sometimes be a problem. Finally, this allows for translations for apps that are unique to Ubuntu or if Ubuntu developers decide they need to add features to an existing app, those features can be translated too.

7 of 33

Unity

Ubuntu’s custom desktop since GNOME 3.0 in 2011
Most apps were still GNOME apps. Unity was basically an alternative to GNOME Shell
The Unity vision foresaw providing Ubuntu on a variety of devices all sharing the same UI principles.
Canonical stopped development in 2017 and switched back to GNOME

8 of 33

Ubuntu extensions #1: The Dock

9 of 33

Ubuntu extensions #1: The Dock

10 of 33

Ubuntu extensions #2: App Indicators

11 of 33

Ubuntu extensions #3: Desktop Icons

12 of 33

Ubuntu extensions #3: Desktop Icons

13 of 33

Ubuntu extension #4: Tiling

14 of 33

Ubuntu extension #4: Tiling

15 of 33

Yaru theme, now with color styles

16 of 33

sudo apt install gnome-session

Ok, but what if you want to use Ubuntu because you like getting GNOME quickly and you like the support ecosystem of a popular distro backed by a company providing security updates, but you don’t want so many tweaks to the GNOME look and feel. All you need to do is open a terminal and run sudo apt install gnome-session. Log out. Click your name on the login screen then click the gear button in the bottom right and choose GNOME. Then enter your password to finish logging in. Now you have the default theme without the extra Ubuntu GNOME Shell extensions enabled and even the Settings app doesn’t have the extra Ubuntu Desktop panel. This has been available since 2017 and was built using an interesting combination of features including GNOME Shell modes first used for the GNOME Classic session and per-desktop gsettings overrides which Canonical pushed into GNOME as part of this project.

17 of 33

Debian GNOME packaging: git

Since 2017
git-buildpackage from Guido Günther
Merges downstream packaging with full upstream git history

18 of 33

Debian GNOME packaging: watch files

Old system
Updated for GNOME 40 style
Now watching for beta and rc releases but not alpha

Each Debian package includes a debian/watch file. debian/watch files are an amazing tool that Debian has had for a long time to basically parse webpages for version updates. In Debian GNOME, we have those set to track new stable releases. Our watch files became more complicated with the GNOME 40 version numbering switch. Maybe if I or others from Debian and Ubuntu had been more involved in that proposal, the watch files could have been a bit simpler but what we have now works. Basically, we need to rewrite the .beta etc version numbers to ~beta so that they sort lower than .0.

I said that we track stable releases, but actually we will now be tracking beta and rc releases too. In 2023, we successfully packaged the GNOME beta releases in Experimental or in many cases, Unstable. This allows Debian Unstable and Testing users to get bug fixes and features faster and improves the quality of the GNOME .0 stable release. Therefore, it makes sense to make that more official by updating the watch files to match existing practice.

19 of 33

Debian GNOME packaging: status trackers

20 of 33

Debian GNOME packaging: status trackers

21 of 33

Debian release schedule

New stable release every 2 years
Stable, Testing, Unstable
Freeze temporarily stops new GNOME releases from getting into Unstable or Testing

Debian does have one complication for having the latest GNOME in Unstable: every two years (or every four GNOME Release cycles), Debian freezes briefly in preparation for a new stable Debian release. Unfortunately, these freezes still last for months although I remain hopeful that the freeze periods will be shorter in the future. Debian 12 was released significantly sooner than Debian 11 was. So although GNOME 44 was released in March, most of it is only landing in Debian Testing this week. However, we expect to have most or all of GNOME 45 in Debian Unstable or Testing on time.

Ubuntu doesn't have this long freeze. However, Debian's freezes do affect Ubuntu. When Debian 11 was released, Ubuntu chose to do like GNOME and ship the previous GNOME version. But this time while Debian 12 was frozen, Ubuntu was still able to get GNOME 44 on time. Ubuntu still worked with Debian to push their GNOME 44 work to Debian Experimental.

22 of 33

GNOME release schedule

Let's first briefly look at the GNOME 45 release schedule. Like every GNOME release, the GNOME 45 development cycle is 6 months long, beginning when GNOME 44.0 was released as stable and ending when GNOME 45.0 is released as stable. The first few months of the release cycle are wide open for development. GNOME then has an alpha milestone, which is basically an early work-in-progress snapshot of how things are going. From my perspective, the most important milestone of the *development* process is Beta. Beta also marks Feature Freeze, User Interface Freeze, and API Freeze. This means that at Beta, GNOME 45 will look and act really close to what it will be at release. The remainder of the development is focused on bug fixing, while allowing the documentation, marketing, and translations teams to do their jobs to prepare for the stable release. Shortly before release is a final milestone, Release Candidate. This helps ensure that the components are buildable and work well together for the stable release soon after. After the stable release, GNOME releases point release updates about once per month. Not every component of GNOME gets updated for these point releases and it's possible for GNOME components to release sooner if there are high priority bugfixes that should reach users faster.

23 of 33

Ubuntu release schedule

Now we can compare with the release cycle for Ubuntu 23.10. It is also 6 months although it starts and ends a couple weeks later than GNOME's. As previously mentioned, this is intentional since Ubuntu's release schedule was originally built around GNOME's schedule. Ubuntu used to have an Alpha milestone but dropped it in part because it seemed an arbitrary date and many big features and UI improvements weren't done at all by then. Also, the Alpha took developer time away from their development work for a milestone that was quickly obsolete. Some people looked forward to these milestones as an invitation to try the development version of Ubuntu on those days. Instead, users can try out any daily build of Ubuntu. Significant work has been done with automated testing to ensure that the daily builds should basically work, which was one of the points of finalizing an Alpha release. Ubuntu's big development milestone is Feature Freeze. Ubuntu policy is that big features need to at least be uploaded to the NEW or proposed pockets by that date or they should wait for the next Ubuntu release. In contrast to GNOME, Ubuntu has a separate User Interface Freeze date after Feature Freeze. Finally, while there is a Release Candidate phase, Release Candidate is not itself a single specific software release on a specific day. During this phase, there is a release candidate image that could be declared the final release if there aren't critical bugs found in testing. Additional release candidates are produced as needed to fix critical bugs. At this point, the only changes allowed to packages included on the images are

TODO: Ubuntu LTS

24 of 33

Ubuntu Main and Universe

Main are officially supported with free security updates for all from Canonical. Universe is basically everything else.
Main is everything in the default Ubuntu Desktop & Server installs
Also includes toolchains such as rustc, OpenJDK and dotnet even when not installed by default

Packages in main are officially supported by Canonical with free security updates for everyone for the regular lifetime of the release.

Universe is everything else. It started as an import of Debian’s source packages, but there can be Ubuntu customizations or even packages unique to Ubuntu in universe. These packages are community supported. Recently, Canonical began offering Ubuntu Pro which also provides security updates for universe packages. This is an opt-in service for Ubuntu LTS releases

Packages in the default install are in Ubuntu's main section. There are some things not in the default install that are also in main. Here are a few examples:

- Additional language support

- Toolchain support. One example is openJDK. Java is such an important programming language that it is useful for Canonical to commit to providing official support for its compiler. Other compilers in main are of gcc for the C programming language, g++ for C++, and Rust. TODO: Foundations team slide.

- Tools used for the maintenance of Ubuntu. Git is a great example but there are several Debian build tools or specific Python libraries.

- Also when we say default install, it includes Canonical products such as Ubuntu Desktop and Ubuntu Server. There are community-managed flavors of Ubuntu that include many things form Universe. Among these are the official desktop flavors: the oldest is Kubuntu featuring the KDE desktop and the newest is Ubuntu Cinnamon.

At the very beginning, things were in main because they were needed for the default install. But over time, there became an explicit commitment from Canonical to support all the things in main. Therefore, there is a review process packages must go through before they are allowed into main. Once a package is identified that it is believed ought to be part of the default install (or otherwise receive the main support commitments), someone needs to file a bug. There is a bug template.

25 of 33

Ubuntu Main Inclusion Review

Because of Canonical’s support commitment, there is a review process packages must go through before they are allowed into main. Once a package is identified that it is believed ought to be part of the default install (or otherwise receive the main support commitments), someone needs to file a bug. There is a bug template at the Github page on this slide.

A very recent example is Tecla. Tecla is a very minimal app written with GTK4 & libadwaita to replace gkbd-keyboard-display which was written years ago in GTK3. I noticed that this was a brand new dependency for GNOME 45 for GNOME Shell & the Settings app. Therefore, I packaged it for Debian and Ubuntu which are the only distros to have packaged this so far. I then used the template to file the bug.

To maintain quality standards, the Ubuntu Main Inclusion Review team wants to see tests for each package. It is nicest if upstream provides automated tests. This wasn’t done for Tecla so I filled in a wiki page with a manual test plan which is linked in the bug report.

Fortunately, the app is simple and did not require a separate review from the Security Team and the main inclusion request was approved quickly. I was so early in packaging Tecla that my test case didn’t test how Tecla was actually used in those 2 places in GNOME. As the final step, I tested the actual integration and saw that it was broken. I filed an upstream bug. If the bug isn’t fixed in time, then I would need to patch out the dependency change to not introduce a regression for our users. But I’m confident this bug will either be fixed or the upstream integration temporarily reverted so that a downstream patch will not be necessary. https://gitlab.gnome.org/GNOME/tecla/-/issues/7

In other cases, the Main Inclusion process could take months, so it is helpful for Ubuntu Desktop developers to know about planned dependency changes early because of these Ubuntu-specific requirements.

26 of 33

Ubuntu Stable Release Updates

Different process than security updates
Intended for “high impact bugs” or “other safe cases”
New upstream microreleases are ok if there is a good test suite
However, a lot of GNOME components don’t have a test suite. Fortunately, there is a standing exception for GNOME. But SRU team still requests a written manual test plan.
Translations are currently only updated for Ubuntu LTS point releases

27 of 33

Ubuntu Stable Release Updates (SRUs)

Requires tracking bug with test case
Ubuntu SRU team member manually reviews. If accepted, it is built as a “proposed” update.
The tests cases need to be run and manually verified.
After a minimum of 7 days, an Ubuntu SRU team member manually accepts it as an Ubuntu update
The update then is phased in. 10% at a time, every 6 hours. If no issues, the updates is fully phased in less than 3 days.

28 of 33

Current happenings

Ubuntu now consistently ships the latest GNOME available at release time
Debian and Ubuntu 23.10 have the Rust GTK4 0.5 series (GNOME 43). We are starting work on the current 0.6 series now. Then we will work on 0.7 for GNOME 45. Thanks Matthias Geiger for most of the Rust GTK update packaging work.
Canonical’s Jarred Wilson is working on automating some of the packaging work for new upstream releases

29 of 33

Thank you. Questions?

30 of 33

Questions?

GUADEC 2023, Riga, Latvia, 26 July 2023

31 of 33

References

32 of 33

References: Version Trackers

https://people.debian.org/~fpeters/gnome/ debian-gnome-44-status.html
https://qa.debian.org/developer.php?email=pkg-gnome- maintainers%40lists.alioth.debian.org&version=testing (or version=stable)
https://people.canonical.com/~platform/desktop/ versions/versions.html (variations like ‘gnome’ at bottom of page)
https://repology.org/project/tecla-keyboard-layout-viewer/ versions
https://release-monitoring.org/
https://qa.debian.org/cgi-bin/watch

33 of 33

How GNOME Gets into Ubuntu

Jeremy Bícha

GUADEC 2023, Riga, Latvia, 26 July 2023