Qt6 available for developer preview

Platform Development
#1

Over the last few weeks, myself and @rinigus have been working on packaging Qt6 (6.7.2) for Sailfish OS

We are now at a state where the packages are usable to developers to build applications against. Packages are currnetly in an OBS repo [1], but will in time be moved to the SailfishOS:Chum repo to be easily available to all. The full list of packages is listed in this tracking issue [1], but in summary, most of Qt6 and Kf6 is available to use.

The motivation for this on my side was purely selfish, I had decided to host my music on a subsonic server, and needed an app. I chose to write the app using Kirigami2 knowing fine wwell that it would motivate me to do this (much larger) packaging exercise. I was very happy to get the offer of help from rinigus, which has accelerated the delivery of this project.

Packages install in /usr and live beside Qt 5.6 unlike Qt5.15 which installs in /opt, and maybe these packages will be useful for Jolla in the future.

The aim will be to bring existing Qt6 and KDE6 applications to SailfishOS, as well as new applications, and allow for interoperability with other mobile linux platforms such as plasma-mobile.

If anyone else woiuld like to assist, please do, file PRs, issues etc, and build apps!

Known Issues

  • Due to issues building Qt6 with SB2, OBS does not always successfully build packages. We hope Jolla will fix this issue, so until this is resolved, some packages are being built on rinigusā€™s arm64 build setup, and the packages manually uploaded into a qt6-prebuilt project [3]
  • Internal compiler error in GCC [4]

Still TODO

  • Some packages remain as per [2]

Notes

  • Applications can run using the current qt-runner
  • Material works as a nice mobile friendly style, but we will also bring the KDE Breeze style

[1] Show home:rinigus:qt6 - SailfishOS Open Build Service
[2] Packaging of Qt6 for SailfishOS Ā· Issue #1 Ā· sailfishos-chum/qt6 Ā· GitHub
[3] SDK sometimes creates files with 000 permissions
[4] GCC internal compiler error on i486

48 Likes
#2

Thanks for stubbornly continuing this update. Of course I am waiting for webengine the most :slight_smile:

Does this mean cloud money have been spent? I would like to know how to contribute to offset that.

4 Likes
#3

Few comments regarding the build status as it is now.

To see all packaged software, its the best to search for ā€œqt6ā€ or ā€œkf6ā€ in sailfishos-chum repositories Ā· GitHub . At this moment, we have 28 + 22 = 50 repositories out of which 1 or maybe 2 are not yet fully working (need extra dependencies). QtWebengine is packaged as well and worked on my device.

Packaging, as for writing SPEC, was way easier than for Qt515. As we install in /usr and donā€™t clash with Qt5 distributed by Jolla, we could offload dependency management to RPM and donā€™t have to track them manually.

The bugs already mentioned by @piggz were the main obstacle.

Compilers: on i486 (and I suspect on armv7), gcc was crashing due to internal error. As a result, we switched to clang. Clang, on the other hand, had major issues with compiling QtWebengine and KF6 packages due to the bugs in Clang (incorrect handling of stdc++ headers). So, current status is: arch64 is using gcc and we could package all in this architecture. Some clang compiled packages are available at Show home:piggz:qt6 - SailfishOS Open Build Service . I suspect that gcc bug is out of Jollaā€™s hands and we can mainly hope that it will get resolved with gcc updates.

SFOS SDK: This was a major obstacle. Basically, when compiled using Jollaā€™s SDK on PC or on OBS, builds were failing as files were created with 000 permissions. We have seen that before, but not at such scale. For Qt6Base, @piggz managed to somehow patch the code to avoid it. For the rest, we had to find an alternative. There are 26 packages that had to be built separately from OBS. Solution was to use native build containers that were updated to support such builds. While native containers support single package builds, I had to rewrite my earlier build engine TBuilder to allow us to define projects. Use of this environment is quite simple. You need to have podman and QEMU supporting arch64. After that, install tbuilder, clone project repository and start compiling. Qt6 project with the list of packaged software is at tbuilder-qt6/src at main Ā· rinigus/tbuilder-qt6 Ā· GitHub (qtwebengine is not merged into that yet).

One note regarding QtWebengine: 32-bit architectures are not supported by this packaging of QtWebengine. Its impossible to build it on 32-bit arch, maybe possible to do so through cross-compiling and using 64-bit Node. If somebody is interested in getting it working on 32-bits, you would have to look into whether it is possible and how to make it work.

Now how to proceed from here. On the building side, one solution would be to have OBS with aarch64 native builders, similar to whatā€™s used by Suse, Flathub and probably many others. That way we will avoid using sb2/mb2 and rely on hardware to do that magic. If someone knows OBS, maybe we can setup a separate small OBS cluster on one of the VM providers to test it. Or maybe use some alternative system. Although, we, as developers, are more familiar with OBS. Ideally, we would have a system that would start worker VMs only when needed for a build and keep them off when not in use. I wonder whether OBS supports it.

