Sailfish OS Hossa is now available

It has been a long time since my previous blog post, but I though it was time to give a bit more tech savvy update for a change. I want to open up a bit more in details how things go and the reasoning behind those actions. So without further a due, let’s proceed.

We are pleased to announce the new 3.0.3 update, which is named after Hossa National Park. Hossa National Park is located in North-East Finland in the region of Kainuu. The park is home to Värikallio, an area that has some of the most important rock paintings in Finland. The paintings tell the story of the Stone Age men that used to be located in the area, and used the water routes next to the stone wall.

The update

Hossa release is primarily a technical software release that brings many under the hood upgrades, such as the long-awaited updates for C-library (glibc), compiler toolchain (gcc), browser engine, as well as the integrated Near Field Communication (NFC) framework. Also included are a number of security vulnerability fixes, stability improvements, and better compatibility in different areas.

Maintaining an operating system is a huge effort and there are lots of things that are not visible to the naked eye. To keep the maintenance burden under control, so that we will not deviate from the upstream and do not need to start maintaining our own version of the components, at times one needs to take a step back and look at the whole picture. With the 3.0.3 upgrade, we took such a step and concentrated a bit more on the not-so-visible items. At the same time we worked on bigger items for the upcoming updates, such as file system encryption, which some of you noted being referenced in the 3.0.3 update already

This time we decided to make some improvements that our community has been asking for a while, including glibc , gcc and browser engine. These couple of components have not got much attention in a while and needed it quite a bit.

Updating glibc

Our glibc has been for some time now in the eglibc version 2.19, which was already merged a while ago back to the upstream glibc. When a component is this far behind the upstream, it is quite common that going directly to the latest and greatest version is not possible, and one needs to first look on the dependencies to be able to know this information. In addition to reducing the maintenance burden, the new glibc also brings us security improvements, as well as support for new features, such as a new version of Unicode. After checking some of the dependencies on the glibc side, we noted that the first feasible step would be to move to glibc version 2.25 version with security patches on top of it. Reasoning for this was that glibc 2.26 required at least gcc 4.9, which was not there at the time we started the glibc update. Also glibc 2.28 requires version 4.0 or newer, which we did not have yet either. Thus, the 2.25 was selected as the first step to ensure that we did not make too many changes at the same time in one release.

It should be noted though that since the branching of the 3.0.3 release we have worked more on glibc and as some of you might have already noted, we have version 2.28 in our repositories, which is coming in the next release. You can follow the progress at glibc repository. To get to such new version we had to touch on tens of different packages including e.g., m4, bison, automake, gzip, groff, iproute, libdrm, mkdevnodes, procps, qemu-usermode, qemu-usermode-static, squashfs-tools, systemd, and many others. This should give you a better picture as to why this change is not only about updating this particular component, but also about ensuring that all other components building on top of it builds properly.

Updating gcc

The second big update that we worked on was gcc, which is also lagging a bit behind in the latest releases. Because of this, and the fact that we have not been updating gcc in a while, we decided to split the update to smaller parts similar to the glibc. In gcc’s case we decided to take the first step by updating it to the latest version of the 4.x branch, i.e. 4.9.4. This gave us a bit more solid base for the platform and also more visibility of how the gcc upgrades go. Going from 4.8 to 4.9 also brought us improved C++14 support. Similarly to the glibc update this gcc update touched  a lot of components, such as, sb2-tools, buteo-mtp-qt5, maliit, listpcik-jolla-home-qt5, gdb and so on.  After this we are planning on the next step of the gcc upgrade, which hopefully will still land for the latter part of the ongoing year.

Browser engine

The last big item that improves usability is the browser engine upgrade, i.e., Gecko, which is used to render web content to the user’s display. This time the update was up to the Extended Support Release version 45 (ESR45), which we know isn’t the latest version but was the next step in the upgrade path that was relatively easy to take. By updating Gecko, the browser functionality within websites has been improved, and it is able to show the web pages more accurately. However, there are some features that we didn’t finish in time like double tap to zoom. The browser’s default user agent string was updated at the same time. If you are interested in contributing and fixing user-agent based errors you can find more information here. Like with the glibc and gcc, this browser engine update is just the first step, and the target is to take the next step in the browser engine soon.

