Sailfish OS 3.3.0

by

Jolla heeft eerder een update van zijn Sailfish OS uitgebracht met 3.3.0.16 als het volledige versienummer. Voor de naam van deze uitgave is gekozen voor Rokua, een nationaal park ongeveer 75km ten zuidoosten van Oulu in Finland. Sailfish kan gebruikt worden op toestellen van Jolla, de Sony Xperia X, XA2 en 10, en de Gemini PDA. De aankondiging van deze uitgave ziet er als volgt uit:

Sailfish OS Rokua is now available

Rokua forms part of Finland’s first UNESCO Geopark. In Rokua it is easy to see traces of the Ice Age. The park’s many esker ridges and wooded sandhills are blanketed with silvery lichens. Scattered through the park are many kettle hole lakes nestling in sandy hollows.

It has been almost a year since my previous blogpost aimed at a more tech savvy audience. With Sailfish OS Rokua it felt again like a good opportunity for such a blog post. The changes to the Sailfish OS user experience are available at the end of the document, if you want to skip the technical topics.

There are a lot of things that are not visible for a casual Sailfish OS user. This 3.3.0 release contains a vast number of updates for the lower level of the stack. We’ve included for example the updated toolchain, a new version of Python and many updates to core libraries such as glib2. In this blog I will go through a few of the changes and what they mean in practice for users, developers and Sailfish OS in general.

It is not just about updating one component – “Distribution jenga”
As many of you know operating systems consist of hundreds of components. These components are connected to each other at either compile time, link time or run time. When we conduct low level updates, as we have in this release, the changes for one component multiply and we end up updating tens of components because of their dependencies.

One such case was the update of the gobject-introspection package to version 1.63.2. The librsvg library started to fail during the process. This librsvg failure looked like an issue with vala. We decided to update vala also to reduce future maintenance work. This required the autoconf-archive package that we haven’t previously provided. Packaging the latest autoconf-archive then conflicted with gnome-common, which needed a small modification to make it compatible with autoconf-archive. After all the above, we finally got autoconf-archive installed and got back to vala and got all the pieces compiled together.

After compiling these changes together we had to integrate everything in one go to prevent the development branch from breaking. This was just one example of the many changes we have provided with this release. With the toolchain it was much more time consuming to actually get all the build failures fixed.

Binary compatibility with the Toolchain update
The most difficult, and at the same time one of the most anticipated updates by the whole Sailfish OS development community is the update of the toolchain. This includes an update of GCC from version 4.9.4 to version 8.3. We did not update to version 9.x or 10.x, as the work was started when the latest release by linaro/ARM was 8.3. We wanted to finalize this version before taking the next step. As mentioned also in the Hossa blog post, it is better to take smaller steps when updating complex components. While we did not get the latest and greatest, the changes are still extensive. GCC 4.9.x series was released in 2014 while GCC 8.3 is from Feb 2019. Even though the change is significant, we managed to preserve binary compatibility. All the binaries and applications compiled with the old toolchain should work just as they did before.

New code optimizations and support for the more recent C++ standard are a couple of the possibilities we gained with the update. The GCC update rebuilt the whole OS multiple times because of circular dependencies in the code, as expected. This process revealed dozens of packages that needed to be fixed. Some of the fixes were trivial, such as bluetooth-rfkill and buteo-mtp. At times we had to just take into use a fix that had already been available for the previous toolchain. This was the case for example with gst-plugins-base. There were tens of similar PR’s that had to be accomplished all over the stack to get everything built.

Some of the problems do not become visible at compile or linking time, making them very hard to notice. For example, we ran into problems with the old perl. We considered first to update perl to a newer version, but decided to develop a small patch instead. The rationale for this decision was to reduce risk for the release, as the amount of changes all combined was already considerable. In addition it should be noted that perl by default is not installed on the devices, it is in the stack because it is needed for the builds. Nevertheless we’ll need to look into updating perl later.

All things considered the toolchain update is a major step forward and with this change we will have development opportunities which we do not even know of yet. We invite you to comment and collaborate if you think of new ways or have additional ideas about how these changes will benefits us all.

Python 2 support ended
Python 2 support ended on 1st of January 2020. Python by default is not installed on Sailfish OS devices, it is used in our build environment. It also provides us the pyotherside bindings to Qt which allow developers to create Qt based applications using python. In this release python3 was updated to version 3.8.1 and python2 to the latest version 2.7.17. Having two Python versions in the stack means increased maintenance, and thus we have decided to start deprecating Python 2 and will focus exclusively on Python 3 in future.

