subsurface.centos6.sh uses a CentOS 6.7 Live ISO as a buildroot. This has the advantage that the resulting AppImage can run on more systems than if compiled with the normal Ubuntu 12.04 provided by travis-ci.

We should try to make subsurface.centos6.sh run on travis-ci.
Unfortunately chroot needs root and needing root means that we cannot cache the ISO and other ingredients needed for building.
Possibly we could get around this by using proot or something similar that doesn't need root rights.
https://smspillaz.wordpress.com/2015/01/04/creating-mini-distribution-containers-with-fake-root-access-on-travis-ci/

But then, simply mounting the ISO also needs root... :-(
Hey, tmp space should not be an issue so we might even unpack the ISO...

If you attempt this, please do so in a separate fork or in a "centos6-on-travis" branch.

Hi,

I was hoping that bintray.com would have a "flag package out of date" option like the Arch User Repository (https://aur.archlinux.org) has, but as it doesn't I'll have to report that Atom 1.9.9 is presently the latest stable version of Atom (as opposed to 1.9.8, which is presently the latest an AppImage is built) and Brackets 1.6 isn't the latest version of Brackets available, 1.7 is.

Thanks for your time,
Brenton

Subsurface_4.5.1.236_x86_64_centos_6.7.AppImage does not run on openSUSE-Tumbleweed-KDE-Live-x86_64-Current.iso. The real reason can only seen using export QT_DEBUG_PLUGINS=1:

Got keys from plugin meta data ("xcb")
loaded library "/usr/lib64/qt5/plugins/platforms/libqxcb.so"
QLibraryPrivate::loadPlugin failed on "/usr/lib64/qt5/plugins/platforms/libqxcb.so" : "Cannot load library /usr/lib64/qt5/plugins/platforms/libqxcb.so: (/usr/lib64/qt5/plugins/platforms/libqxcb.so: symbol qt_version_tag, version Qt_5.5 not defined in file libQt5Core.so.5 with link time reference)"
This application failed to start because it could not find or load the Qt platform plugin "xcb".

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb.

Reinstalling the application may fix this problem.
/run.sh: line 25:  1312 Aborted                 /opt/AppRun

Apparently it is picking up the wrong libqxcb.so (the one from the system when in fact it should use the bundled one).

Well I guess I have to boot into openSUSE and strace around...

Update required and in VLC recipe there are some hardcoded release number used

Hi,

The VSCode AppImage is not licensed under the MIT License, because it is built from the binary releases provided by Microsoft, which are licensed under a proprietary End-User License Agreement (EULA). If the AppImage was built from VSCode's source code, then it would be licensed under MIT (as its source code is MIT Licensed), but as it is built from Microsoft's binary releases it is governed by the license of these binary releases.

Thanks for your time,
Brenton

I'm getting a "no usable sandbox" issue when running the Chromium AppImage on Arch Linux. It runs fine when passing --no-sandbox to it. But, by default, the AppImage doesn't run.

Currently we are either building on CentOS 6 or use upstream-provided binaries. Building recent software on CentOS 6 can be cumbersome due to outdated dependencies. Hence we should investigate build systems that could make it easier to produce binaries that run on most distributions.

Holy Build Box

This is very close to what we are doing currently but using CentOS 5 rather than 6 for even greater compatibility of the resulting binaries. It might be complicated to get modern GUI software to compile on it however.

• https://github.com/phusion/holy-build-box Holy Build Box is a system for building "portable" binaries for Linux: binaries that work on pretty much any Linux distribution. This works by providing an easy-to-use compilation environment with an old glibc version.

Linuxbrew

• http://linuxbrew.sh Bottles are Linuxbrew's precompiled binary packages. Linuxbrew bottles work on any Linux system. They do however require glibc 2.19 or better. On systems with an older version of glibc, Linuxbrew will install glibc the first time that you install a bottled formula. If you prefer to use the glibc provided by your system and build all formulas from source, add to your .bashrc or .zshrc: export HOMEBREW_BUILD_FROM_SOURCE=1

Meson

• https://github.com/mesonbuild/meson
• https://github.com/mesonbuild/meson/wiki/Creating%20Linux%20binaries "Creating Linux binaries that can be downloaded and run on any distro (like .dmg packages for OSX or .exe installers for Windows)"
• https://github.com/mesonbuild/meson/wiki/Wrap%20dependency%20system%20manual The traditional approach to this has been to bundle dependencies inside your own project. Either as prebuilt libraries and headers or by embedding the source code inside your source tree and rewriting your build system to build them as part of your project. This is both tedious and error prone because it is always done by hand. The Wrap dependency system of Meson aims to provide an automated way to do this.

This ticket tracks issues of upstream projects interested in providing AppImages.

An AppImage is a distribution format for applications that can run anywhere without installation: Distribute your desktop Linux application in the AppImage format and win users running all common Linux distributions. Package once and run everywhere. Reach users on all major desktop distributions.

Note to upstream application authors: If your project appears in this list, it most likely means that AppImage has been suggested as a way to distribute your application. Please open an issue in this project if you are an upstream application developer requesting support for packaging your application as an AppImage.

Find details on AppImageKit here.

This repository contains some example Recipe files that show how to package applications as AppImages.

Also, many projects are building on Travis CI using Qt; these could potentially be interested in providing AppImages of the build results.

Applications

• mumble-voip/mumble#1986
• evothings/evothings-studio#27
• MrKepzie/Natron#120
• therealglazou/bluegriffon#15 - can't get it to build; no CI available
• mavlink/qgroundcontrol#2913
• baedert/corebird#518 - upstream does not target older target systems
• puddletag/puddletag#288
• OpenShot/openshot-qt#93
• markummitchell/engauge-digitizer#112
• Philip-Scott/Notes-up#25 - @demonpig working on it
• GoldenCheetah/GoldenCheetah#1913
• balena-io/etcher#323
• cjcliffe/CubicSDR#334
• https://github.com/iridium-browser/iridium-browser/issues/24
• gnunn1/tilix#25
• ossia/score#186
• HelloZeroNet/ZeroNet#283
• cpvrlab/ImagePlay#57 (comment)
• itchio/itch#683
• https://youtrack.jetbrains.com/issue/ALL-712?query=AppImage
• drawpile/Drawpile#338
• nuttyartist/notes#13
• LMMS/lmms#2556
• servo/servo#12031 - official download does not run for me
• OtterBrowser/otter-browser#1148
• Ultimaker/cura-build#63 | Ultimaker/cura-build#75
• aferrero2707/PhotoFlow#103
• damellis/ESP#323
• arkottke/strata#1
• vinszent/gnome-twitch#157 - upstream seemingly not interested in AppImage
• https://github.com/DemonsawCommunity/demonsaw/issues/4
• https://github.com/xdgurl/xdgurl
• Swordfish90/cool-retro-term#136 (comment)
• https://github.com/FreeRDP/Remmina/issues/1123#issuecomment-282304895
• alamminsalo/orion#197
• jamiemcg/Remarkable#178
• lbryio/lbry-desktop#332
• KDAB/hotspot#58
• bilelmoussaoui/Hardcode-Tray#391
• chenxiaolong/DualBootPatcher#611
• QTodoTxt/QTodoTxt2#30
• hyperdriveguy/OpenGospel#12
• babluboy/bookworm#46
• gcompris/GCompris-qt#191
• qbittorrent/qBittorrent#7312
• brave/browser-laptop#10250 (comment)

Games

See our sister project, https://github.com/RazZziel/PortableLinuxGames

• minetest/minetest#3568
• worldforge/hammer#13
• RigsOfRods/rigs-of-rods#800
• supertuxkart/stk-code#2448
• RPCS3/rpcs3#1561
• planeworld/planeworld#39
• speed-boulder/speed-boulder#2
• unfoldingWord-dev/ts-desktop#194
• AppImage/AppImageKit#177 TrenchBroom
• dosemu2/dosemu2#93 (comment)
• Secretchronicles/TSC#614
• LateStartStudio/Hero6#187 (already builds on Travis CI)

Other

• alganet/AppPackPrototype#1

We could use zsync to make delta updates easy.

Here is an example of a package that has been waiting since 2009 to be included in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=490140

It can be installed using sudo yum install ftp://ftp.icm.edu.pl/vol/rzm5/linux-dag/redhat/el6/en/x86_64/dag/RPMS/zsync-0.6.2-1.el6.rf.x86_64.rpm

Currrently we are using a bash script for uploading to Bintray. We could consider using the travis-ci hook for the actual upload to Bintray.

https://docs.travis-ci.com/user/deployment/bintray

But before we do that we should make sure we can control when it uploads (not only on releases).

The PhoneGap Desktop application isn't provided for Linux but can apparently be built, as it is based on nodejs:

https://openitstudio.ru/blog/18.html

Please, anybody make AppImage of SolveSpace for 32bit and 64bit

• http://github.com/solvespace/solvespace/releases/tag/v2.1

Here are discussions:

• http://solvespace.com/forum?action=viewthread&parent=1369
• solvespace/solvespace#17

There should be icons for the text/x-arduino MimeType in the Arduino AppImage; something along the lines of

numixproject/numix-icon-theme#922

See arduino/Arduino#4436

E.g., Firefox Aurora (Developer Edition), different channels, etc.

https://docs.travis-ci.com/user/environment-variables/#Defining-Multiple-Variables-per-Item

Since we can override the env matrix using API calls to trigger builds, we could even feed in things like git branches, git revisions, git tags, version numbers, languages, architectures, channels, etc.

One recipe to build them all!

I had thought that whatever the arch of Appimage is, all library files are put into APPIMAGE_BASE/usr/lib. Is that assumption correct, or there are ./usr/lib for 32-bit and ./usr/lib64 for 64-bit Appimages?

Hi,

I'm getting the warning bellow:

You are using an unsupported command-line flag: --no-sandbox. Stability and security will surfer

As can see in the source:

https://github.com/probonopd/AppImages/blob/master/recipes/chromium/Recipe#L33

Why the AppImage is using this flag?

Regards

Chromium 51.0.2684.0
Distro Ubuntu 16.04

I'm not sure it it's the right place to make package requests, but it would be nice if you could bundle a GTK3 build of Firefox as an AppImage, while official upstream binaries not switch to GTK3 definitely.

Hi,
I've managed to compile my code (https://github.com/iltommi/neutrino) via Travis and upload it directly on the release page of the repo: https://github.com/iltommi/neutrino/releases (the zipfile contains the AppImage).

The travis recipe is here: .travis.yml
My code is a bit complicated. It needs a couple of packages which are not available on plain trusty travis image:

• cmake (compiled from git clone https://github.com/Kitware/CMake.git)
• qt5.6 (got via sudo add-apt-repository -y ppa:beineri/opt-qt561-trusty)
• pyhtonqt (compiled from git clone https://github.com/iltommi/PythonQt.git )

For AppImageKit, I use this:

sudo apt-get update ; sudo apt-get -y install libfuse-dev libglib2.0-dev cmake git libc6-dev binutils fuse
git clone https://github.com/probonopd/AppImageKit.git
cd AppImageKit
cmake .
make
cd ..

To create my AppImage, I use this part of the travis recipe:

mkdir -p Neutrino.AppDir/usr
cp -r build_dir/lib build_dir/bin AppImageKit/AppRun Neutrino.AppDir/usr
cp resources/icons/icon.png resources/linuxPackage/Neutrino.desktop Neutrino.AppDir
cp -r ${Qt5_DIR}/../../../plugins Neutrino.AppDir/usr/bin
sudo apt-get install -y pax-utils
lddtree Neutrino.AppDir/usr/bin/Neutrino | grep "=>" | awk '{print $3}' | xargs cp -t Neutrino.AppDir/usr/lib/
rm -rf Neutrino
./AppImageKit/AppImageAssistant Neutrino.AppDir Neutrino
zip -FSr Neutrino.zip Neutrino
export RELEASE_FILE=Neutrino.zip

So far, so good... but When I try to run in an ubuntu machine, I get:

/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libPythonQt.so)
/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5Network.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libPythonQt.so)
/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libPythonQt.so)
/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5Sql.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libPythonQt.so)
/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libQt5MultimediaWidgets.so.5)
/tmp/.mount_NKi4QH/usr/bin/Neutrino: /usr/lib/x86_64-linux-gnu/libQt5Network.so.5: no version information available (required by /tmp/.mount_NKi4QH/usr/lib/libQt5Multimedia.so.5)
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Reinstalling the application may fix this problem.
Aborted (core dumped)

