I just checked availability of apps on my Jolla C, which happens to be left on SFOS 3.1, It shows an old version of SeaPrint from before it started to require 3.4. And i was going to say “and later 4.x”, but at least according to Harbour, the current version is compatible with 3.4. (And i always have built with the latest build engine, even EA once or twice - which might not be so smart, but that’s what i have done).
@slava, @rinigus: My thoughts are in this direction, git → obs (signed) → chum → harbour. We can’t get around signing if we want to take this ‘seriously’.
I’m doing ‘extra’ work to try to ease the initial experience people have (since harbour is the first impression). But in the long term, obs/chum does make things a lot more fun, even if only because it’s fast and works directly from auditable code.
A stupid question. Should one just leave old build up? I’ve generally been removing them (since often bug fixes are involved) . But I’m just making myself more work, or? It’ ok for the divide is 3.4/4.2, 32bit/aarch64 at the moment…
AFAICT the harbour webpage is just a submission form, Jolla hangs on to several if not all versions submitted. 3.4 downloading now - let’s see what happens.
Edit: latest SeaPrint shows up, installs and starts just fine on my Jolla C, now running 3.4.
No artificial 4.x requirement there 
(despite all 3 packages having been built built with 4.2.0.19EA).
I would love this also. Editor by @GoAlexander is very nice, but needs some usage/controls improvement.
The problem I found with tIDE when I tried to build for aarch64 is outdated code. It would build and install, but menus are not showing because of some deprecated element…
I just added it it to the wiki at https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64 and someone has already made a ticket about the bug.
Can we get downloads from the Jolla Store that are 32-bit packages? Seems like a ton of stuff is missing in 4.3 that was there in 4.0 (it’s been a while since I actively used SFOS)
i wanted to build armadillos tasklist for aarch64 and provide it via obs
i did stumble over 2 points:
- missing keys for dropbox api and how to provide them as secret in obs build
- it depends on a third party package:
include(“qtdropbox/libqtdropbox.pri”)
i did open already an thread for problem 1 and got now answer so far.
for problem 2:
should / shall we include this lib as separated package and if yes how ?
http://lycis.github.io/QtDropbox/
Re separate lib: you can package it separately in the project. Then you could add library RPM as a build dependency in your package and just have that package in the same project. For example, Chum has rather large number of libs already that are used as dependencies for end-user apps.
Noarch apps (qml-only) still works at aarch64? I don’t need to recompile them?
will try that, never defined a spec file from scratch before.
i have installed tasklist on my xperia 10. dropbox integration seems to fail. i can not login.
qtdropbox lib is like 5+ years old. doubt that it still does work
i have just installed sailkick arm version on my gs290. it.ist qml only
I liked cSMS, wish it had a 64-bit application… Or at least we had backward support for 32-bit libraries and binaries…
@slava Would you please humor me and explain once more? Because i’m obviously thick.
Hopefully we can pester the Store keepers (Harbour masters?) at another community meeting, but to do so effectively i need to understand.
I have SeaPrint built on latest build targets for all architectures, showing up and working just fine on down to and including 3.4.
3.3 and earlier get an old version, so no hiding going on that i could find. Are there some circumstances i’d need to hit for this to occur, or are you talking about new apps only?
My assumption is that the 3.4 cutoff is from gcc8 and library uplift rather than specifically aarch64.
Although obviously related, since no aarch64 target existed with the old compiler and libs, and if the system just takes the highest requirement for all the effect is the same.
Is this the core of the issue, or are there more things to it?
GCC 8.3.0 may very well be the reason of some/many apps missing…
The best Jolla could possibly do, is plead the developers to re-compile their apps. Jolla is a “store front” here and not in any way responsible of keeping the apps up-to-date, even architecture-wise.
Chum is marvellous piece of engineering in this context! It’s not quite fire-and-forget, but somewhat close anyway! (I still should find the time to move some of my projects there…)
I’m not talking about apps not showing up for aarch64, that is just the architecture indeed.
I was trying to understand the reasoning for deliberately not publishing aarch64 apps in Store as laid out previously in this thread. It was said it comes with too much exclusion of people on older versions, with the reason here being one (Harbour-)enforced minimum SFOS version across architectures for each app.
When I remove 64-bit rpm, the lowest version in the “OS version limit” drop-down list is 2.0.0. When I add 64-bit rpm, the lowest version becomes 3.4.0 (apparently by mistake, I was told that it was supposed to be 4.0.1).
I want the lowest version to remain 2.0.0 because my 32-bit rpms are compatible with 2.0.0. It’s absolutely safe because there’s no 64-bit Sailfish OS 2.0.0 and will never be.
There are many ways to fix this problem (the easiest one is probably to calculate the lowest compatible version only taking 32-bit rpms into account) but it’s apparently not perceived to be a problem on the Jolla Store side. From my side, I don’t feel much of a pressure to make 64-builds of my apps available in Jolla Store. So things happily stay the way they are
2 Likes
The Machines VS Machines game.
Apparently it’s a game that comes from Ubuntu.
I have posted a message in the app comments in Jolla store asking for a 64bit version a while back but there has been no answer so far.
Avia flight search doesn’t exist for 64Bit.