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:
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 . . .
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.
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.
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.
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
Well said! I also do this because it’s fun, that’s actually one of the bigger drivers for me personally!
Separate 64-bit builds could be scripted easily enough (thanks, sfdk!) but still, it’s a chore. Even worse, it’s a workaround, amd the issue should be fixed on Jolla Store side.
Jolla Store is the safest place to get apps. It it causes issues like this, it drives the devs to OpenRepoa and Chum instead, and that’s not a good thing in the long run… The “homebrew” community has existed peacefully alongside the “official” store and, in my opinion, that should be the case in the future, too.
Jolla Store is the safest place to get apps. It it causes issues like this, it drives the devs to OpenRepoa and Chum instead, and that’s not a good thing in the long run…
While it is off-topic, I couldn’t let it slide.
I would argue that Chum is the safest as you have a chance to examine a code from which the package has been generated.
In the case of Jolla Store, packages are checked for installation and tested a bit, but you don’t know whether some kind of evil code would kick in later. For the sake of the argument, rm -rf ~ could be just behind if (today() > data_of_submission+5*days). As the testers in the Store do not have code, it is impossible to test for such “nice” feature if they do tests within couple of days after submission.
In practice, we don’t read through the code on Chum submissions either as there is no manpower to do so. But it would be possible to find if some complaints will start coming in.
Chum obviously has more libs under the hood, way more open API that the Store. So, while care has been taken to ensure consistency of the build environment and libs, it is possible that something can go wrong with the apps in some conditions. But I would consider Chum to be rather safe place.
So, as explained above, Chum and Store have different trade-offs in terms of safety which has to be realized. Now, if we could push into the Store submission system directly from Chum builds automatically, you could combine the both advantages as well. Obviously, marking in the Store that the package has been Chum-built as a quality sticker to convey that info to the users.
Sorry for going off-topic.
By opening the sources I kind of implicitly agree that anyone can do anything with those - changing, recompiling, redistributing under the same or a different name and so on.
At the same time (and partly because of that 
) I would appreciate if Jolla set up a system of building and signing rpms internally before pushing them to Jolla Store, as well as some sort of procedure of checking the rpm signature prior to installing the app, maintaining a CRL and checking installed packages against it and so on, to allow users to verify that rpms are actually built from the sources they claim to be built from. That would be a great step towards providing certain level of security.
So far, Chum (thanks, @rinigus and @piggz) has gotten closer to that distribution model than Jolla Store. At least one can be reasonably sure that OBS compiled the sources from the location/revision specified in the service file. And 64-bit builds of my apps are already there🤷♂️
Jolla could have chum included by letting the user enable it in the Untrusted SW section of the settings -with a big red fat warning- to make things a bit easier for the user but i don’t think that it will ever happening.
Kodi 64bit would be nice
tIDE – post must be at keast 20 chars