Sailfish Community News, 6th May, sfdk

Subscribe to future posts here :bell:

Sailfish OS update from Jolla

The last community news generated a lot of interest and we were really pleased to get all of your feedback. We can’t give you any more updates on the Xperia 10 II release just yet, but it is coming and it’s great to see so many of you making preparations for it. And while there’s no doubting the importance of new hardware support, not all Sailfish OS developments are about the OS. Another really important piece of the puzzle is the Sailfish SDK, which has developed rapidly over the last few months.

In this newsletter we want to focus not on future features of the SDK, but rather on recent additions which some developers may have overlooked. As a result, some of this may be a bit development-heavy. We hope it’s still of interest, and if not, we will of course be covering other topics in the future updates.

As many users of the Sailfish SDK will know, recent changes have introduced a docker-based build engine as an alternative to the long-standing VirtualBox VM that has been in use for many years. Alongside this the new sfdk build tool has become the default way to build projects for Sailfish OS. The sfdk tool isn’t itself tied to Docker and has also become the favoured way to interact with the VM. Recent sfdk development has resulted in a host of new features being added.

One of the fruits of this work includes support for lightweight snapshots. A snapshot, as the name implies, is a copy of a build target¹ that can be worked in without affecting the target it was captured from. For filesystems such as btrfs that support Copy on Write, this can be done in a very lightweight way. You can use it just the same on filesystems that don’t support CoW, only with slightly greater storage overhead.

Snapshots are particularly useful for dependency management. As any developer will know, every app depends on other libraries and resources to work correctly. Some are needed at run time in order for the app to work on the phone, whereas others are needed during development in order to allow the app to be built correctly (the build requirements are often packages with “devel” on the end of their name). When creating an app, a developer will list both types of dependency in the spec file that describes how the rpm for the app should be built and installed.

When a user tries to install an app, the package manager inspects the details from the spec file and installs the packages needed for it to run. Although this all happens in the background when you install an app on Sailfish OS, many Linux users will likely be familiar with it, especially if you’ve installed things from the command line.

The same is true for the build step. As the build engine starts to build an application, it first inspects the spec file to check what the build requirements are. It installs those needed, before continuing with the build. All of this is done automatically when the build is trigged, which can either be done using one of the options in the Sailfish version of the Qt Creator IDE, or by typing the following inside the application directory² (yes, building an application from source really is this easy):

sfdk build

The developer must list the build requirements correctly, otherwise the build will fail if there are packages missing. Moreover build requirements can change over time as functionality is added to or removed from the code, so it’s important to keep the details up to date.

The problem is that in general, just like on the phone itself, once a set of dependencies have been installed on the build engine, they rarely get removed. This means the default set of installed packages increases over time. Historically, when a developer started work on a new project, there would already be a bunch of packages installed on the build engine from any previous work the developer may have been doing, but which wouldn’t otherwise be included in the default install. As a result, it becomes really easy (in a bad way) for a developer to omit a required build dependency in the spec file: the app builds on the dev’s system anyway because the dependency is already there, even though it wouldn’t work on a clean install. This can make it much harder to figure out the dependences that need to be added to the spec file.

Snapshots help with this by allowing the developer to capture a “clean” version of the build target which you can roll back to each time you perform a build. So how do you use snapshots in practice? Well, it’s pretty simple. Just run the following command to turn the snapshot feature on for all future builds.

sfdk config --global --push snapshot

Then build your project in the normal way, either through the IDE or by invoking the following at the command line.

sfdk build

The build engine will create a fresh snapshot for each project you work with. You can see the snapshots that have been created using the following.

sfdk tools target list

When you next build the project the same snapshot will be used to avoid having to download all the dependencies again. However, you can now revert back to the default target installation by removing the snapshot in order to perform a clean build.

sfdk tools target remove SailfishOS-

Now if you build again a fresh snapshot will be created and the dependencies specified in the spec file will be downloaded again. This is a great way to ensure your spec file contains all the dependencies required to allow others to build your app successfully. If you need to build and reset to the last snapshot, it can be done like this.

sfdk build-requires reset

If at some point you want to disable snapshots, you just need to run the following command. Note that if you do this you should also remove the snapshots as well, otherwise sfdk will refuse to build your projects until you do.

sfdk config --global --drop snapshot

There are other smart ways to manage your targets that have been added to sfdk recently, and which can be combined nicely with the snapshot facility. For example, check out how to set up a shared output directory using tasks, which can be particularly useful if you have several projects with internal dependencies between them. For more info about this, and more, review the comprehensive sfdk help:

sfdk --help-all

As you can see, there’s plenty of juicy new functionality to be found in sfdk, far too much to cover here. There have also been exciting new developments from the community in terms of Continuous Integration (e.g. use of runners for automatic builds on Github and GitLab), Rust usage and more. We encourage you to share all your own useful developer experience in the forum.

¹ For those less familiar with SDK jargon, a “target” is a bunch of libraries and other resources that are stored in the SDK and which mimic the resources available on the phone. Developers can choose which target to build against, depending on which phone they want their finished software to run on. For example Sailfish OS targets are categories by processor type (Arm 32 bit, Arm 64 bit, x86) and by Sailfish version (e.g.,,, etc.).

² In practice you have to set a target first. If you’ve not already done so, you can set it using sfdk config --global target=SailfishOS- (or whichever other target you prefer).

Energy from the Community

There’s been another great selection of apps, both new and updated, entering the repositories this week. Here are just a few of those that caught our eye.

Picross 2

