How to install SailfishOS SDK on OSX – the Dummy Guide

Two days ago I started to install SailfishOS SDK on my Mac Mini using the instructions from Martin Grimme published in SailfishOS mailing list. As a non-seasoned Virtualbox (or a Mac) user it took me several hours and lots of questions in the mailing list to take me where I am now. Currently I have fully functional SDK installation on my Mac Mini, and I decided to write down this guide to help others do the same. The guide will be based on the bullet point guide from Martin, but will have some additions such as tips and don’t dos from me, to avoid readers to do same mistakes I did.

Step 1: Get Linux Running on Virtual Machine

* Install VirtualBox on your host OS. Give it at least 1.5 GB of RAM. After the whole setup process, you may push this down to about 500 MB, if desired.

* Install Linux in a VirtualBox. Ubuntu 12.10 32 bit works just fine.

Give it at least 12 GB of hard drive space, otherwise it runs out when installing the SDK. Dynamically expendable should be fine. After the installation you’ll be asked to reboot Ubuntu. At least for me, the Virtual machine got stuck for ages in “The system is going down for reboot NOW!” phase, so I decided not to wait and manually powered off the VM, and started it again from the VirtualBox manager. That seemed to be ok.

* Don’t forget to install the guest additions as well, because we will have to use shared folders.

You can install them from the Devices menu, selecting Install Guest Additions.

Step 2: Get the SDK in it

* Install VirtualBox on Linux and install the Sailfish SDK afterwards.

Select 32 bit version of Sailfish SDK, if you installed 32 bit version of Ubuntu. After you’ve downloaded SailfishOS SDK run
sudo chmod +x
to make it executable and start the installation

* The suggested installation path /home/<user>/SailfishOS is fine. Do not install the SDK into a shared folder as shared folders don’t support creating symlinks.

Step 3: Get the Virtual Machines Out of It

* Open the VirtualBox configurator on Linux and export the two virtual machines ‘MerSDK’ and ‘SailfishOS Emulator’ by selecting ‘File -> Export Appliance’. This will take some time. Move the resulting .ova files to your host OS (Mac OS-X in my case).

* Create a directory ‘MerHome’ on your host OS, e.g. /Users/<user>/MerHome. Inside MerHome, create three directories:

– emulator
– mersdk
– projects

Now you have to copy stuff from your virtual machine to your host OS. I used shared folders for that. You can share folders from your host from the virtual machine shared folders settings, and then mount and unmount them in Linux
sudo mount -t vboxsf mount_name mount_point
sudo umount mount_name

* Copy the SailfishOS/emulator/ssh directory from Linux into the just created directory ‘MerHome/emulator’ on the host OS.

* Copy the SailfishOS/mersdk/ssh directory from Linux into the just created directory ‘MerHome/mersdk’ on the host OS.

* Copy the ~/.scratchbox2 directory from Linux into the just created directory ‘MerHome’ on the host OS.

* Open a terminal on Linux and pack up the targets directory:

cd SailfishOS/mersdk
tar -czf targets.tar.gz targets

* Move the file targets.tar.gz to your host OS into ‘MerHome/mersdk’ and unpack it there:

cd MerHome/mersdk
tar -xzf targets.tar.gz

Step 4: Get the Virtual Machines on Your Host

* Open the VirtualBox configurator on your host OS and import the two recently exported VirtualBox appliances by selecting ‘File -> Import Appliance’.

* Edit the shared folders settings of the ‘MerSDK’ virtual machine:

home -> <your MerHome>
ssh -> <your MerHome>/mersdk/ssh
targets -> <your MerHome>/mersdk/targets

* Make sure that you don’t change the mount names during this action.

Be careful with this one, cause I managed to change “home” to “MerHome” even without touching the target name.

* Edit the shared folder settings of the ‘SailfishOS Emulator’ virtual machine:

ssh -> /emulator/ssh

Make sure that you don’t change the mount name during this action.

* You may optionally also want to activate audio while in the ‘SailfishOS Emulator’ settings.

* Test-run the MerSDK virtual machine on the host OS. Does it come up with the message ‘mounted home and targets successfully’? Then the shared folders settings ought to be OK. Close the virtual machine (saving machine state instead of shutdown is fine).

