Upgrading Quickbar from SFOS 3 to SFOS 5 #2

 

Yesterday we "rebooted"  the source repository, and tried to build Quickbar with the SFOSSDK.  Turns out I forgot that the SDK itself was outdated. (SFOS4 to be exact). So well, the next best thing, of course, is to update the SDK. Firing up the maintenance tool, updating it and then update the SDK was a breeze. I believe between version 4 and 5, Jolla changed ownership (from ROSTELECOM to Jollyboys). The SDK has survived this exceptionally well it seems kudos to Jolla, in comparison to what Harmattan experience was like, this is a thousand times better. 

However, the issue is not solved with the update. So more digging appears to be in order. Taking a closer look at the compiler's build steps (from the "Compiler output" window), we see the building command via sfsdk : 

<sdk_install_path>/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

it appears to be correct, referencing the right .pro file (debota-sailfish.pro; "debota" is Retoromanic for "fast" in case you were wondering). However, even tho the parameter is correct, down the line, we can see that the real make command:

 /usr/bin/qmake -qt=5 -makefile <lot of stuff we do not care about>  LIBDIR=/usr/lib64 /home/tone/checkouts/svn/debota -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

appears to be _missing_ the .pro entry. Remember, this issue carried over from SDK Version 3. It's quite interesting to see the behavior has survived. We could cludge this by removing the extra .pro files. But let's see if we can spot what eats the debota-sailfish.pro 

The command before that is (a long one, but we need that to highlight that the .pro file is missing here as well):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64
 

I would assume a similar behaviour to be spotted by others among the community. So this is either a known bug with really low priority (for whatever reason), or then its a design choice. Let's see if we can clear this up!

So as a first step (after starting the building engine), QtCreator launches:

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake" /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

which is correct and coherent to what we get from the "Projects" section in QtCreator:

$HOME.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

so QtCreator is off the hook. Let's descend one layer...by adding a set -x to the script file in 

$HOME/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default/qmak 

we can get more info:

+ ARGUMENTS=
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug'
+ ARGUMENTS= '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ export MER_SSH_SDK_TOOLS=/home/tone/.config/SailfishSDK/libsfdk/build-target-tools/Sailfish SDK Build Engine/SailfishOS-5.0.0.62-aarch64.default
+ exec /home/tone/dev/SailfishOS/libexec/qtcreator/merssh qmake '/home/tone/checkouts/svn/debota/debota-sailfish.pro' '-spec' 'linux-g++' 'CONFIG+=debug' 'CONFIG+=qml_debug'
+ /home/tone/dev/SailfishOS/bin/sfdk qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug 

and we can see that qmake also is executed with the correct command line. In fact, debota-sailfishos.pro gets passed all the way down to sfdk  .

After this, things get a little weird:

sfdk: [I] Options from environment: -c target=SailfishOS-5.0.0.62-aarch64
error: No source number 0

the first line is correct (the target is the desired one), but the second one is an error - no source number 0. Seems like an off-by-one. Let's forget about it for now, should not be too serious, hopefully.

So what happens next, is that sfdk parses the spec file, makes sure the dependencies specified in it are correctly installed; at this point, the "number 0" error re-appears; and then sfdk proceeds for the building after cd'ing into the build directory (a so-called "staged" build).
The build is started by launching qmake (again), this time to generate the correct target build files (Makefiles):

qmake -qt=5 -makefile 'QMAKE_CFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_RELEASE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' 'QMAKE_CXXFLAGS_DEBUG=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -march=armv8-a' QMAKE_STRIP=: PREFIX=/usr LIBDIR=/usr/lib64

 No .pro file is here, but you would assume that's fine, as we are in the staged build directory. and qmake should handle this correctly.

Well, 20 years of experience in the  field as told me one thing (which I call the first "rule" of development):

whenever the world "should" is involved, the assumption made is instantly and irreversably proven to be wrong, and therefore irrelevant.

So something is happening here. Lets fire up the sdk command line.

ssh -o IdentitiesOnly=yes -i <sdkinstallpath>/SailfishOS/vmshare/ssh/private_keys/sdk mersdk@localhost -p 2222

this is the way I would have done it two years (or more) ago. Nowadays, the Jollyboys have streamlined this with the sfdk utility.  So

