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!
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.
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.
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.
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
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).
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.
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.
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.)
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.
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.
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.
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!