The relevant portion seems to be:

This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Any ideas why?

p.s.
thanks for the effort!

https://www.videolan.org/vlc/releases/2.2.4.html

I have a little issue with running my experimental GIMP AppImage (see the current Recipe here).

The AppImage gets mounted in a temporary directory of the form "/tmp/.mount_*". This means that the GIMP plug-ins are located in a different folder at each execution of the appimage. This in turn triggers the update of the GIMP plug-in registry at each execution, which significantly increases the GIMP initialisation time.

Would there be a way to tell the AppImage to mount to a fixed directory instead of an uniquely-generated one? Something like "/tmp/.mount_gimp_appimage"? Or is there a severe problem with this?

For continuous/daily/nightly/weekly builds, limit the number of binaries on Bintray.
Let's conserve some disk space. E.g., preserve the last 5-10 builds only.

Arduino-1.6.8.hourly201602020926.esp04c6609-x86_64.AppImage stopped running on Fedora 23:

Picked up JAVA_TOOL_OPTIONS: 

(process:4683): Gtk-WARNING **: Locale not supported by C library.
    Using the fallback 'C' locale.

(java:4683): GLib-GIO-ERROR **: No GSettings schemas are installed on the system
/tmp/.mount_VnWrGA/usr/bin/arduino: line 34:  4683 Trace/breakpoint trap   (core dumped) "$JAVA" "${JAVA_OPTIONS[@]}" processing.app.Base "$@"