Step 5: Prepare your workspace

* Add the directory ‘MerHome/projects’ to the shared folders of your Linux virtual machine. This may be done while the machine is running.

* In your Linux home directory create an empty directory with the same name ‘projects’.

* As root, add the following line to /etc/fstab on Linux:

projects /home/<user>/projects vboxsf rw,uid=1000,gid=1000 0 0

Replace with your username and use the GID and UID of the user. On Ubuntu, the first user normally has GID = 1000 and UID = 1000.

If you have multiple users or groups, or want to be sure, you can double check them using id tool
id -u <username>
id -g <username>

* As root, mount the projects shared folder:

mount projects

* Open the VirtualBox configurator on Linux and change the host keyboard key in the global settings to something different than on the VirtualBox on your host OS.

Step 6: Fake VBoxManage Output

* Start the two virtual machines on Linux with the VirtualBox configurator. They will be very slow (as you’re running VirtualBox inside VirtualBox), so you need to have some patience until they’re fully loaded. Fortunately this has to be done only once. You will later never have to use VirtualBox inside VirtualBox again.

* Record the output of VBoxManage that the Sailfish SDK expects:

VBoxManage showvminfo MerSDK --machinereadable
VBoxManage list runningvms
VBoxManage showvminfo “SailfishOS Emulator” --machinereadable

The names of the record files contain the md5 sum of the command, so
they must match exactly.

* Stop the two virtual machines.

* In the Linux virtual machine, locate your VBoxManage program. On my Ubuntu installation, this is ‘/usr/share/virtualbox/VBoxManage’. Become root and move the file to VBoxManage.orig

On my installation, the binary was found from ‘/usr/lib/virtualbox/VBoxManage’.
If you don’t find it from either of the locations, you can locate the binary using find:
find / -name "VBoxManage" 2>/dev/null

sudo su
cd /usr/share/virtualbox
mv VBoxManage VBoxManage.orig

* Save this script as VBoxManage. It will record the output of VBoxManage and later replay that output for the Sailfish SDK.

#! /bin/bash

VBOXMANAGE=`dirname $0`/VBoxManage.orig
COMMAND=`echo “$@” | md5sum | cut -d” ” -f1`

if [ ! -f ${RECORDFILE} ]; then
exit $?

Dont forget to give the script executable rights:
sudo chmod +x VBoxManage

Step 7: Finalize the installation

* Start the two virtual machines ‘MerSDK’ and ‘SailfishOS Emulator’ on your host OS. Their performance will be far better than inside the Linux virtual machine.

* Make sure that your host OS runs a ssh server. Find out the host IP and connect to it from Linux, tunneling the ports used by the SDK.

From Mac OSX you have to tick “Remote Login” from System Preferences -> Sharing to start the ssh server. You can then find out your ip using ifconfig, or use your mac’s local name.

ssh -l \
-L 2222:localhost:2222 \
-L 2223:localhost:2223 \
-L 8080:localhost:8080 \
-L 10000:localhost:10000 \
-L 10001:localhost:10001 \
-L 10002:localhost:10002 \
-L 10003:localhost:10003 \
-L 10004:localhost:10004 \
-L 10005:localhost:10005 \
-L 10006:localhost:10006 \
-L 10007:localhost:10007 \
-L 10008:localhost:10008 \
-L 10009:localhost:10009 \
-L 10010:localhost:10010 \
-L 10011:localhost:10011 \
-L 10012:localhost:10012 \
-L 10013:localhost:10013 \
-L 10014:localhost:10014 \
-L 10015:localhost:10015 \
-L 10016:localhost:10016 \
-L 10017:localhost:10017 \
-L 10018:localhost:10018 \
-L 10019:localhost:10019

This ssh connection needs to be established all the time while you’re using the SDK.

* Start the Sailfish SDK QtCreator on Linux. It should be able to connect and use the virtual machines on your host OS now. You cannot start the virtual machines via QtCreator, though.

* IMPORTANT: Your Sailfish projects must all reside in the projects shared folder so that the MerSDK virtual machine will be able to find them.

Now you are ready to test your connection to the emulator in QtCreator.


