postmarketOS // 600 days of postmarketOS

Where Have You Been?

postmarketOS is aiming for a ten year life-cycle for smartphones, see the all new front page for a short introduction if you are new around here. Today we'll cover what happened during the second half of 2018. Many have been wondering where we've been and why it took us so long to write a real update post. Is the project dead already? Weren't phone calls almost working? What happened?

Development has been going on continuously, so we are not dead. Maybe a little undead though, like some of the old and forgotten phones we are trying to revive, because we have not really gotten any closer to the goal of getting telephony working or turning a phone into a daily driver. The Nexus 5, while booting mainline with accelerated graphics and connecting to the cellular modem all with a free software userspace, still does not have working audio. That is one example, other devices have different problems. However, we have not been sitting idle and doing nothing these past few months!

What's Missing?

So you might think, "well, then suck it up and get that last missing piece about making calls in place, and there we have our daily driver and salvation from the Android/iOS duopoly" right? No, not at all. You see, even with that missing functionality, it's still a proof of concept and not something that can be easily used as a daily driver. Making a phone call on the Nexus 5 still requires firing up a terminal and inputting commands, to name the most obvious flaw.

But there is more. Like all Linux distributions, we need to take care of all the things below the surface. The list of housekeeping tasks include: integrating the various components with one another, updating software in the repositories and dealing with breakage from such updates, maintaining a binary package repository and repairing packages that fail to build, handling incoming patches, bug reports and feature requests, and writing and organizing documentation. These things slow development down, especially if they are not as optimized as they could be.

What Now?

We are stuck in a proof-of-concept stage, and it's time to get out. No, this does not mean we are going to rush out telephony functionality (even if it could be done that "easily"), and pretending everything around it can be fixed later. There are certain workflows that need to be put in place to get a rock solid base, upon which it is easy and fun to develop on. Becoming a great platform for development has been the idea from the beginning, but it was only applied to the very foundation of postmarketOS: our pmbootstrap development tool. It's time to take it to the next level, and deploy this concept to the distribution as a whole.

Aports Split From pmbootstrap.git

With that in mind, we took on one of the most long-standing issues we have had with the postmarketOS architecture: the package building recipes (aports) were not separated from the pmbootstrap tool. This is resolved now, pmbootstrap will clone its own copy of the now-separated pmaports.git repository as you run its initialization wizard the first time. Thanks to this new independence, Linux distributions can properly package pmbootstrap. This change has also allowed us to (finally!) put it up on pypi:

$ pip install --user pmbootstrap
$ pmbootstrap init

