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.
I got it to build and install, and open, bit it won’t start…
error is:
[D] unknown:0 - setting levelpack “”
[W] unknown:130 - file:///usr/share/harbour
-machines-vs-machines-sfos/qml/harbour-mach
ines-vs-machines-sfos.qml:130: TypeError: C
annot read property ‘titleSound’ of null
[D] onStatusChanged:43 - Loader MainPage.qm
l status changed: Ready
[W] unknown:12 - file:///usr/share/harbour-
machines-vs-machines-sfos/qml/components/Le
velPackCarousel.qml:12: TypeError: Cannot r
ead property ‘levelPackId’ of null
I guess probably something to do with changes code on newer SF versions … Source is from 2018
1 Like
Nothing comes to mind immediately - those errors do not sound critical.
But the obvious thing to check for in the code would be hardcoded /usr/lib locations (as opposed to lib64) - the package files themselves have nothing like that though.
2 Likes
But wouldn’t that likely show up in output?
Correction:
That component uses ListView.itemAt() with an index parameter.
According to the Qt 5.6 docs that’s wrong, the method wants x,y parameters. Later Qt versions have itemAtIndex(i), but 5.6 does not.
Are you sure you’ve built the right version?
1 Like
I just built from Git zip on my phone with rpmbuild… https://github.com/mzanetti/machines-vs-machines-sfos
So using an earlier qmake might work, or, is there a way to change that line to wor with current version?
There do appear to be some ‘faults’ in harbour currently. If you upload aarch first, often you have the opportunity to upload arm, but not x86. I’ll try to document this. But it’s happened to me 3 or 4 times in the last weeks …
My approach, regardless of necessity, has been to upload 3.4 compiled x86, arm7 and then aarch. But with very few exceptions, my apps are fine as 3.4 targets (there are no security aspects, on superficial inspection). I also did trial with all 4.3 targets (QML only app) and could install on 3.4 arm and 4.3 aarch. For what it’s worth :0
1 Like
If you build from SDK it’s fine. It’s plays fine. The sdk (.pro) includes steps for copying files that probably require the sdk.
I’ll post a ticket in the original repo and add to https://forum.sailfishos.org/t/apps-that-havent-been-ported-to-aarch64 (which is a wiki)
EDIT: added a ticket and to the page. I think the files copy stuff I suggested is:
copydata.commands = $(COPY_DIR) $$PWD/data/lpbuild /home/deploy/installroot/usr/share/harbour-machines-vs-machines-sfos/data/
target.depends = $(target) copydata
export(first.depends)
export(copydata.commands)
QMAKE_EXTRA_TARGETS += target copydata
1 Like
Doesn’t seem to be any source available …
I did some minor changes to the pro file which should work on chum and on device: https://github.com/poetaster/machines-vs-machines-sfos/blob/master/machines-vs-machines-sfos.pro
Builds on obs: https://build.sailfishos.org/package/show/home:poetaster:coderus/MachinesVsMachines. (the directory is confusing, sorry).
3 Likes