AppImage Linux package for OpenHantek

[jan-kleks]

Maybe it would a good idea to provide an AppImage package for OpenHantek? It could be a nice way for using the latest version (and this could possibly mean more testers...) without messing around with the source code thanks to AppImage's simplicity.

Hopefully, OpenHantek will make its way to popular repos as well, but having a simpler more distro-agnostic method of installation would've been really useful. And let's not forget that, for instance, Krita is available in repos as well as an AppImage package which is without any doubt comfortable.

[davidgraeff]

Or snap or flatpak. But someone need to write the script to auto generate those packages.

[probonopd]

Please try https://transfer.sh/me9v8/OpenHantek-949b427-x86_64.AppImage (download link valid for 14 days). I don't have a compatible device so all I am getting is this:

If it works, I will send a pull request that will build an AppImage on Travis CI automatically.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[jan-kleks]

@probonopd That was quick! Thank you! I should be able to test it this week.

@davidgraeff What do you think? I'm not saying that flatpaks and snaps aren't interesting, but this list looks really tempting, doesn't it?

[davidgraeff]

I don't mind adding scripts to the repo to generate flatpak, snap, appimage files. I would prefer a build-system (cmake) integrated solution if possible. At the moment you can do: make && make package to automatically generate deb/rpm/sh files on Linux.

[jan-kleks]

@probonopd @davidgraeff Finally, I got around to test the AppImage package and it seems to work fine. Thanks again!

If there is a way to generate such packages automatically, IMHO the project could really benefit from this...

[probonopd]

If there is a way to generate such packages automatically, IMHO the project could really benefit from this...

@jan-kleks I have sent a pull request to do this.

[davidgraeff]

Hm, the pull request actually exactly confirms my reservation against all those one-file approaches. Either snap/flatpak/AppImage work with the installed base system (especially libstdc++ and libgcc) or the approach is flawed.

I'm not happy that the PR includes a lot of "unrelated" github projects and applies workarounds. As soon as AppImage is mature enough to fully rely on its own sources (within the github.com/AppImage namespace), I happily accept a PR.

[probonopd]

Hi @davidgraeff

Either snap/flatpak/AppImage work with the installed base system (especially libstdc++ and libgcc) or the approach is flawed.

The way the Linux userspace (or really any OS userspace for that matter) works is by backward compatibility, which means that an application compiled against version n of a library will run on target systems that have version n or n+x available. For libstdc++ this means that if you want the application to run on the oldest still-supported OSes (e.g., Ubuntu 14.04), then you either need to compile the application on a build system that uses a libstdc++ version no newer than what ships with Ubuntu 14.04, or you need to bundle a private copy of libstdc++ that is used if the version of libstdc++ on the target system is older than what the application needs. The existing .travis.yml uses Ubuntu 14.04 but also uses PPAs that pull in a newer version of libstdc++ than what comes with Ubuntu 14.04 by default. Hence we need to bundle it. This is not "flawed" imho, there is no other way around it. (Snappy and Flatpak also would need to ship a private libstdc++, e.g., in what the call a runtime, in this case.)

As soon as AppImage is mature enough to fully rely on its own sources (within the github.com/AppImage namespace), I happily accept a PR.

We need to distinguish between "the AppImage" and the contents/ingredients of a particular application's AppImage. "The AppImage" (as in: the bundle format) only needs https://github.com/AppImage/AppImageKit. An AppImage is really just a self-mounting disk image (squashfs image, actually). What goes into the AppImage is entirely up to the author and out of the scope of AppImage (and you could put the same ingredients into a zip or any other type of archive). What I am using in the PR is just one way of compiling ingredients that should run on many target systems (distributions) including the oldest still-supported Ubuntu LTS release. It can be made in any way you like. Which external projects do you disagree with?

[davidgraeff]

I want the build system workaround free and self-maintaining. The cmake build process provides a very accurate list of files that are required (make install). Some cpack bundlers like the dep/rpm ones are even using this command to determine the required files.

Some remarks:

• The only additional list that I like to provide for such a one-file bundler is the Qt and fft library file names.
• Why is linuxdeployqt necessary and if this tool of yours is an essential tool to create AppImage files, why is it not upstream?
• A bash script that is called by travis would be preferable instead of embedding commands into travis. Travis cannot build arm versions of OpenHantek, that need to be done manually.

[probonopd]

I want the build system workaround free and self-maintaining.

Isn't every build system a collection of workarounds? ;-)

The cmake build process provides a very accurate list of files that are required (make install).

Can it be compiled on a stock Ubuntu 14.04 with the compilers and libraries shipped there and no additional PPAs?