Arduino-1.6.8.201601250626.esp1783-x86_64.AppImage did not have this issue. Running the hourly directly from the Arduino site also does not have this issue.

When I mount Arduino-1.6.8.hourly201602020926.esp04c6609-x86_64.AppImage and run the AppRun inside, then it crashes. However, when I run usr/bin/arduino.wrapper directly then it doesn't crash. So it looks like AppRun is running the wrapper and/or app in a way that causes the issue; apparently by setting the offending environment variable XDG_DATA_DIRS=./share/.

I tried the oldest version on github 2.2.2 and it still errors on a libc version that is too new... we have glibc 2.12 ...

Consider hosting AppImages on Bintray as it seems free for open source projects, and possibly is easier to handle than GitHub Releases. https://gist.github.com/hgomez/4447779

Currently, only the first word is used. This should be changed.

When constructing the AppImage filename, we need to convert blanks into "-" or "_" characters. Which is better?

Related: Also, we need a more robust way to preserve version information inside the AppImage so that the Bintray upload script doesn't have to guesstimate the version number from the AppImage filename.

Isn't AppStream supposed to know version information?

• (DONE) Bundle tkinter so that Scripter > Scribus scripts > CalendarWizard works
• (DONE) Make it possible to enter text
• (DONE) Revert merging the 2 icon sets
• Remove *.pyc files?