Removing Python 2 may cause extra work for our development community, as some may still be using it. Despite this, the decision to remove Python 2 and concentrate our efforts on upgrading the stack is necessary and evident. Python 2 packages will remain in our repositories with this release and partly also on the next release as well, as removing the dependencies will take time. Nevertheless please consider moving all your code to Python 3 as soon as possible.

As a side effect of this work we were able to improve our build time, for example for dsme. Many of the dependencies on Python were not really needed, so removing them reduces the need for rebuilds.

QEMU
QEMU is an important part of our toolchain, used to compile our ARM and aarch64 binaries with x86 based machines. Over time we have experienced some problems with QEMU and it has become evident that we needed to update it to a newer version. Even though the release includes version 4.2.0 (update from the old 2.x branch), internally we conducted the upgrade in two steps, first to 4.0 and then to 4.2 release.

The change required a notable amount of work and resulted in no visible improvements for Sailfish OS end-users as such. However, developers will now be able to enjoy the new capabilities.

Library updates
Some of the updates would not have been possible with the previous version of the toolchain, as was the case with glibc which we’ve now updated to version 2.30 from the previous version 2.28.

We have also worked on different system components, such as expat, file, e2fsprogs, libgrypt, libsoup, augeas, wpa_supplicant, fribidi, glib2, nss and nspr as part of our normal maintenance work.

Included are also updates to lower level components that improve the user experience. The updated Gstreamer 1.16.1 offers better support for selected video and audio codecs. We also switched gstreamer to use ffmpeg for all SW codecs on the devices.

Technical debt installment
As part of our move towards a more maintainable system we have also been switching to use busybox more widely. In this release we moved coreutils, tar and vi to busybox. An additional benefit of using busybox is that it reduces the memory footprint of our image. With the coreutils replacement we saved ~4.2MB and with tar ~1.4MB from all device images. The vim-minimal replacement saved ~1.6MB of space from images with developer mode.

As with any platform there are times when one needs to look back a bit in order to consider how to proceed in the future. We have had our fair share of issues with statefs and we have come to the conclusion that it is not worth maintaining anymore. As such we will deprecate statefs after the 3.3.0 release. Instead of using statefs we will be moving to our other APIs. For example in future status information will be moving to libqofono that is already available in the stack. Other examples that used to require statefs are maliit and the browser.

We also started to deprecate qtaround. Qtaround is a small helper function library that is not used anymore and thus maintaining it in the stack does not make sense. We also removed other repositories and packages that are no longer used, such as cutes-js, cutes-qt5, meego-lsb, and libtalloc to name a few.

Sandboxing system services
There was also work done to further limit access to system services, which was mostly achieved using the systemd sandboxing feature. Surely this is just a small step, and we have the older systemd currently in use which does not include all of the latest features, but still provides a clear path forward for limiting our attack surface. Examples of how it was done can be seen in the mce and sensorfw repositories.

While systemd sandboxing is a small thing and currently only used by the system services, we have also been looking to provide similar capabilities for applications as well. There are no updates on the matter within this release, but there is already firejail packaging available for those who want to do early experiments. Whether we will make it part of the official API remains to be seen, and any feedback would again be welcome at together.

Changes for upcoming features
As mentioned in our earlier blog post we are working on providing multi-user functionality. This is something that has been requested by our partners. Access for different users on the same device is something that’s needed particularly in corporate environments where, for example, devices may be mounted in cars. Some lower-level enablers are already included in this 3.3.0 release.

We also noted that the community has been working on FlatPak. To help the community effort we merged libseccomp and json-glib into the Sailfish OS. We undertook internal research regarding FlatPak with our partners, and While FlatPak seems nice, the conclusion was that we do not see FlatPak as the selected Sailfish OS application bundling framework, mainly due to its high resource usage. Application sandboxing techniques need further research and we’re still looking in to the right approach.

Visible changes
Sailfish OS 3.3 is a major release including also visible changes. Here is a recap of some of them.

So quite a lot of things happened and more stuff to come, stay tuned 🙂

To celebrate the new release we offer Sailfish X with special price. You can get the offer by entering voucher code VAPPU when checking out from Jolla Shop. The offer is valid only for a limited time.

Br,
Sage

Update-historie