Some cpack bundlers like the dep/rpm ones are even using this command to determine the required files.

I don't understand what this means.

The only additional list that I like to provide for such a one-file bundler is the Qt and fft library file names.

linuxdeployqt figures out what needs to be bundled based on inspecting the compiled files using ldd.

Why is linuxdeployqt necessary and if this tool of yours is an essential tool to create AppImage files, why is it not upstream?

It is not essential to creating AppImage files. For example, electron-builder does not use it. It's just a convenient tool that can bundle the subset of Qt that is needed to run a particular application. You can also use it without making AppImages but shipping the resulting bundle as a zip file, for example.

A bash script that is called by travis would be preferable instead of embedding commands into travis.

That's no problem, the script in the .travis.yml file can easily be converted into a bash script by removing the - prefix from each line.

[davidgraeff]

linuxdeployqt figures out what needs to be bundled based on inspecting the compiled files using ldd.

I have seen some tools doing this. The problem with Qt is, that is supports runtime plugins like the Image plugin for the SVG format, that is required to paint some of the icons. The OpenGL/ES support is also structured as runtime linked components. ldd will not tell you about it.

It might be a good idea to use linuxdeployqt to collect the initial set of library names (and add the missing ones), and repeat the process for each new OS version that travis will change to in the future (~3yr cycle).

We can then use cpacks InstallRequiredSystemLibraries feature and specify the libraries via the CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS variable.

My proposal looks like this:

• Determine necessary libraries with linuxdeployqt for instance.
• Extend the current cmake/cpack based build system with InstallRequiredSystemLibraries.
• Create a self-containing zip via cpack that should include everything to run the app. (make package)
• Transform the zip into an AppImage with the AppImageKit

The windows build does this already, when it creates the NSIS based installer exe.

It shouldn't be too hard to get from here to snap and flatpak and macos bundles.

[probonopd]

I have seen some tools doing this. The problem with Qt is, that is supports runtime plugins like the Image plugin for the SVG format, that is required to paint some of the icons. The OpenGL/ES support is also structured as runtime linked components. ldd will not tell you about it.

linuxdeployqt can be provided by the Qt plugins that should be bundled using the -extra-plugins=<list> parameter. Which ones should be bundled for OpenHantek?

It might be a good idea to use linuxdeployqt to collect the initial set of library names (and add the missing ones), and repeat the process for each new OS version that travis will change to in the future (~3yr cycle). We can then use cpacks InstallRequiredSystemLibraries feature and specify the libraries via the CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS variable.

I do not understand why you would want to have additional work re-creating things in CMake manually that linuxdeployqt is already doing automatically.

Determine necessary libraries with linuxdeployqt for instance

This is automatically done with each run of linuxdeployqt.

Extend the current cmake/cpack based build system with InstallRequiredSystemLibraries

What advantage does this provide?

Create a self-containing zip via cpack that should include everything to run the app.

What for do you need an interim zip?

[davidgraeff]

I think we are mixing two topics into one here. One is to bundle all dependencies into one shippable file. And the other is to actually support the AppImage format.

Regarding the bundling itself

The Qt project ships windeployqt which solves the problem for windows and which is currently used to assemble a Windows installer. It is purely optional. If it is installed, cmake will use it to bundle Qt, otherwise the installer will be the executable and resources only.

I would accept the exact same analoge way for Linux bundles. linuxdeployqt would be used, if found to generate a more complete .sh/.zip file. cpack already supports the qt installer framework to create an installer for linux applications, next to the the command line .sh installer and the .zip file.

Regarding AppImage

The build system (which is currently cmake, but doesn't need to be cmake) should build and package, for all supported systems. No dedicated or exceptional code paths -> There are not enough people maintaining extra solutions, to keep it working in say half a year or year.

As soon as cmake/cpack supports AppImage and other bundle formats, those can be generated as well.

[probonopd]

Yes, I agree that these two points can be separated.

Regarding the bundling itself, linuxdeployqt started off from the macdeployqt codebase actually, and is a direct equivalent to the other *deployqt tools. If it is invoked with -bundle-non-qt-libs rather than with -appimage, then it will generate an application directory (that can be zipped up) instead of an AppImage.

Would that fulfill your requirements?

Regarding AppImage, the application directory from above can be translated into one using a one-line command that runs appimagetool on the application directory, which will simply put the contents of the directory into an AppImage.

This one line can be invoked directly, or could be invoked by CMake.

Would that fulfill your requirements?

Purely for convenience, linuxdeployqt has the -appimage functionality which allows it do do step 2 after step 1 automatically.