Current version provided by you is Beta1

Péter writes:

Linux (Mint) - Qt 5.5x - Scribus it does not works well (pages move slowly if you use wheel mouse button). Request: Possible to use Qt 5.4x or Qt5.6x (this works well!)?

AppImage contain Qt5.5x . How to replace? Qt5.5 --> Qt5.6 (or 5.4.2)

Fast operation: Qt5.4.2 and Qt5.6
Slow operation: Qt5.5 :-(

Example (video): https://www.dropbox.com/s/dgkszedcdn5hfb9/example.avi?dl=0

We need to find a way to install Qt 5.4x or Qt5.6x on CentOS 6 where the AppImage gets built.
Here is the script that produces the AppImage;
https://raw.githubusercontent.com/probonopd/AppImages/master/recipes/scribus/Recipe

I've registered an idea in Spotify Community forums to build an AppImage for its Linux Desktop app. Maybe you can help them.

It should be possible to convert xdg-app packaged apps to AppImages using some converter logic. This needs to be investigated.

[db2z07@evadlaptopz Downloads]$ ./Terminix-0.59.0-x86_64.AppImage 
/tmp/.mount_6HIlQ3/usr/bin/terminix.wrapper
2016-05-11T00:19:40.365:resource.d:getResource:102 Unexpected error loading resource /com/gexperts/Terminix/css/terminix.Adwaita.css
2016-05-11T00:19:40.366:resource.d:getResource:103 Error: The resource at '/com/gexperts/Terminix/css/terminix.Adwaita.css' does not exist

(terminix:18714): GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.interface' is not installed

Trace/breakpoint trap

On RHEL 7.2 workstation.

Interesting trick showing how to use alpine linux as a base for appimage.
Alpine Linux is minimalist, musl-based Linux distro. It provides not so wide set of packages in repositories, but all useful stuff is there.

So, using VLC as an example

1. Download apk-static tool
   wget http://mirror.yandex.ru/mirrors/alpine/v3.3/main/x86_64/apk-tools-static-2.6.5-r1.apk tar xzf apk-tools-static-2.6.5-r1.apk
2. Create root folder
   mkdir rootdir
3. Init database and install vlc
   ./sbin/apk.static -X http://mirror.yandex.ru/mirrors/alpine/latest-stable/main -U --allow-untrusted --root rootdir --initdb add alpine-base vlc vlc-qt
4. Navigate to root folder and adjust LD_LIBRARY_PATH
   cd rootdir export LD_LIBRARY_PATH=./lib:./usr/lib
5. Run vlc
   ./lib/ld-musl-x86_64.so.1 usr/bin/vlc
6. You can delete all folders in root dir, except for lib and usr. Also you will need to cleanup all extra folders and also binaries in usr/bin.

@probonopd What do you think?

[desktopintegration] MIME types are missing for Subsurface

I built myself VLC appimage on top of Centos 7 base, and it works in Fedora 24 flawlessly. The ones I downloaded from your bintray, fail to run, showing segmentation fault.

Apparently my own idiocy is working against me, because I'm unable to push changes to the git repository. I've updated the recipe to pull the newest client version and install the correct libnss3* libs. There's probably some cleanup that could be done, but for the moment, it works.

--- AppImages/recipes/upwork/Recipe 2016-06-18 19:24:27.245194177 -0500
+++ upwork.sh 2016-07-20 12:51:22.313900032 -0500
@@ -1,3 +1,5 @@
+# This script is written by probonopd of the AppImage project,
+# and is about 500% better than the Ruby script I was using.

In this example, we use non-repo .deb

Some projects provide raw .deb files without a repository

hence we create our own local repository as part of

@@ -42,7 +44,7 @@
-o APT::Install-Suggests=0
"

-wget -c "http://updates.team.odesk.com/binaries/v4_1_314_0_0bo6g5kfbj07y2x4/upwork_amd64.deb"
+wget -c "http://updates.team.odesk.com/binaries/v4_1_337_0_vctcub5d7q8kudja/upwork_amd64.deb"

Add local repository so that we can install deb files

that were downloaded outside of a repository

@@ -51,9 +53,10 @@

apt-get $OPTIONS update

-URLS=$(apt-get $OPTIONS -y install --print-uris $LOWERAPP | cut -d "'" -f 2 | grep -e "^http")
+URLS=$(apt-get $OPTIONS -y install --print-uris $LOWERAPP | cut -d "'" -f 2 | grep -e "^http" | grep --exclude "libnss")
+NSS3=$(apt-get $OPTIONS -y --force-yes install --print-uris libnss3=2:3.15.4-1ubuntu7 libnss3-nssdb=2:3.15.4-1ubuntu7 | cut -d "'" -f 2 | grep -e "^http")

-wget -c $URLS
+wget -c $URLS $NSS3

cd ./$APP.AppDir/

https://github.com/GitbookIO/nuts

Nuts is a simple (and smart) application to serve desktop-application releases. It uses GitHub as a backend to store assets, and it can easily be deployed to Heroku as a stateless service.

Nuts provides a backend for the Squirrel.Mac auto-updater. Squirrel.Mac is integrated by default in Electron applications. Nuts also provides a backend for the Squirrel.Windows auto-updater.

See https://github.com/electron-userland/electron-builder/wiki/Publishing-Artifacts for a workflow for automatic uploading from Travis CI.

Chromium appimage refuses to run on centos 6, looks for GLIBC_2.14

https://docs.travis-ci.com/user/triggering-builds

Specific recipes can be triggered by overriding the .travis.yml matrix in the request

https://securityblog.redhat.com/2013/09/18/reproducible-builds-for-fedora/

"It should be possible for the users to verify that the binary matches what the source intended to produce, in an independent fashion. This is the basic nature of open source, the source code is available, so what can we do with it?"

https://wiki.debian.org/ReproducibleBuilds/Howto

"A source package should build byte-for-byte identical products when rebuilt in the same environment. (...) We have seen variations related to the time of the build, the order of files on the filesystem, the current user, the system hostname, the uname output, (pseudo-)-randomness, and the CPU features or load. Such aspects must not be captured by the build process to make a package reproducible."

Possibly we can use Mock

https://fedoraproject.org/wiki/Mock?rd=Subprojects/Mock

"Mock is a tool for building packages. It can build packages for different architectures and different Fedora or RHEL versions than the build host has. Mock creates chroots and builds packages in them. Its only task is to reliably populate a chroot and attempt to build a package in that chroot."

We could store the Recipe and information in which Docker image to run it inside each generated AppImage for convenience and reproduce-ability.

With the recent continuation of development of Geary and Shotwell, it is worth packing them into AppImages.
Although I should mention that they probably will require at least Centos7 as a base.

[desktopintegration] Update recipes to make use of https://github.com/probonopd/AppImageKit/blob/master/desktopintegration

Also see AppImage/AppImageKit#63

We now have i386 builds (although not yet on travis-ci). For the latter, see #7.

Hey guys,

I was just trying out AppImages and I have to say that it's a bit mindblowing. I found the AppImageKit guide and it all makes sense, but I have to say that I need some infos to get started. (First-time user, hope that I didn't miss something in the wiki).

