Tightening the feedback loop Link to heading

One thing we notice ever so often is that although Phosh’s source code is publicly available and upcoming changes are open for review the feedback loop between changes being made to the development branch and users noticing the change can still be quiet long.

This can be problematic as we ideally want to catch a regression or broken use case triggered by a change on the development branch (aka main) before the general availability of a new version.

Not doing so can then lead to extra churn for both users and developers because at the point in time the issue is spotted/reported the developer’s focus is usually somewhere else entirely already and hence the issue might get less immediate attention than it should have.

To mitigate that we already

  • Use GNOME gitlab’s CI (thanks a lot GNOME!) to catch things upfront
  • Release on a monthly basis to shorten the time between a feature getting merged and “general availability”.
  • Make it simple to run Phosh nested so changes can be validated without installing anything

But even with the above it’s a bit tricky to do a “real live” test of a certain component at it’s current development version as it usually requires to invoke a package build or manual download of a package or tarball.

Nightly Builds Link to heading

So to improve on this we aim to provide nightly Debian package builds of several of Phosh’s components built against Debian Trixie. These jobs fetch the projects main branches and after applying possible packaging tweaks and building packages for amd64 and arm64 upload the packages into a common phosh-nightly repository. Thus if a change gets applied to a projects main branch it should be available in a packaged form a couple of hours later.

Gitlab CI Pipeline for nightly builds

This makes it easier for you to:

  • Verify if a bug you filed and that was closed as fixed is really fixed in the way you expect it
  • Help test the next release before it’s getting tagged
  • Test a newer version before filing an issue to make sure that version is still affected
  • Help out by continuously testing development versions

We picked Debian Trixie as a base since it’s Debian’s current testing distribution and builds the base for other, mobile focused distributions like Mobian Trixie, an upcoming PureOS version based on Trixie, etc. so packages can be tested there too. Once Debian releases Trixie and it becomes stable we’ll switch the nightly builds to Debian’s new testing (codenamed Forky).

As initial set we build the Shell phosh, the compositor phoc, the mobile settings application, the tour, phosh-osk-stub, calls and chatty for amd64 and arm64. We don’t provide builds for software that is available as nightly flatpak builds as that would be duplication.

Setup Link to heading

In order to use the nightly packages you need to add a new apt source. This is achieved via by the following commands:

cat <<EOF >/etc/apt/sources.list.d/phosh-nightly.sources
Types: deb
URIs: http://deb.phosh.mobi/nightly/
Suites: trixie-nightly
Components: main

apt update

If copy and paste is troublesome you can also get get the phosh-nightly.sources here and put it into /etc/apt/sources.list.d/.

Installing packages Link to heading

The repo is (similar to Debian’s backports) set up in a way that packages aren’t fetched from it by default - so you can still safely apt upgrade with the above added to your apt sources without pulling all nightly packages accidentally.

Now if you want to pick a nightly build (e.g. for phoc) you’d do

apt install -t trixie-nightly phoc

This will fetch the nightly build and also continue to pick it from that repository on further updates. When you want to go back to the version shipped in Debian you do:

apt install phoc/trixie

It’s as simple as that and the preferred way as it allows you to test changes on a per package basis.

Should you want to pull all packages from the nightly repo you can do:

apt install -t trixie-nightly full-upgrade

but be careful to check what packages exactly get installed/removed in this case.

Finding packages from the nightly repo Link to heading

If you want to figure out the packages you got form the nightly repo you can use apt-forktracer:

apt-forktracer |  grep '\+nb'

On a system that pulled phosh, phoc and mobile-settings and the matching debug packages the result looks like:

phosh-plugins (0.36.0+next20240208.1519.f5176c759.1) [Phosh: 0.36.0+nb20240306.4312891] [Debian: 0.36.0-1 0.36.0-1]
phoc (0.36.0+nb20240306.4312881) [Phosh: 0.36.0+nb20240306.4312881] [Debian: 0.36.0+ds-1 0.36.0+ds-1]
phosh-plugins-dbgsym (0.36.0+next20240208.1519.f5176c759.1) [Phosh: 0.36.0+nb20240306.4312891] [Debian: 0.36.0-1 0.36.0-1]
phosh-dbgsym (0.36.0+nb20240306.4312891) [Phosh: 0.36.0+nb20240306.4312891] [Debian: 0.36.0-1 0.36.0-1]
phosh (0.36.0+nb20240306.4312891) [Phosh: 0.36.0+nb20240306.4312891] [Debian: 0.36.0-1 0.36.0-1]
phoc-dbgsym (0.36.0+nb20240306.4312881) [Phosh: 0.36.0+nb20240306.4312881] [Debian: 0.36.0+ds-1 0.36.0+ds-1]
phosh-mobile-settings (0.36.0+nb20240306.4312901) [Phosh: 0.36.0+nb20240306.4312901] [Debian: 0.36.0-1 0.36.0-1]

This version information is useful to provide in bug reports as it allows to identify the exact git commit the package was built from.

Closing Link to heading

Note that you’re testing unreleased software so always make sure you can recover by going back to the Debian version e.g. via ssh login. Also make sure to not bother the Debian, Mobian or PureOS devs with bugs in these version. Issues detected in the nightly builds can go directly upstream. If you have trouble to figure out the right component start at phosh.

Have fun testing the nightly builds!

This work is possible thanks to your donations and Purism’s gitlab runners used to do the builds.