@slava can you also explain what will break in your apps with mandatory sandboxing?
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
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.
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.
3 Likes
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 
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.
I have contacted the developer of received in OpenRepos and he provided this link that I used to install the aarch64 version of received:
2 Likes
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 . . .
1 Like
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
I pinged the author and added it to the wiki page.
1 Like
Kodi. the media player that is, not the remote control.
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.
1 Like
It wasn’t the case for Imageworks, which I finally added aarch64 a month ago. On the other hand, I believe I compiled arm 32 bit with a 3.4 target and the aarch64 with a 4.2 target.
That is not a sustainable strategy
EDIT: and thanks for updating your apps!
EDIT2: Since this is a burning issue, I’m going to bring it up at the next community meeting.
Just to confirm, I uploaded (the app tidings) aarch64 built against the 4.2 target and armv7hl with the 3.4 target and I can install on both 3.4 and 4.2. I’ve booked myself into the community meeting.
Now to get the bugs out
My idea would be that you give your apps a new name for the 64bit build. Maybe just add a -64 suffix?
I could, but that would mean maintaining one additional build because of an artificially introduced restriction, and that’s not fun. I’m already maintaining two builds (openrepos vs harbour) for quite a few of my apps, that’s enough for me. After all, it’s not a paid job, it’s something I do in my spare time. It must be fun, there’s no other motivation. My openrepos builds do include aarch64 rpms, and if there’s no way to do it for Jolla Store then so be it.
5 Likes
That is perfectly understandable. How would you feel if someone else packaged aarch64 versions of your apps for Jolla Store with a different name? You could do what you consider fun, and someone else might consider helping with that bit fun. No, I’m not volunteering (not yet at least), just thinking that someone might