It it possible add a “Getting Started” similar to:
I am a bit confused. The supersonik app does not seem to use these in its spec:
Is the " %global qt_version 6.7.2" optional?
A minimal example app with needed spec macros would be much appreciated.
qt_version
should be used only for Qt6 own libs. That will allow us later to automatically update Qt6 and KF6.
For your own apps, please specify the requirements as you find fit.
Is this a known issue when building?
File /usr/bin/qmake
from install of
qt6-qtbase-devel-6.7.2+dev1+main.20240929091800.2.ge2b0b69-1.1.1.jolla.aarch64 (qt6obs)
conflicts with file from package
qtchooser-26-1.6.3.jolla.aarch64 (@System)
File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
Continue? [yes/no] (no): no
I added the repo like this:
sfdk tools target exec SailfishOS-4.6.0.13-aarch64 ssu lr
Enabled repositories (global):
- adaptation-common ... https://releases.jolla.com/releases/4.6.0.13/jolla-hw/adaptation-common/aarch64/
- apps ... https://releases.jolla.com/jolla-apps/4.6.0.13/aarch64/
- customer-jolla ... https://releases.jolla.com/features/4.6.0.13/customers/jolla/aarch64/
- hotfixes ... https://releases.jolla.com/releases/4.6.0.13/hotfixes/aarch64/
- jolla ... https://releases.jolla.com/releases/4.6.0.13/jolla/aarch64/
- sdk ... https://releases.jolla.com/releases/4.6.0.13/sdk/aarch64/
Enabled repositories (user):
- qt6obs ... https://repo.sailfishos.org/obs/home:/rinigus:/qt6/sailfish_latest_aarch64/
No, it is not. Please submit an issue at GitHub - sailfishos-chum/qt6
We used so far environment that did not have Qt from Jolla (or much of it): OBS and build env based on containers
Done!
Thanks for the support!
FYI, working on packaging KDE Itinerary here:
https://build.sailfishos.org/project/monitor/home:nephros:devel:qt6
There’s quite a list of dependency packages for that as well, so if someone misses a dep in their app it might be worth having a look in that space.
Iff that project results in something useful, these shall be transferred to Chum as well eventually.
(The variant for qt 5.15 is here but it has an issue with some requirements so I don’t recommend installing those in general.)
I have updated Qt6 packages for aarch64. Latest version is available via the same repository as listed above.
Next
- add i486 builds
- tag all versions properly
If all works well, we can push that into Chum. After that we will trigger Qt updates.
All packages are tagged and compiled for aarch64. This time the prebuilt packages have “chum” set as a vendor. If all goes well, we can start moving all effort into chum:testing.
I wonder if a sailfishos:chum:archive
project would make sense? So we can retire packages but keep them available for some?
Do you consider compiling it also for 32 bit devices later?
We will try … there is currently a build failure in qtbase to iron out.
it may end up having one more project to admin. I would suggest to keep the packages as they are and see if we need to separate them (if they start clashing in terms of names).
i486 is fine, armv7hl not so. there were suggestions for testing the breakage during compilation, but I haven’t tested it yet. maybe @piggz will do it before me
BUT, note that we cannot compile qtwebengine for 32-bit devices. at least not using our common approach. its already disabled in fedora - source of our SPEC files. so, if the interest is to get qtwebengine on those devices, you would have to investigate and figure out how to do it.
Thanks for info… but
That’s too high for me!
Gentoo has also dropped support for QtWebEngine on all all arches except amd64 and aarch64.
And say what you will about Gentoo, but the devs do know how to compile stuff
Also, apparently building it needs more than 2GB RAM in a single process at some point when linking, so you can’t do it on a native 32bit machine and have to cross-compile.
And here comes the next phase: Qt6 has landed in Chum:Testing. Right now, aarch64 and i486
Thanks for this @rinigus … next step of app builds can now begin. I have ported the .spec for angelfish to kf6, and started making things available here Show home:piggz:qt6apps - SailfishOS Open Build Service
angelfish is somewhat working, though its quite crashy atm!
Thanks @nephros for the qt5compat package as angelfish requires this.
will try to build it too. could it be due to 41 tabs open?
One general suggestion regarding packaging: let’s try to avoid adding manual requirements to SPECs (“Requires”). If requirement comes from building with some lib, it is usually picked up automatically. So, no need for qt6-qtbase-gui, for example.
I think we shouldn’t include any requirements for qt-runner, qt-wayland and similar. Users should install qt-runner-qt6 if they want to use Qt6 and qt-wayland is pulled by qt-runner-qt6. It would make SPECs cleaner and, as a side effect, allow us to develop a community replying to each other that they need to install qt-runner-qt6 as a part of troubleshooting .
Yes, indeed. If Gentoo won’t support compiling for it, it’s not really worth doing. The few that know more about compiling on diverse hardware than the Gentoo folk (speaking in terms of distributions) are the netbsd folk: All NetBSD Packages lists the qt5 version but not the qt6 version.