Background: I'm the founder of lycheeJS which aims to ship bundles of isomorphic javascript applications (using node, node-sdl, nwjs and electron, and others for mobile).

I am kind of confused about the AppDir structure, can it contain pretty much anything? I was taking a glimpse on some of the Recipes, but I couldn't find clues about what files have to be named in which case.

It would be awesome to have something like an AppDir structure wiki entry that documents something like:

• /lib contains all libraries
• /assets contains all assets like png images, js files etc. pp.
• /appimage.desktop has to exist, alternatively use /appimage.desktop and appimage-2.desktop for multiple desktop files
• /package.json contains all meta data that AppRun needs to integrate it properly, it also requests access to storage, usb etc. pp.
• /Hello-World.bin is our program that is started, it is the "main" entry in the package.json file

Is there any kind of documentation for that? That's where I'm hanging in my local setup right now. I was also going to ask if there is the possibility of distributing multiple desktop files via AppImageKit?

The only thing I've found so far was the /app.wrapper and the AppImageAssistant.

It would be really neat to have a kind of failsafe hello-world tutorial that just does the basics, clean and simple - so that others can follow up quickly what which tool does.

So I guess it was compiled on Centos 7. So we are past Centos-6 as a base?

We can find out the minimum GLIBC version required and save that as metadata in the AppImage.

