Create a Pull Request for an AppImage Travis build

[tukkek]

@probonopd can you create a pull request adding your recipe into something the project can use? You mentioned in #2556 that you were willing to make it happen as a Travis artifact build, if there was any interest. I think it's safe to say now that there is a real interest here despite that issue being locked over purely non-technical issues.

[tresf]

Reopening and splitting this off so we have a place to discuss prior to the PR.

#
# WARNING QT5 ONLY
#


#
# PREREQUISITES
#

# Optional, so package can be signed
sudo apt-get install gnupg2

# Fetch portable linuxdeployqt
wget https://github.com/probonopd/linuxdeployqt/releases/download/continuous/linuxdeployqt-continuous-x86_64.AppImage -O ~/linuxdeployqt
chmod +x ~/linuxdeployqt

#
# BUILDING
#

# Important! Setup custom "/usr" prefix, use "../target/" as DESTDIR instead
mkdir -p ../target/usr
cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DWANT_QT5=True
make DESTDIR=../target/ -j4 install

#
# PACKAGING
#

# Make skeleton AppDir
rm -rf ../LMMS.AppDir

# Clone install to AppDir
cp -R ../target/ ../LMMS.AppDir/

# Prepare the launcher
mv ../LMMS.AppDir/usr/share/applications/lmms.desktop ../LMMS.AppDir/
mv ../LMMS.AppDir/usr/share/pixmaps/lmms.png ../LMMS.AppDir/

# Cleanup orphaned directories
rmdir ../LMMS.AppDir/usr/share/applications/
rmdir ../LMMS.AppDir/usr/share/pixmaps/

# Workaround per https://github.com/probonopd/linuxdeployqt/issues/52
# export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/pulseaudio/:$LD_LIBRARY_PATH
# ^--- Shouldn't be needed anymore via https://github.com/probonopd/linuxdeployqt/commit/9a93e030cff2cb10e9e672ebb3360d30b3099c6d
export LD_LIBRARY_PATH=../LMMS.AppDir/usr/lib/lmms/:$LD_LIBRARY_PATH

# Bundle both qt and non-qt dependencies into appimage format
~/linuxdeployqt ../LMMS.AppDir/usr/bin/lmms \
-executable=../LMMS.AppDir/usr/lib/lmms/RemoteZynAddSubFx \
-bundle-non-qt-libs -appimage

# LMMS-x86_64.AppImage created

@probonopd can you nudge this in the right direction? double check my work. :)

• What's the difference between an AppDir and and AppImage? Am I doing it right?
  • Edit: I think this is working now by using the usr/ prefix per instructions. This should eventually be made optional. :)
• What steps are missing to convert the AppDir to an AppImage? Should it just spit out an LMMS.AppImage file side-by-side the LMMS.AppDir or am I using it wrong?
  • Edit: It was non-obvious why or even that this was failing due to the errors showing as warnings. Fixed.
• What exactly is $ID.desktop and how do I define it? (I assume I can use our .desktop shortcut for this?)
  • Edit: This seems to be fixed.

[tresf]

Updated. Here's an AppImage created directly from Ubuntu 14.04 adapted using our existing build process.

The above steps are still causing me a bit of grief. I'll wait to receive some help from @probonopd on Gitter or here before submitting a packaging script.

https://github.com/tresf/lmms/releases/download/v1.2.0-rc2.113/lmms-1.2.0-rc.2.portable.AppImage

[probonopd]

Hi @tresf thanks for your work on this. Sorry I wasn't able to chime in quicker. To your questions:

What's the difference between an AppDir and and AppImage?

The AppDir is a directory that contains the payload application and supporting files and has an executable file called AppRun as its entry point. It is what goes inside an AppImage, which is a self-mounting filesystem image that contains an AppDir.https://github.com/AppImage/AppImageSpec/ has more on it.

It was non-obvious why or even that this was failing due to the errors showing as warnings.