This was also a very important stepping stone for basing our packages on different Alpine Linux branches in the future. Right now, we are on Alpine's bleeding edge (aptly named "edge") branch. While this allows us to get the latest versions of packages quickly it is a moving target, and roughly once a month there is an update in one of the packages that causes substantial breakage throughout postmarketOS. As developers, this is not a fun situation, but we can deal with it. Typically after a few days, everything is adjusted on our end, but we don't need to tell you how unacceptable it would be if your phone refused to work for a few days. Especially when every so often the "fix" involves having to reinstall the OS. Therefore the plan is to use Alpine stable releases in the future as a base, and rebasing our packages in a separate branch on the next Alpine release roughly every six months (to match Alpine's release cycle). This will allow us to give users a clear and safe upgrade path from the current stable packages branch to the new one once it is ready.

New sr.ht Based Binary Repository

Having multiple package branches means that we need to build each package for each branch, for every CPU architecture. Of course, this is not a fun exercise without a powerful and automated package building infrastructure. The problem is, what we have right now is not cut out for that task: a single x86_64 machine with a 3 GHz Quad-Core that is manually triggered to build everything. It takes, for example, several hours to build new Plasma Mobile upgrades for all supported architectures even though we are cross compiling and not supporting multiple branches yet.

This prompted us to start brainstorming for a worthy successor. Not long after the discussion started, builds.sr.ht ("builds dot sir hat") was mentioned and we have since started collaborating with its author @SirCmpwn. He describes his project as:

The flagship product from sr.ht is its continuous integration platform, builds.sr.ht, which is easily the most capable continuous integration system available today. It’s so powerful that I’ve been working with multiple Linux distributions on bringing them onboard because it’s the only platform which can scale to the automation needs of an entire Linux distribution. [...]

@MartijnBraam has been working on backend code that will start the individual package build jobs whenever new commits land in pmaports.git. It comes with a nice status page frontend, which links the individual postmarketOS packages to their sr.ht build jobs. Having one job per package requires knowledge of which packages need to be built in advance, so @ollieparanoid added pmbootstrap repo_missing.

The sr.ht based build repository efforts are still work in progress, however we have already caused nice spikes in sr.ht's statistics as we triggered the initial package build (see image below).

Improved Nexus 5 Mainline Packaging

@pparent figured out why the Nexus 5 was not booting reliably and fixed it. Furthermore he made sure that all backlights of the phone are used, instead of only having half of them activated.

In the picture you can see that he enabled the Plasma style for the QtVirtualKeyboard, and was able to do some basic web browsing with the device. Check out this video where he uses his mobile-configured QtWebBrowser on top of Plasma Mobile to visit various websites, watches a video in the browser and uses touch gestures with OpenStreetMap.

Pine A64-LTS, Librem 5, NC_1

While the majority of the devices running postmarketOS are rather old ones, we are interested in packaging support for new hardware as well. Especially if that hardware is produced by free software loving companies such as PINE64, Purism and Necuno Solutions.

Let's go through the related news in chronological order. After the PINE64 CEO TL Lim saw our postmarketOS presentation at Akademy, he offered us free Pine A64-LTS devices and shipped them shortly afterwards. @MartijnBraam did the port with a lot of help from @z3ntu and extended pmbootstrap to be able to write the U-Boot bootloader to the SD card.

Next up is Purism's Librem 5. @craftyguy ordered the development kit back in the crowdfunding days in September 2017. It arrived a few weeks ago and, while we were writing this blog post, he managed to boot postmarketOS on it. Sharing as much code between all devices as possible has paid off once more, because the Librem 5 requires U-Boot to be written to the SD card too. It also needs another firmware file to be written there, so @craftyguy refactored the code to allow an arbitrary number of firmware files to be embedded into the SD card images. In the picture you can see the dev board booted into XFCE4 and hooked up to a HDMI monitor.

Last but not least is Necuno Solutions with their NC_1. They are collaborating with six alternative mobile OS communities, and postmarketOS is among them. @PureTryOut will receive one device for free for porting purposes, and it is possible to order the NC_1 with postmarketOS pre-installed. Which of course brings back some classic questions: When a device is sold with postmarketOS, should we just name it marketOS then? What about premarketOS or pre-postmarketOS? (More work is clearly needed here.)

Raspberry Pi Zero

As shown in the last big update post, we have support for all Raspberry Pi versions up to 3B+ in postmarketOS. This already included the Raspberry Pi Zero, but since we had the DHCP server disabled for all Pi models, there was no convenient way to boot the Zero: it does not come with an ethernet port like the other models.

@drebrez took care of it by making several related fixes and introducing a separate device package, along with updated wiki documentation to provide installation instructions for each model.

Unity 8 and Phosh

You may remember Canonical's canceled attempt to bringing Ubuntu's Unity desktop to the phone. It was called Ubuntu Touch and lives on without Canonical's backing in the form of ubports, who have forked the project and maintain it nowadays. @z3ntu started porting the interface to postmarketOS and has already done an impressive amount of upstreaming with everything he fixed along the way. Unity 8 boots up so far, ubuntu-app-launch is working enough that applications can launch but everything locks up easily at this point. We need to package some actual apps as well, right now there is only the system settings app (in the picture).

Meanwhile, @PureTryOut, @ollieparanoid and @MartijnBraam took a shot at packaging Phosh, the UI that the Librem 5 will use by default on Purism's PureOS. Just like the Unity 8 port, getting the UI running on Alpine's stack holds some unresolved challenges and help is highly appreciated.

Misc Changes

As always with these blog posts, they get long even if we don't bother listing each and every change. Here are some of the most noteworthy ones.

Tab completion for pmbootstrap works perfectly now for bash and zsh: @GrantM11235 added this support by using argcomplete, so it automatically does the tab completions from the existing argparse. It does this without manual maintenance, and always perfect! Isn't that nice?

Until recently we had to use ARMv6 binaries on the devices with ARMv7 CPUs, because ARMv7 was not available in Alpine and postmarketOS. This is no longer the case! We should be able to unleash the full CPU power shortly for all devices, as @PureTryOut tested that changing the architecture for the Sony Xperia Z1 Compact works flawlessly.

One of the tougher challenges for postmarketOS was Alpine's upgrade from GCC-6 to GCC-8. A lot of vendor kernels refused to compile with GCC-8, and at least one device doesn't boot with a kernel compiled by GCC-8. We ended up with packaging GCC-6 side-by-side with GCC-8, building all existing kernels with GCC-6 and allowing device owners the ability to select the GCC version that should be used in each vendor kernel package. Device owners have been slowly switching to GCC-8 since then, after carefully testing that their device still boots after the change. New default patches related to GCC-8 were added, so new ports don't have to deal with these issues.

@pinoaffe updated the initramfs script to look for the rootfs in all block devices and partitions. Speaking of the rootfs, @zhuowei made it possible to build rootfs images with non-512 byte sector sizes (required for the Google Pixel 3 XL).

Two other important project changes, which aren't necessarily related to each other, are that @ryang2678 packaged the grate driver (for Tegra GPUs), and the wiki main page and homepage (based on @pparent's excellent photos) have been updated to be more mobile friendly by @ollieparanoid.

Eating Our Own Dog Food

A great way to increase stability is dogfooding: using postmarketOS installations on our own devices every other day for certain tasks. One example is turning the Nokia N900 into a music player with i3wm and mpd. This effort has already spawned a few usability improvement patches and lots of resulting ideas. It turns out this idea was not exactly unique as at least one other person has created a very similar setup for their N900. If you would like to join us on the dogfooding journey, figure out your own use case (e.g. how about a podcast player, or a browser that displays a status page? Tracking habits or TODOs?).

Then document your progress in the wiki and reach out to the Community to share your results, work together on fixing the flaws you found, and optimizing postmarketOS for your use case.

28 new booting devices (112 total)

Thanks to: everyone who ported these devices, see the contributors section in each device's wiki page.

Raw Numbers

As in all the big update blog posts, here are some additional figures. Note that the merged MRs, closed issues, open issues are counted across all postmarketOS related repositories now (this was not possible on GitHub, but we moved to GitLab). Stars, forks and watches are not included, as these were not imported. See the last post for reference.

415 people in the channel (+65)
1145 merged MRs
845 closed issues
251 open issues
133 contributors in pmaports.git (git shortlog --summary --numbered | wc -l) (+27)

Closing Words

FOSDEM 2019 starts in roughly two weeks, and quite a few people from postmarketOS will attend (@bshah, @MartijnBraam, @MayeulC, @PureTryOut, @unrznbl and @z3ntu), together with folks from pretty much every alternative FLOSS mobile project out there. Looking forward to seeing you there, if you are going!

So this has been a mixed bag of news. But here we are, honest and still having fun celebrating the hacker spirit that flows through the project. Thanks for reading and good luck with whatever your passion is, let's make 2019 a marvelous year of overcoming our obstacles, having fun and hacking on fascinating stuff!