Alternative is to get tbuilder to support builds in container jobs. I am looking right now on Oracle Cloud as they give 3000h of free CPU time and have aarch64 supported. Negative side of making a separate build engine is that the time spent on it would probably be wasted when the proper full-build engine, such as OBS, will work. So, working towards longer term goal would make more sense.

On users side, I suggest that when we have Qt6 packages built and ready, we stop and, after a bit of time, remove all opt-qt5. Although then all 32-bit users will loose access to the more recent Qt than provided by Jolla. Note that this older opt-qt5 will probably be unmaintained with all possible complications that it entails.

PS: @vlagged: no cloud money has been spent yet :slight_smile:

16 Likes
#4

This is my current sample app using these libraries, which you may or may not have seen me post about

Im already pretty happy with it, and can stream music from home while on the go!

5 Likes
#5

awesome work, thank you all.

dumb Q from a non-dev: regarding the QT5.15 /opt - does this mean it will be easier for Jolla/SFOS to jump from 5.6 to 6.7 than it is to go from 5.6 to 5.15?

#6

Impressive work. Thank you!

#7

It is hard to judge what would be easier. So far, it has been mainly prevented by legal aspects. For details, there should be several posts in this forum explaining situation.

1 Like
#8

I donā€™t see jolla making the jump anytime soon so it would be better if they were writing a modern compositor (not tied to any toolkit) that you can run anything on it and let SFOS move forward.

Qt was the probably the biggest mistake jolla ever made.

#9

Easy to say that of todays perspective. As far as i know they adapt it from Meegoo, correct me if iā€™m wrong.

1 Like
#10

@PeegeeTips (Iā€™m also no dev) In /usr/share/ there is a directory qt5 and another lipstick-jolla-home-qt5, and also in usr/lib/ a qt5 directory, so itā€™s surely difficult to distinguish between the two ā€œ5ā€ version paths. So surely it would be difficult to distinguish the paths to the libs. Qt6 surely will have a qt6 directory, or not? (clearly distinguishable paths)

1 Like
#11

i wonā€™t disagree that i say that with todays perspective. However its been apparent for quite a while and no efforts have been made to fix this mistake. Or at least a sign that they are trying to fix it.

As a result SFOS has stagnated not because its ā€œfeature fullā€ but because it simply cant move forward.

3 Likes
#12

Very exciting to see this happen, great work by yourself @piggz and @rinigus :100: Funnily enough I had started my work a couple weeks ago on a Kirigami + KF6 + Qt6 rewrite of an audio manager / player I had originally written in GTK3->GTK4/C , and intentionally structured the project so I could have a ā€œmobileā€ Qt5-specific implementation for Sailfish. Of course, that was with the intention of it using Silica as well for that implementation.

While I donā€™t expect to see the likes of Silica ported in the near future, at least Iā€™ll know that thanks to your guys work, I can eventually tinker with OBS (or GHA?) builds for SFOS with kf6 & Qt6 target with kirigami as the UX. So massive thanks to you both! :partying_face:

8 Likes
#13

It does look like less of the maco hell with 5.15 and more like parallel installs as ā€˜we know themā€™. Can you mention which macros maybe necessary / useful? You had nice docs for the 5.15 efforts.

EDIT: and congrats you maniacs!

3 Likes
#14

So far we used:

%global qt_version 6.7.2

at the top of SPEC and then you have to put the same version under Version: . In BuildReq use it in the form

BuildRequires: qt6-qtbase-devel > %{qt_version}

Then line

%{?_qt6:Requires: %{_qt6}%{?_isa} = %{_qt6_version}}

is needed to lock qtbase version.

Other than that, all should similar. Looking forward to your first package and, after that, for PR with documentation. :slight_smile:

2 Likes
#15

Fantastic, it is exatly uses like this i woukd like to target
reach out if you need anything!

1 Like
#16

Please donā€™t remove opt-qt5. Iā€™m working on an app that
uses LQML and itā€™s Qt6 support isnā€™t there yet. Although it is being worked on.

3 Likes
#17

I guess it can stay at OBS for some time. Please donā€™t expect any maintenance of it - although that was minimal already. Hopefully they port LQML to Qt6 and we can move forward

3 Likes
#18

Yeah, ive no issue keeping optqt5 around until some future when nothing depends on it

3 Likes
#19

There are a lot of good old apps that would no more work if removing qt5 completely, isnā€™t it so? And why? Canā€™t they both live in peace and good neighbourhood in qt5 and qt6 directories, at least for some transition time, to keep old app compatibility?

#20

Right now we talk about opt-qt515 removal, not regular Silica 5.6 :slight_smile:

1 Like