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 