<sdk_install_path>/SailfishOS/bin/sfdk -c target=SailfishOS-5.0.0.62-aarch64 qmake /home/tone/checkouts/svn/debota/debota-sailfish.pro -spec linux-g++ CONFIG+=debug CONFIG+=qml_debug

will execute the same build commands, and there you have it - this command line eats the .pro file entry.

 sfdk is a compiled binary. So we have to jump over to github to take a look. But this is an exercize for another day, given it's late now!

Upgrading Quickbar from SFOS 3 to SFOS 5

So the new Jolla phone has been announced! Its incredible! 13 years is an insanely long time in the world of Software; it has transformed, re-transformed, re-shuffled, re-painted, re-<enter your favourite "re-" thing here>. What has stayed? Jolla! Out of all things! To honor that, and due to my own masochism; I want to resuscitate Quickbar for the occasion! For the ones who don't know; Quickbar is a simple one-row mini-launcher app, that embeds itself at the bottom of the screen of your SailfishOS phone, tracking the most recently used apps, as well as favorites! It originated in the Meego times, back when Ovi Store was still a thing (yes yes don't worry, Ill skip the nostalgy ;) ).

But first, a bit of background. Quickbar had transitioned from MeeGo To SailfishOS; the idea back then, in the MeeGo days, was to learn about N9 and Harmattan. And for SFOS, the idea for me was to learn about Wayland, and what not of a better approach, to try to integrate a mini-widget into an operating system with a new model of Window manager (Wayland). However, maintaining Quickbar for SailfishOS has been more complicated than expected, for reasons we (might) re-face down the road. Mostly due to the simple Wayland protocol implemented in lipstick, the SailfishOS compositor; btw as we speak there is talks about redesigning the current approach by detaching the Wayland compositor from the acutal UI, this shows that SailfishOS is never static on everything. I love that, it gives the feeling of a "living" operating system!

So today I start with the basic. Getting back online my old svn (yes, svn!) repository,  checking out the sources. The svn repo was resting on an older diskstation. Luckily I still had the disks, so after plugging them into the usb to serial adapter, it was easy to recover. Getting the repo back online then was as simple as spinning up a docker container with svnserve in it. We are ready to dance!

Checking out the code took a bit since I didnt really remember the password (so had to look it up from old notes), but worked flawlessy. I then spun up SailfishOS Sdk QtCreator, opened the harbor-debota.pro project file, and gave a build and thought "here we go"; and even before I got to the end of that thought, an error popped up:

Project ERROR: gq-gconf development package not found 

Well that's a bummer. But the project was last built on 2020, so what was that, SailfishOS 3? A quick look at the SailfishOS Wikipage  revealed Rokua (3.2.0) and Pallas-Yllästuntturi (3.3.0). Feels like so long ago..Alot has changed since then (including Jolla who shifted to the Jollyboys team in the meantime! And let's not go back to how the world has changed in between...). The funny thing is, this package is _not_ a direct dependency of Quickbar; but of another project lancia (italian for launch), which is the really early and plain name for the app I had used for the harmattan version. Good times, Ovi store times..I heard they rebranded to "Apple store" nowadays. But perhaps it's just an internet meme....Aaaaanyways. 

So to go back on topic, the gq-gconf (where the hell do these names come from) package is something I have (honestly) almost never worked with. I do not recall using it, and there is no information around in SFOS. In fact, in 2026, even Gemini is clueless about it (surprise, but not really, given its information that probably has never been crawled):

(between you and me, I love the "preciseness" of the _alternatives_ that are provided) 

But perhaps the most interesting question here is, how comes the lancia project is built instead of the harbor-debota, the actual Quickbar? There is no connection between the two in any way (except for source file sharing), they sit in the same directory tree, in two separate folders...like this:

     debota \
            harbor-debota
            <more crap here in between we dont care>
            lancia

But that's really it! This will be the first knot to untie! 

So to go down the rabbit hole (just a bit), we find from the `Makefile` in the build directory : 

        SUBTARGETS    =  \
                    sub-lancia

So indeed the build tools seem to believe there is some kind of dependency between the `lancia` project as well as the harbor-debota one. This is something I havent seen around lately in the Qt World, so it _might_ be just a SFOS thing...Will have to check on the forums! But now it's late, and tomorrow is a working day! Have a good one, and stay tuned for part #2!