Quite possibly worth opening tickets (or sending PRs) if you think that some of the warnings should be errors. Thanks.

What exactly is $ID.desktop and how do I define it? (I assume I can use our .desktop shortcut for this?)

It is the desktop file of the payload application that you would like to execute. If you invoke linuxdeployqt with the path to the desktop file instead with the path to the binary of the payload application, then it gets copied to the AppDir top-level directory automatically.

[probonopd]

https://github.com/probonopd/lmms/blob/patch-1/.travis.yml has a work-in-progress .travis.yml file for generating an AppImage on Travis CI.

[probonopd]

The file above produced
https://transfer.sh/HKhdZ/LMMS-git.f5fa745-x86_64.AppImage
Please test, and please use the yml file linked above as an inspiration for the pull request.

[probonopd]

By the way, while I agree makeself can do many things, it's not so much about the wrapper format (be it zip, makeself, or AppImage) but how one makes the actual payload binaries that go inside what determines the "out of the box" compatibility with different target systems (distributions). And makeself needs to extract the contents of the entire archive before it can execute the payload, whereas AppImage mounts the filesystem image and then immediately starts executing the application and decompresses in RAM on-the-fly, which is very fast. This can make a rather large performance difference for large applications.

[ghost]

Using the script above, I am able to build LMMS with Qt 5.9 and make a working AppImage. ldd complained that libjasper.so.1 (a Qt 5.9 dependency) was not found. I simple ran

sudo apt install jasper-dev

and after that the AppImage built successfully.

I thought the GUI of LMMS would scale when compiled with Qt 5.9, but it didn't... From my experience, there is a flag you can set to make everything scale. Try this:

QApplication.setAttribute(Qt.AA_EnableHighDpiScaling, True)

[tresf]

ldd complained that libjasper.so.1 (a Qt 5.9 dependency) was not found. I simple ran
sudo apt install jasper-dev

Edit: It looks like the libjasper issue is a duplicate of upstream bug report probonopd/linuxdeployqt#109.

I thought the GUI of LMMS would scale when compiled with Qt 5.9, but it didn't... From my experience, there is a flag you can set to make everything scale. Try this:

QApplication.setAttribute(Qt.AA_EnableHighDpiScaling, True)

Thanks! This conversation really needs to be in #2510. Can you tell us which OSs you've tested this on, but please keep the answers in #2510 as they do not pertain to the AppImage support specifically.

---

Why are the dev libraries needed? How would Qt otherwise run without it? Generally speaking, the dev libraries shouldn't be needed for runtime loading, but rather for headers and linking against when building (and we're not building Qt).

We can bundle this library too, but linuxdeployqt should handle that, especially considering it's a Qt dependency. @probonopd is the maintainer of linuxdeployqt.

@probonopd are you aware of this libjasper.so.1 issue? Is this a know issues with the linuxdeployqt tool or perhaps a known issue with Qt5 in general?

[ghost]

I added that line to gui/GuiApplication.cpp. I compiled a LMMS AppImage with Qt 5.9. Then I set an environment variable:

$ export QT_AUTO_SCREEN_SCALE_FACTOR=1
$ ./LMMS-x86_64.AppImage

The beautiful GUI showed up. (Ubuntu 16.04)

[tresf]

AppImage support has been added to the stable-1.2 source tree. It can be performed by doing:

make install && make appimage

These changes will be merged back to master once they've been synchronized.

Due to the way the dependencies are bundled the install prefix currently must be something sandboxed, e.g. $HOME/lmms/target. It will fail if the default /usr/ location is used.

Also, this PR doesn't not handle automatic uploads of the AppImage packages. @probonopd has recommended we use a service such as transfer.sh which will hold the file for 14 days to allow for adequate testing. A barebones transfer.sh example is available here for anyone willing to tackle this: stable-1.2...probonopd:patch-1#diff-354f30a63fb0907d4ad57269548329e3R29.