Apps that haven't been ported to aarch64 (Store)

[slava]

@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

[poetaster]

Have you considered submitting them to chum?

[slava]

Have you considered submitting them to chum?

Most if not all of them are already there.

[poetaster]

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:

1. App is available for 3.4/32bit
2. App is not available for 4.x/64 bit
3. 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.

[slava]

@poetaster

What did you mean by bumping the version requirements for 32 bit?

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!

[ApB]

@slava can you also explain what will break in your apps with mandatory sandboxing?

[attah]

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!

[slava]

@ApB

@slava can you also explain what will break in your apps with mandatory sandboxing?

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.

[rinigus]

@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

[poetaster]

Ok, just because it’s available as aarch64 doesn’t seem to preclude arm7 and, for instance installing on 3.4? I just tested installing Bim (new app from jpetrell) on 3.4 (armv7 32 bit) and 4.2 (aarch64.) Both are Volla phones. That works.

But you mean if one build, the aarch64 ‘requires’ 4.x that a 32bit build cannot require 3.4, for instance, correct?

I have one app (perhaps 2) that is directly affected by this: https://github.com/poetaster/harbour-simplecrop (Imageworks). But I frankly haven’t figured out a way to build it properly for 3.4/4.2 without also building a dependency that I don’t want to manage. It so happens that python-imaging (PIL) is available in 4.x but not in 3.4. So In 3.4 I’m supplying the library (an older approach on openrepos installed it from an openrepos package) and installing it local and in 4.2 I’m using Buildrequires and installing it local. I’m doing those builds with separate spec files since I haven’t figured out how to unify harbour/chum. Well, chum would basically require me to include the library build.

Err, so I think my example is not strictly the kind of thing you are talking about. In any case, it seems like the way I built the packages allowed both to get into harbour and I have 3.4 / 32 bit and 4.2 / 64 bit covered if in the most tortuous way possible.

[slava]

@poetaster

But you mean if one build, the aarch64 ‘requires’ 4.x that a 32bit build cannot require 3.4, for instance, correct?

32-bit build can require whatever, but even it runs on Sailfish OS 2.x, Jolla Store client stops showing it on 2.x and 3.x. devices if I drop in aarch64 rpm. Because the whole thing starts to “require” 4.x

My 32-bit apps actually do run on 3.x (some even 2.x) devices because they are built on top of stable C/C++ APIs and compiled against 2.x SDK. Obviously, I want my apps to be available on all supported versions of Sailfish OS.

[poetaster]

I’m not sure why, but Imageworks, after uploading aarch64 U still see and can install Imageworks on both 3.4 and 4.2 (volla). So it doesn’t always seem to be the case that uploading aarch64 causes 3.4 support to disappear. Is it maybe only a case for c++ apps?

I’ve done a bunch of aarch64 uploads but have’t tested re-installing on 3.4. hav to be careful to disable repos

[robthebold]

Received (internet radio app) doesn’t seem to have an aarch64 version anywhere that I can find. Went to install it this weekend to give me some diversion doing lawn work and no install candidate. On the plus side, AllRadio seems to have been rebuilt a few months ago – although not by the original author, I’m glad to see it.

[cquence]

I have contacted the developer of received in OpenRepos and he provided this link that I used to install the aarch64 version of received:

Releases · sailfish-apps / Received

[robthebold]

Tuxracer! How did I miss this? Kids’ favorite game on my phone, now I gotta loan them the OnePlus One running UBPorts to play. All well and good except when I don’t have that device on hand . . .

[pherjung]

The app PulseTunnel hasn’t been ported to aarch64. I tried to compile using Sailfish IDE but I’m getting error that I don’t understand.

Thanks for helping me

[poetaster]

Added to wiki at Apps that haven't been ported to aarch64

[poetaster]

I pinged the author and added it to the wiki page.

[robthebold]

Kodi. the media player that is, not the remote control.

[walokra]

@slava

Jolla Store client stops showing it on 2.x and 3.x. devices if I drop in aarch64 rpm. Because the whole thing starts to “require” 4.x

Is this still an issue? If I want to support also older devices (I don’t personally have aarch64 device) I can’t update my apps to Jolla Store with aarch64 build? Now my apps are available from Chum because of this.