Integrate AppImage for Linux releases

[NaterGator]

Linus' subsurface project uses AppImage and it seems to have his seal of approval. This should help greatly simplify getting users up and running in Linux without worrying about dependencies.

http://appimage.org

[dagar]

I can't believe I haven't heard of this.

[probonopd]

Have a look at the AppImage build scripts ("recipes") of other Qt based applications:

• https://github.com/probonopd/AppImages/blob/master/recipes/subsurface/Recipe
• https://github.com/probonopd/AppImages/blob/master/recipes/scribus/Recipe
• https://github.com/probonopd/AppImages/blob/master/recipes/krita/Recipe

By building on a CentOS 6 build host, the resulting binaries are known to run on most modern desktop Linux distributions. Possibly it's easiest to clone the probonopd/AppImages repository and start from there.

I'd be happy to help if you run into any issues.

[probonopd]

How do I build this on a CentOS 6 build host?

[dagar]

@probonopd are you asking how to build qgroundcontrol on centos 6, or how to get AppImage working?

[probonopd]

I am asking how to build qgroundcontrol on CentOS 6. This would make the AppImage more portable since the binaries currently provided by the project require at least GLIBC 2.14, which older distributions might not have. On the other hand, 2.14 is not that recent so maybe we can just live with it.

[probonopd]

Here is the Recipe that can be used to generate the AppImage for 64-bit Linux.
https://github.com/probonopd/AppImages/blob/master/recipes/qgroundcontrol/Recipe

[probonopd]

And here is the resulting AppImage:
https://bintray.com/probono/AppImages/QGroundControl/view#files

[dagar]

Nice! It works on my Ubuntu 14.04 machine.

The problem is we'd need to find a continuous integration service that offers CentOS 6. We could build on Ubuntu 12.04, but we had to upgrade because of udev issues.

If you could document how to create the AppImage I'll add it to the builds with s3 and github deployment ASAP.

[probonopd]

@dagar the recipe above shows how to do it.

For other packages I am using CentOS 6.7 Docker images that I run on Travis-CI. This way, I can build on CentOS while still using Travis-CI. But maybe it is OK as it is, as long as you get no complaints from users.

[dagar]

Ok perfect. I see the script grabs an AppImageAssistant binary. I was thinking we might need to build or install it on travis-ci. Do you mind if we pull your script into the deploy directory and modify it work with the output of a freshly built release? We also need to fix the icon.

[probonopd]

Feel free to go ahead. If you like you can of course build AppImageKit on travis, but you don't have to.

[dagar]

It should be tested, but the is AppImage is now created in the builds and uploaded to s3. http://qgroundcontrol.s3.amazonaws.com/master/qgroundcontrol.AppImage?dl=0
Tagged releases will be auto added to GitHub releases

Thanks again @probonopd

[probonopd]

On Ubuntu 16.04:

me@host:~$ '/home/me/Downloads/qgroundcontrol.AppImage' 
/tmp/.mount_W7Kwcs/qgroundcontrol: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

Please see https://github.com/probonopd/AppImages/blob/master/recipes/qgroundcontrol/Recipe#L9-L24 for how to solve this.

Also, the filename should have the version. See https://github.com/probonopd/AppImages/blob/master/recipes/qgroundcontrol/Recipe#L53-L62 for how to automate this.

[dagar]

I'm pulling the debs just like your original script. I'm not sure what's wrong with it at the moment.
https://github.com/mavlink/qgroundcontrol/blob/master/deploy/create_linux_appimage.sh#L17

For development builds we're trying to only store and link to the latest good binary for each branch. Is there some reason it's important to have the version in the name for AppImage? We could do it for proper releases.

[probonopd]

Sorry, I forgot to mention that the AppRun script also needs to set LD_LIBRARY_PATH accordingly so that libraries are also picked up from usr/lib/x86_64-linux-gnu, e.g.,

export LD_LIBRARY_PATH="${HERE}/usr/lib/x86_64-linux-gnu":"${HERE}/Qt/libs":$LD_LIBRARY_PATH

As for the names, I just find it convenient to know the version something has. There is no hard technical requirement to include the name (or architecture). But if it can be automated, why not do it?

[dagar]

@probonopd can you try http://qgroundcontrol.s3.amazonaws.com/master/qgroundcontrol.AppImage?dl=0 again?

Do you know if it's possible to have an icon in Ubuntu unity for an AppImage?

[probonopd]

You added usr/lib to $LD_LIBRARY_PATH but the library is in usr/lib/x86_64-linux-gnu so it does not find SDL yet... of course it wouldn't hurt to add both paths.

Regarding the icon I am not entirely sure how this works for Unity, it does show icons for most AppImages. Can you attach an icon to your main window and would that change it?

[dagar]

Ah, I just copied your recipe. Thanks
Trying again...

[probonopd]

Yes, it was a bug in mine... updating the recipe

[dagar]

Any ideas for the launcher icon?

[probonopd]

Regarding the icon I am not entirely sure how this works for Unity, it does show icons for most AppImages. Can you attach an icon to your main window in Qt and would that change it?

[dagar]

I think it was just missing the extension in the desktop entry.
1cde874

[probonopd]

Does this result in the icon being displayed?

[dagar]

Travis-ci builds are especially slow during the day. We'll know shortly.