If you’re seeing port 65535 in the ssh setting in QtCreators devices settings, go back to step 6. Probably something has gone awry with the VBoxManage recordings, and QtCreator cannot see the running SDK VM’s.

If the previous is not a problem, and the device connection test goes well, but you still see errors like “SailfishOS Emulator is not running”, you can try to hit “yes” when QtCreator asks if it should start the simulator, even if that does really nothing. Also it might need some certain combination of build/deploy/run to get your project run on the emulator, and QtCreator stop whining about not finding the SDK, but patience is good, and I hope you will have less problems with that than I did.

And finally the image I sent to Twitter, as soon as I got it working. I was pretty exited 🙂



Themes for Harmattan – Part 3: Using C-OBS and submitting to store

In last postings I’ve been telling how to create custom theme for Harmattan, and how to change between installed themes with ThemeChanger tool ( by Leimu). Also how to create valid debian packaging for the theme and preparing the package to be built in OBS. This is the last part of the themes trilogy and will give a quick guide for using Community OBS (, or OBS in general.

To get started with Community OBS, you need to contact either X-Fade or lbt #meego@freenode on IRC. Kindly tell them about your project and ask for either of them to enable your C-OBS account. You have to have existing account to have your C-OBS account enabled, the same credentials will then work in C-OBS.

There are two ways to use C-OBS, the web interface and OSC tool ( There are plenty of tutorials on how to use OBS with OSC, like this here: Also I’ve found this cheat sheet very usable: when dealing with OSC. Instead of OSC, this tutorial is focusing on how to use OBS from the web interface.

When you login first time to you’ll see five large icons showing up your quick options. Because we want to create a project to build the custom theme, we select the fourth icon New Project. This project is going to be one of your subprojects of your Home Project. Now you have to give a name to your subproject and a little description of what it’s about. In my case I created project called “themes”. The next hierarchy level under subproject is Package. You can add multiple packages under one subproject, like I’ve done with both of my themes. When you have your new project ready, you can start adding Repositories to build your project on. This time we are adding only Harmattan repositories. It is usually wise to create separate subprojects for different target repositories, especially if their packaging differs from each other, like in case Harmattan vs MeeGo. If I would build these same themes for MeeGo also, I would create another subdirectory for them. This reminds me of something, if I’ve known this from the beginning, I would have named my theme subproject as themes-harmattan, so I could name the other one themes-meego.

Let us have some target repositories. To add one, select Repositories tab from your new subproject view. Select Add Repository in the repositories view. There are two ways to add a repository, either with simple interface or with advanced interface. Only some repositories are available through the simple interface, Harmattan is not one of them. To add Harmattan, you need to select  pick one via advanced interface. Start typing “harmattan” to the project search field, and it will complete with you some options. Select MeeGo:1.2:Harmattan from them. Leave Repository field intact. In the New name field you can give a new shorter name to the repository for your own convenience like simply “harmattan”. From architectures, tick armv7el only, and then press Add repository.

Now you’re ready to upload your package. Go to Packages tab in your subproject view and select Create new package. You have to give a name and description to your package. When you’re done, you can start uploading files. For that, in your newly created package’s main view, select Sources tab. In the last part of the tutorial we test built the package. Now you will need part of the side products of that build. If you don’t have them anymore, you can rebuild the package to regain the needed files for OBS. Only two files you need for building for Harmattan are the source tarball (file with .tar.gz suffix) and .dsc file. They should be found from the one directory up from your build directory. You can now use local file upload feature of the sources view to upload those two files to the OBS. Once you’ve done with the upload, OBS automatically triggers a build when it notices that those files needed for build are both present. To check the build progress, you can return to main view of your package selecting Overview tab. Build status box on the right should show build status for your target repository. If the status is not “building” you may need to click the reload status icon. If you can’t see your repository in build status box some extra work is needed, this has happened to me a couple of times. It means that the selected architecture was not successfully applied to your repository. To fix this, go to Repositories tab. There you see your repository and a note which says that these repositories are inherited from your subproject. Now select the link to your subproject, in my case: home:matrixx:themes. There you see your configured repository again. Select Edit repository from architectures, re-tick armv7el and click the Update button. If everything did go well, you should now see your package under Packages tab building nicely against Harmattan target. If build fails, go back to last tutorial  and check everything is in place. The usual suspect when something fails has been in my experiments, the build dependencies. OBS is much more pickier with those than scratchbox, so you might have a perfectly building package in scratchbox, but not in OBS. When package has “succeeded” build status, you’re ready to add some extra stuff for the app store submission.

The extra stuff needed for the app store submission are described here: Shortly, you’ll need at least one screenshot and icon. Screenshot name should end screenshot.png and the icon needs to be named icon.png. Harmattan category section we already covered in the last post. In addition, your package needs to have a proper description. The submit process is highly automated, so it’s important to have that info, and also screenshot and icon names correct to pass the automated tests. The extra files are added same way than the package files themselves, through upload system in Sources tab.

The actual submission is done according to this guide: Briefly: Go to your package’s main view and click Submit package. You are now asked to fill in the repository where you are submitting, type in: MeeGo:1.2:Harmattan:Apps:Testing. Do not tick the empty check box. After you have submitted your package, you are forwarded to request follow-up page. There you can happily wait a while when refreshing the page and wait the your request changes state from New to Accepted. There should be some email notifying you in certain states of the test run, but I’ve so far received none, so I don’t expect you also getting any. If you are using IRC, you can follow your request on #meego-boss @ freenode, where bot is spamming with all the things happening on C-OBS at anytime. If the request fails, the request page or the bot will tell you what went wrong (missing metadata, name, description…). Everything can be fixed and resubmitted with the same steps. Once the request is Accepted, your package will show up in in the same category you selected for your package. This is a staging are for all the applications which were accepted to Harmattan testing repositories. They have to go through the Community QA review process, where they need to get 6 positive reviews to be promoted to .

From you can also download the Community Apps client if you dont have it already. It lets you browse and download apps in While waiting for your app to be promoted, you can do others a favor and rate/review the other goodies waiting in the testing area. You can browse and install also the apps in the testing area with the Apps client by installing appstestingenablerharmattan package on your device. After installing the Community Apps client, it should be possible to install the package via apt-get. Now you can give those goodies a shot and review them with a same go.

I hope this whole shananigan did make any sense, and I will see also other themes in the store soon. There’s already a request from @knobtviker to create a Tron theme, just for lulz 😀

Themes for Harmattan – part 2: Packaging and building

In last post I started series of HowTo create a custom theme for Harmattan, from scratch to the community app store. This is the second part where I’m going to share some tips on packaging, and going through usage of Community OBS, step by step. I just taught myself to use Community OBS for building my apps and I must say, it’s about the time, OBS is really a great tool!

Now, if you are following these postings to create a custom theme, after the last post, you should have a theme ready for packaging. If you are already familiar with Debian packaging, you don’t need any guidance, but this is for those you aren’t that familiar yet. The minimal proper debian package needs only few files to guide how the package is built. Those are called control, rules and compat. In addition you might want to have changelog, copyright and readme. For packages that don’t actually need to build anything, but only extract files from the package to their rightful locations on the device is a handy tool called CDBS ( . I got this tip to use such tool from a friend of mine, Juho, and thanks to him, I have to spent only a minimal time for the packaging process. The advantage of this tool is that you don’t need custom Makefile for your project, and also only two lines in rules file instead of normally needed few to tens of debhelper macros. As con sides, you have cdbs as an extra build dependency, and also you need one extra file to tell, what to install and where to install.

All the packaging files should be placed in a directory called debian, in your project directory. Easy way to create a skeleton for the package is to take some existing package and copy files from there. Another way to create the skeleton is to use QtCreator. Start new project on Qt creator, any kind of project will do, as long as you use the name of your upcoming package as a project name. Then add Harmattan as one of the build targets. Build the skeleton project once. After that, you can delete everything else, but things inside debian folder. Now you can move your theme stuff inside that new project folder and you have a skeleton packaging files. After creating skeleton, with either of those methods, or from scratch, you can start from the easiest file, compat, and change the compatibility value to 7, if it’s not already it. The second easiest file in this case is rules, normally it isn’t, but this time you can remove all the other lines but leave these two:

#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/

For the control file, you need a little bit more work to match the info with the ones for your package; name, version, category, homepage url, maintainer etc. One thing to notice at this point is that when packaging for Community app store,, you have to follow packaging rules which are mentioned here in section 1.4:

The last file you are going to need for packaging is the .install file. It should be named according to your package. If your package happen to be name “mytheme”, then the .install file should be mytheme.install. The example installation lines I have in one of the theme packages are following:

funkyocean.desktop /usr/share/applications/
index.theme /usr/share/themes/funkyocean/
license.html /usr/share/themes/funkyocean/
icons/* /usr/share/themes/funkyocean/meegotouch/icons/

At simplest, it tells where to install .desktop file (more of desktop file in a bit), theme index file, license and the icons themselves, wildcard can be used to indicate to install all the icons which are in the icons dir of your package. The desktop file includes info of your application. The guide to create valid desktop file you can find from:

Here’s a couple of lines I added to my theme desktop files to prevent the package icon showing up in homescreen. I’m not sure if they are both needed, and you can experiment by having only of them, but here they are anyway:


Now you may want to add some license, I’ve used one of the Creative Commons licenses. Changelog is also good to have for your release, especially if you are updating the package, it’s nice to have a description of what has been changing between current and last version of the package. Format for changelog you can find here: Now you are ready to test-build your package for sending to OBS for final build. Apparently this came out too long to have OBS n00b guide as is, so I’m leaving it for the next post. That’s how it always is with debian, nothing comes out short, not even with great helper tools..

HowTo: Custom theme for Harmattan, from scratch to Community App store

There is something I want to share with you. I’ve been lately tinkering on customizing Harmattan to look like it’s _my_ phone. There was a time when Widgetsgallery demo app was included in the Harmattan image, and it had a feature which allowed changing between installed themes. Now the app is gone from the image, but the source is still available in gitorious. I decided to bring the most useful feature back and assembled a dedicated theme changer application, taking advantage of the LGPL source of Widgetsgallery. The ThemeChanger app ( by Leimu ) is currently downloadable from Community OBS. Here’s quick instructions how to do it most conveniently from your device:

Add a file named themechanger.list to /etc/apt/sources.list.d/ and write this line to the file:

deb ./

Now you can apt-get update & apt-get install themechanger.

If you would like to test the ThemeChanger app out, you’ll need at least one custom theme installed to your device. You can download the ones I did by adding this repository to your device:

Add a file named themes.list to /etc/apt/sources.list.d/ and write this line to the file:

deb ./

Now you can apt-get update & apt-get install either funkyocean or purplehaze packages.

Here’s how they look like:




To create your own icon set, it’s easiest to see what one of those have been eaten. All the installed files are found under /usr/share/themes/funkyocean/ or /usr/share/themes/purplehaze/.

Basically the minimal you have to have is the index.theme file and the wanted amount of icons. My icon set includes icons for the basic pre-installed applications excluding games. In your icon set it’s possible to have more or less icons, depending of your choice. Complete instructions on creating a theme and how to use the ThemeChanger tool is located here:

When you have all the icons (sized 80×80 pixels) ready for your theme, it’s time to create packaging for the set. Easiest way to create a debian package which does not build anything, just installs the icon set files, is to use cdbs tool which is installable in scratchbox. When your package is complete, you can create a project in Community OBS. I’ll continue with detailed instructions on packaging and with instructions for using C-OBS for n00bs like me in the next posting.


Recently I finished my previous project, a Yammer mobile client called Mash. Actually I didn’t really finish it, it’s more like stuck. I published versions for Symbian^3 which is now available in Ovi Store, and also published a version for MeeGo Harmattan, which is still in Q&A while writing this post. N900 has totally lost my home wifi which makes testing the software with it quite challenging. Also for any fun, a friend told me that even reflashing don’t take the problem away, something to do with mac addresses. I could port the client to upcoming Qt Lighthouse Android port, but I don’t own any Android devices, probably making that target secondary for now. Only thing to do is to port the app to MeeGo tablet and netbook which might take a day or two.

It starts to get me feel a bit happy, but empty when the project is almost ended, and now I needed to come up with something else. For a big while, I’ve been pondering of starting a new open source project, and that’s where my new hobby, geocaching did me a favor. I noticed that has a comprehensive list of  utilities provided for geocaching by different parties. Even if the list was long, I noticed the absence of support for Nokia devices there. They are serving the masses from their perspective, which usually means support for iPhone, Android and BlackBerry, are there others? No, at least that’s how some people think. I decided that this is a good spot for me to check in. I investigated a bit and found out that is soon going to publish an API, which is already in beta testing and used by the apps mentioned earlier. Using those API’s will also provide a seamless (paperless) geocaching experience for those users who knows that there exists also Nokia phones.

Even though the API is not available yet, I already started a project: OpenCache. Naturally it’s going to be done with Qt, since it nicely gives the possibility to port the application to multiple platforms including MeeGo tablet & netbook, MeeGo Harmattan, Maemo, Symbian^3, and possibly Android. It’s going to utilize QML in the UI as much as it can, and the rest is going to have Qt/C++ under the hood. I already took a closer look at Qt Mobility’s location / positioning API and found it very suitable for this mission. OpenCache can be targeted for every mobile phone which runs Qt and has GPS. They are not too strict requirements, are they? I even saw someone saying at IRC that Qt Core is already ported to iPhone and porting Qt Gui is in progress, so here we come! More targets, yummy targets, omnomnom.. Ok that’s enough, even getting ports for N9, N950 and newest Symbian phones would be cool enough for me.

So, what is it, the OpenCache, it lot depends how broad will be the API. Because I have no idea about that yet, we’ll play how it would go, if everything I need would be available:

1) The navigating, the most important feature of the app would be navigating. This could be actually do without the API, so it’ll be done anyway, even if the API will never be published. I’ve previously used which ever Maps application comes with my Nokian. It’s very good for what’s it meant for, driving with car, or walking. Well, walking is what we need also in geocaching, but hey, Maps thinks you should walk in the sidewalk, not in the forest! It works very fine until you go out of track, and it’s very difficult to find precise coordinates, especially when the update interval of your current position is very long. That’s where own navigation system will come handy. The idea is also to combine a compass, I think most of the middle and high end phones has it built in. The map view would update your position with a smaller interval and also will show an arrow like guiding with a  distance to find the precise place set by coordinates.

2) The cache locations. At the moment,  I haven’t found a way to save landmarks to Maps’ favorites other than inserting coordinates by hand. Also noticed that one of my test platforms can’t even do that simple task decently. The format available from is .loc which seemed to be xml based format, simply offering cache name, coordinates and unique waymark identifier in the geocaching world. Coordinates were already in NMEA standard format which Qt also uses in its positioning classes, so no conversion needed there. We just need to offer a simple way for user to download cache info to the device and for use of our OpenCache app. Very probably the API will provide a nice and simple way for doing that, but if now, they can be even now downloaded from the site, one by one. Some nice categorized folder system would be needed to have easy access to caches of users choice.

3) Cache logging. When you find/not find  a cache, you need to log it. Also if you grab a Travel Bug or Geo Coin with you, or drop either of those to some cache, you need to log it too. Our mission is to provide simple and nice UI for logging these things quickly and painlessly.

4) User info, this is not mandatory content, but would be nice if user could see his stats. Depending of the API, all info available through that could be shown to user.

5) Proposed content: Mystery Helper. Some caches are so called Mystery caches and there are some math, equations and multiple coordinates involved, which needs some paper to solve at sight. It would be nice to replace the paper and create a helper utility to manage the different parts of the mystery, and solve the final coordinates with user given data. This tool would be totally extra, but if everything else is together, it would be nice bonus to provide it on top of the basic tools

I think those were the main points of the idea. For most of the graphics, existing icons would be utilized, or atleast they are kept recognizable, since they are already almost “standardized”  in the world of geocaching.

Oh, and did I forgot to mention it’s gonna be free.. Yeah I did, but have to say it again, just in case. The existing apps for iPhones and such were paid apps, and what would be nicer we could offer from the homeland of Nokia, for users of Nokian phones, free tools to make moving outside more fun.