armv7 AppImage progress
well I managed to buil Qt 5.12 on armv7 debian stretch (although ran into a hiccup with webengine I couldn't figure out...says it's an "internal compiler error, whatever that means" if anyone can maybe give me a tip: https://gist.github.com/ericfont/4582d4e6bfe441466bf04d4575c4e750). But anyway I am able to succesfully build musescore with webengine disabled and it seems to run fine, of course without the startcenter. So I'll try to update the AppImage script. Then the few users can run it on their Rpi 2 & 3 and their android tablets inside of a vnc or xserver program. Note: arch linux already does have 3.0 built in their distro for armv7 and aarch64, since arch linux is up-to-date with qt 5.12. But an AppImage will allow those arm users on debian stretch+ and ubuntu 16.04+ and other distros to use it too.
I don't know if it is worth to try to build on the ealier debian jessie (which is what the previous appimage was on) cause I might run into another error building Qt...and it is so hard to compile Qt anyway. Most of the small number of users who would be on arm I think will at least be running Raspian strech on their raspberries, or if running in their androids, will almost certainly use a debian or ubuntu os as new as stretch.
I'll first get the appimage built on my computer before trying to do it on Travis-CI. But one question I have is there any new way to collect the resulting build artificats off of travis-ci?
Comments
I might not bother doing the Travis-CI actually since I'm really the only tester on arm I think. So I'll just manually build AppImages for each new releases to upload (maybe to my github or wherever) for people to download.
Ciao.
Actually in the meantime I was trying during these last days of holiday to make a functioning AppImage type 2 for x86_34. At the moment I am at this point:
https://github.com/AntonioBL/MuseScore/commit/7f3dc6b3bda177fee5be3641a…
it should build and upload the MuseScore 3-dev AppImage to my bintray account https://bintray.com/antoniobl/musescore-custom-nightlies
I tried with the default updated bintray.sh and it was working, so I now tried to patch the version in MuseScore's source code and force pushed the commit.
I also wanted to try to see if the AppImageUploader was working on this build.
At the moment I used the update info automatically generated for bintray:
https://github.com/AntonioBL/MuseScore/commit/7f3dc6b3bda177fee5be3641a…
I think the changes I made in my branch would break the AppImage generation for other architectures (but at the moment they were not working even in master branch), but I don't think my modifications are ready of course for merging, yet.
Maybe you could see if an AppImage version 2 could be done also for armhf. I see that AppImageKit is available also for that architecture, but maybe linuxdeployqt should be specifically compiled for that architecture. Actually, linuxdeploy (alterntive to linuxdeployqt if used with its qt plugin) comes with a plugin for experimentally including new system libraries for running softwares compiled with these new libraries on older systems.
By the way, the bintray uploading scripts at the moment present in MuseScore sources works, but only for AppImage type 1 (provided that it is enabled https://github.com/AntonioBL/MuseScore/commit/7f3dc6b3bda177fee5be3641a… and the file name does not contain strange characters such as brackets).
Ciao,
ABL
In reply to Ciao. Actually in the… by ABL
Thanks for all this info...ill try to get an AppImage version 2 working for armnf later this week.
good to know the bintray upload is allowed...last i remembered they disable that cause we uploaded too much.
And just a note to myself, a lot of info I need to review is: https://musescore.org/en/node/280926
In reply to Thanks for all this info… by ericfontainejazz
Sorry for the confusion, yesterday evening I was wrtiting in a hurry: actually the official MuseScore bintray is not working because of the quota problem, I was referring to using the personal travis account to upload to a personal bintray account.
In reply to Ciao. Actually in the… by ABL
for x86_34 interesting new architecture :-)
In reply to for x86_34 interesting new… by Jojo-Schmitz
Ops...
If that is the only error I wrote I can consider myself extremely lucky :-)
In reply to Ops... If that is the only… by ABL
whether it is the only doesn't really matter, it sure is the funniest ;-)