find . -type f -executable -exec strings {} \; | grep ^GLIBC_2 | sed s/GLIBC_//g | sort --version-sort | uniq

Hi,

I tested LibreOffice 5.0.4 downloaded from https://bintray.com/probono/AppImages/LibreOffice/ , as well as self built LibreOffice images according to https://github.com/probonopd/AppImageKit/wiki/Bundling-OpenOffice, both has problem when converting MS Word format to PDF format.

Steps to reproduce:

1. prepare a MS Word document, or Excel, or PowerPoint, etc.
2. using command line to convert the file

$ ./ooo.AppImage --convert-to pdf test_doc.doc

Expected result:
convert test_doc.doc -> test_doc.pdf using filter : writer_pdf_Export
Actual result:
Error: source file could not be loaded

According to my experience from creating portable LibreOffice for Windows, it seems this error usually happens when some part of LibreOffice installation is missing.

Any comment is great appreciated, thanks for the great work!

I've suggested libreoffice package appimages as a means of having portable apps and maybe you can add some useful information to the bug report.

https://bugs.documentfoundation.org/show_bug.cgi?id=97269

Take Scilab appimage for example. Its name implies that GLIBC 2.4 is required. But when you run Scilab Appimage on centos6, it fails with message that GLIBC_2.14 not found - so I assume it was built on Centos 7, at least.

Correct MIME type ("AppImage"):
https://dl.bintray.com/unruhschuh/AppImages/:Cantata-2.0.0-x86_64.AppImage

Wrong MIME type ("JSON document"):
https://dl.bintray.com/probono/AppImages/:Leafpad-0.8.17-x86_64.AppImage

Why is this and how can I fix this?

@unruhschuh do you have an idea?