“The update target usually is the latest version, but at times one needs to take intermediate steps so that the delta for one upgrade does not get out of hand and that one can integrate and release things earlier.”

In addition to the items above there were a few other items, e.g. updating of icu to version 63.1, which has been also pending for a while as it has had dependencies to the lower level even on package management level i.e. rpm. In this case,the dependency chain was libicu > sqlite > nss > rpm, which meant that in the worst case while doing the icu upgrade the rpm, which had dependencies to it, could stop working (similar to the problems with sqlite and nss also in the past). After looking into this particular issue, we noted that we can drop the libicu from the rpm chain, by changing rpm to use openssl instead of nss by default. In addition to libicu this also made it possible to more easily handle updates to sqlite and nss as both of those also dropped out from the rpm’s dependency chains. Similar change was done to p11-kit to use openssl instead of nss .

As explained earlier, when touching some lower level components like glibc and gcc, many other packages might fail to build because of changes in libraries, headers, paths, etc.  These of course needs fixing before the release can be pushed out. The simplest thing quite often would be to patch the component with the needed fix. However, as we have limited resources and we do not want to pile up the maintenance burden, we rather try to update a component to newer version instead of just fixing the issue with a simple patch. Surely there are always considerations needed as updating a component always brings in bigger change and risk. This is why applying the patch is preferrable when we are further in the releasing process. As pointed out earlier, the update target usually is the latest version, but at times one needs to take intermediate steps so that the delta for one upgrade does not get out of hand, and that one can integrate and release things earlier.

While some of the team worked on the bigger items like these glibc and gcc updates, there were also many others who touched on different parts of Sailfish OS. Thus we also managed to include quite a notable set of component upgrades including, but not limited to: updating of iptables to version 1.8.2, pcre to version 8.42, pulseaudio to version 12.2, shared-mime-info to version 1.12, util-linux to version 2.33.1, valgrind to version 3.14, and zlib to version 1.2.11. The aim is to have a few package updates always in each release, to keep up with the upstreams.

On top of all of the above, we also worked on reducing the image size by moving extra documentations to separate packages and unifying the packaging conventions. Also work was done to exclude some tools/libraries to separate packages, which are not needed without developer mode to reduce the size of the updates. Also tools depending on ncurses were moved to sub packages if possible, which allowed dropping ncurses from the image. Some of such tools to mention are sqlite and connmanctl, which no longer are part of the default image. However, all the tools will still remain in the repositories so that all of you who want to tinker with the cmdline have the tools still available. We also dropped e.g. kbd from the image by default to save some more space, and build e.g. our browser engine with system icu enabling also significantly shorter build time. These and other fixes saved around 15M in the Sailfish OS core.

Surely some fixes on the user interface level also got in  touching different parts like email, keyboard, messages etc. You can read more about those from the release notes and detailed change log.

Oh, and one more thing…

We did not forget Sailfish X and the XA2 device, to which we brought some very welcome fixes, such as fixing the sensor behavior when doing phone calls.  We also improved the high power drain in the wlan usecase. Also one new addition to our Sailfish OS core offering was Near Field Communication (NFC) support, which is in its first version with URL tags available with 3.0.3 hossa. For anyone wanting to give it a bit deeper look you can check the source codes of our NFC daemon and the plugin for the XA2.

Additional items to XA2 were related to improvements for the Android 8.1 App Support, including:

• Mobile data works now with both SIM cards for Andoid apps on XA2 devices
• Recently added files to the Sailfish side appear now on the Android side immediately
• System UI notifications from the Android side are now hidden (Sailfish OS to handle)
• Notification handling is now improved, new notifications will not receive grouped notifications
• SSH file transfer no longer crashes alien

Surely there are still places to improve and we are already preparing for the next set of fixes for the Android App Support, which will include at least improvements with notifications to not show that many duplicates, fix for display blank prevention so that your display stays on while you navigate or watch videos via Android apps, and initial support for clipboard between Sailfish OS and Android apps.

Br,

Sage

Ps. Let us know what you think of this more technical blog post and if we should start going into more details like this also in the future.

The post Sailfish OS Hossa is now available appeared first on Jolla Blog.