After all that heavy dev work, you’ll be in need of a bit of a break. Luckily Picross 2 from Matti Viljanen (direc) is just the thing. Flying the flag for relaxation (or is it deep concentration?) Picross 2 is a digitally-enhanced version of the classic pen-and-paper game, which I’m sure most of you will be familiar. The numbers around the edge of the screen indicate the groups of filled blocks in each line and column, and your job is to apply the logic of deduction and elimination to establish which blocks are filled, and which aren’t. The rules are simple, but clever puzzle design can allow for a range of different difficulty levels. Matti’s version takes full advantage of the phone form-factor, with intuitive touch input, a grid that can be zoomed in and out for better accuracy (when you get to the harder levels and larger grids you’ll be thankful for that) and a variety of neat player aids to make things more enjoyable. The execution is slick with clear graphics and another example of a great app cover, but what stands out for me is the set of 103 hand-made puzzles that are really nicely graded in terms of difficulty. The most recent update gives it new translations, new animations, various bugfixes as well as a host of other new features. Get it from the Jolla Store or OpenRepos.

Weight Tracker

Weight Tracker is a brand new app developed by a team of student developers — Manon Sauvageot, Yoann Dumont and Louis Puyou — from Université de Pau et des Pays de l’Adour as part of a project management course. It allows you to enter your weight periodically to track its fluctuations over time. After adding in your vital statistics, the app will then calculate your BMI and warn you if you fall outside the recommended weight for your height (either too heavy or too light). It’s great to see that the devs have used authoritative sources for their data, with relevant links included on the About page, and also that it’s possible to store multiple profiles for different users on the same phone. You can also read about orangecat’s experiences using Sailfish OS as part of a university course elsewhere on the forum. Please add to the conversation there especially if you’re interested in helping to develop material that could be used by university students in the future to ease them into Sailfish OS development. Weight Tracker is available from OpenRepos with a plan to submit it to the Jolla Store in the near future.

Value Logger

Since we’re on the topic of recording measurements, slava has just released version 1.0.7 of Value Logger. Based on the original app by kimmoli, it allows you to record a set of values which it can then plot graphically as a set of overlaid line graphs. If you want to keep track of some data over time and visualise the results, it offers a straightforward way to both enter values periodically and get a visual representation of values and trends (a feature that would also make a great addition to the Weight Tracker app). The latest version of Value Logger includes bug fixes, new colours and improved zooming. Some of the neat features of the app include the ability to export the data you’ve collected in CSV format, dynamic scrolling and scaling of the graph, and the ability to pair parameter categories to simplify entry. This latest version is available from OpenRepos. Slava has also released recent updates to his other apps including Foil Auth, a one-time-password generator that keeps the generated secrets safely encrypted, and CodeReader for scanning QR codes. Both of these are available from the Jolla Store.


Philips were one of the early entrants into the smart home space with their line of Hue lights, first released around the same time as the original Jolla 1 phone. They’re widely available and Philips offers an open API for local control of lights via the Hue Bridge without the need for Internet access or account registration. So although not as open as some of the open source smart device alternatives, the Hue ecosystem does nonetheless offer a solid and privacy-friendly option. Sailfish has a couple of Hue control apps, one of which is Tint by attah, which was recently updated to support landscape displays and improved UI graphs. Tint makes connecting to a Hue bridge a simple process, after which all of the light details and any groups you’ve already created will materialise on your phone. Selecting a groups of lights brings up a clean set of sliders for controlling brightness, colour temperature, hue (RGB colour) and saturation. There are more capabilities too, such as the ability to create and edit groups, and it’s overall an effective way to control your Hue smart devices; very nice. Tint is available in the Jolla Store.

Please feed us your news

This is a community update, and frankly we can’t always keep up with all the exciting stuff happening in the Sailfish community. Plus, the less of this we have to actually write ourselves the better. So please help us out by posting your Sailfish news updates to the forum as a reply to this post. We’ll collate as much of it as possible into one easily digestable post for the next update.

And don’t forget to join us at the community meeting every other Thursday on IRC. It’s a great place to discuss any of the content you see here, or to share your ideas for future updates. The next meeting will be on the 6th May, full details here.


It would be super cool if the sfdk tool had manpages. Those lots of sub --help menus are confusing to me, so I only use the few commands I have in my history.

1 Like

Try this:

mkdir -p .local/share/man/man1
ln -s ~/SailfishOS/share/doc/qtcreator/man/man1/sfdk* .local/share/man/man1/
man sfdk

Additionally, run mandb afterwards so that apropos and man -K work.

1 Like

Could you please check the DESCRIPTION > Introduction section of sfdk --help and if it is still unclear then tell us more specifically what is confusing to you?

1 Like

I don’t like sfdk <subcommand> --help like stuff. Because you have to first guess under which subcommand the functionality which has to be available could be and then after running --help on that you see it’s not there and you have to search subcommands on and on. In the end you find the wanted functionality at a place which makes sense but which you didn’t expect. apropos <functionality> makes this now way more straightforward instead of spending minutes search. Additionally I personally rather prefer a super-long manpage over multiple ones.

Please help me understand why would one need to guess which subcommand to look for.

Did you miss that passing --help without subcommand gives you an overview of sfdk’s general usage, including the listing of available subcommands, each accompanied with its brief description and categorized by the domain it addresses?

Is the brief description of some subcommands not clear to you? Which?

Did you miss that passing --help-all (no matter whether it is passed with or without subcommand) shows you a how-to like manual, where you can learn in greater detail which command(s) to use and how in a particular use case?

Did you miss that passing --help-<domain> shows you nothing more than just a portion of --help-all, limited to topics under the given <domain>, for easier navigation in the bottom-to-top case, where you read subcommand help first and find the need to remind how the subcommand fits the bigger picture afterwards? (See SEE ALSO in any subcommand help.)