I just asked to be sure because I don’t have device with aarch64 SFOS.
If I understand things correctly, yes they should work.
No aarch64 builds situation affect Openrepos applications, too. There are several “AppNameHere (aarch64)” builds because the dev has left the scene and someone else had to just clicl the build button… Inevitable, but still makes the newestest device a lot less shiny 
Can you please elaborate? I’m afraid I haven’t followed Sailfish’s aarch64 story.
1 Like
AFAIK, there are no major issues regarding native apps and aarch64. Your average app should just work after building for aarch64, if it doesn’t do anything too fancy.
Oh, I see. Looks like the problem is that they don’t support multilib.
6cord 64bit . … 6cord
@slava
Any chance of seeing your great apps in Store for aarch64?
I could have sworn they were there, but apparently i am mistaken - or i would have poked you earlier.
bad news.
1 Like
@slava
Any chance of seeing your great apps in Store for aarch64?
I could have sworn they were there, but apparently i am mistaken - or i would have poked you earlier.
In Store - very unlikely. Even if the problem with the OS version requirements gets resolved (uploading 64-bit rpm unnecessarily bumps version requirements for 32-bit rpms too) most of my aps are soon going to be either crippled or completely broken by mandatory sandboxing.
I publish aarch64 rpms on OpenRepos and GitHub and will continue to do so. When sandboxing becomes mandatory, 32-bit rpms will have to be downloaded from there as well. Sorry about that 
6 Likes
Have you considered submitting them to chum?
Have you considered submitting them to chum?
Most if not all of them are already there.
4 Likes
Cool.
EDIT: found it in the thread above from ApB. What did you mean by bumping the version requirements for 32 bit? I haven’t been able to get anything into the jolla store since I’m using libs (new webview stuff) in one case, that isn’t even supported there yet.
I’m also wary of sandboxing, but most of my stuff won’t be harmed since it ‘can be’ sandboxed. In the long run, I think we need it, just like web browsers should not have a shared cookie jar.
EDIT2: If it IS the case that adding to harbour cripples 3.4 (or older) 32 bit versions we have a serious problem. Has anyone posted this as a bug!? Sounds like a bug since the web interfaces in harbour still claim to support older versions of the OS???
Just to note, On 3.4 (harbour on a volla phone) i can install Counter without problem. So that suggests:
- App is available for 3.4/32bit
- App is not available for 4.x/64 bit
- App can still be installed on a 3.4 device.
Well, that’s good. But @slava is suggesting if a 64bit aarch file is uploaded that won’t work? I’m confused.
EDIT3: nice work @slava having just read a bunch of code reader … live a little, learn a little.
EDIT4: and a ton of QML tips n’ tricks just in the bloody covid QML page. Someone should turn CodeReader into a tutorial. Nice.
In Jolla Store, the minimum version requirement is apparently associated with the app, i.e. there’s one requirement for all architectures. Since there was no 64-bit support prior to Sailfish OS 4.0.1, adding aarch64 rpm makes the app disappear from the store for 32-bit clients running earlier versions of Sailfish OS.
A practical example. Suppose, I upload aarch64 rpm which requires 4.0.1, and armv7hl rpm which requires 2.0.1. Jolla Store client running on 32-bit Sailfish OS 3.4 doesn’t see the app because the app now requires Sailfish OS 4.0.1 even though its armv7hl rpm can be installed (and work) even on Sailfish OS 2.0.1. Bummer!
6 Likes
Wait, it disappears - they don’t just get an old version? 
It’s no secret i have limited patience with people sticking to old releases for shaky reasons, but that’s just ridiculous!
2 Likes
Some are reading files from non-standard locations (Foil apps), some (e.g. various loggers), have to run in the privileged mode and need the tar utility (not available to sadboxed apps) to generate tarballs, some need rpm (not available either) to figure out versions of certain packages, some need D-Bus interfaces which get blocked in a sadbox (e.g. to save a contact) and so on. It’s a pretty long list. I keep discovering new breakages all the time.
Trivial apps (e.g. Lines, Counter, QR Clip and such) seem to have survived the sadboxing without any visible damage.
6 Likes
@slava - thanks for short summary! Sounds like possible trouble is coming in form of sandbox, but hopefully it will work out for regular apps. DBus is rather expected way to communicate between apps and I hope there will be a way to specify interfaces which are needed. As, for example, for Flatpak: https://github.com/flathub/io.github.rinigus.PureMaps/blob/master/io.github.rinigus.PureMaps.json#L13
2 Likes