appimagecommunity / appimaged Goto Github PK

Firejail is a SUID program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces and seccomp-bpf. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.

Written in C with virtually no dependencies, the software runs on any Linux computer with a 3.x kernel version or newer. The sandbox is lightweight, the overhead is low. There are no complicated configuration files to edit, no socket connections open, no daemons running in the background. All security features are implemented directly in Linux kernel and available on any Linux computer.

https://firejail.wordpress.com/

Pros:

• Seems to do what we are looking for.
• Lightweight on dependencies.

Cons:

• Sandbox profiles for each application must be specifically written, e.g, "Iceweasel/Mozilla Firefox, Chromium, Midori, Opera, Evince, Transmission and VLC"
• Needs suid
• Hence needs to be installed into the host OS
• Hence needs root rights to set it up

I have appimaged running in Ubuntu Cosmic, using the Deb installation method, and I have some questions on how it works...

1. Is there a way to configure the directories that appimaged scans. I would prefer it didn't scan downloads.
2. I tried renaming SomeApp.AppImage to SomeApp.AppImageXXX but that didn't stop it! How do you look for programs?
3. In the case of KDevelop's AppImage, the resulting desktop file within the Brisk menu has two arguments after the executable, thus
   Exec=/opt/kdevelop/KDevelop-5.3.0-x86_64.AppImage -b %U
   which prevents it from running, and are not shown by the app's help. If I edit them out, they return on the next boot!!
   Is this a function of how appimaged is working, or is it an issue I should raise with the Kdevelop's developers.
   Thanks
   John

CC @probonopd

Should we (again) offer 32-bit builds for appimaged? At the moment, appimaged is built in the standard Travis CI environment (i.e., Ubuntu trusty) in a 64-bit environment.

We could think about building the project using https://github.com/AppImage/AppImageBuild, just like we did before, when it was part of https://github.com/AppImage/AppImageKit.

appimaged exits with

_________________________

-> REGISTER /isodevice/Applications/QQ-x86_64.AppImage
squashfs based type 2 AppImage
Read of ELF section header from (null) failed: Success

Then systemd relaunches it immediately again, resulting in it taking up 100% CPU.

appimaged -v does not show much more:

_________________________
AppImage type 2

-> REGISTER /isodevice/Applications/QQ-x86_64.AppImage
get_thumbnail_path: /home/me/.cache/thumbnails/normal/74fad7cdf0cb4fd33e0758795bfe48b8.png
squashfs based type 2 AppImage
md5 of URI RFC 2396: 74fad7cdf0cb4fd33e0758795bfe48b8
Read of ELF section header from (null) failed: Success

The AppImage in question has some issue:

me@host:~$ /isodevice/Applications/QQ-x86_64.AppImage --appimage-extract
Segmentation fault


me@host:~$ /isodevice/Applications/QQ-x86_64.AppImage --appimage-mount
Segmentation fault

me@host:~$ file /isodevice/Applications/QQ-x86_64.AppImage 
/isodevice/Applications/QQ-x86_64.AppImage: ERROR: ELF 64-bit LSB executable, x86-64, version 1, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 error reading (Invalid argument)

me@host:~$ ls -lh  /isodevice/Applications/QQ-x86_64.AppImage 
-rwxr-xr-x 1 root root 32K Nov 29 01:26 /isodevice/Applications/QQ-x86_64.AppImage

We should

• Make systemd give up after x retries
• Fix the root cause why appimaged exits here
• In general, make appimaged more resilient so that it never exits, but simply skips AppImages it cannot deal with

defective_appimage_for_testing.AppImage.zip

Original issue: AppImage/AppImageKit#762

Build product ends up in src/ rather than the cwd. Something to do with CMake?

Let's consider to unify 4 tools into one

• https://github.com/AppImage/appimaged
• https://github.com/azubieta/appimage-desktop-integration
• https://github.com/TheAssassin/AppImageLauncher
• https://github.com/CalebQ42/LinuxPA

In times in which people complain about fragmentation of the already small Desktop Linux user base, we should try not to add further fragmentation by offering 3 different ways to achieve desktop integration for AppImages.

As it stands now, not even I would be able to explain to a user which one to use, and why.

Hence I suggest we make a table that lists the differences, and then see if we can make one tool that either does it all, or at least can be configured to do either-or.

Please add to the list (maybe we should move it to the wiki for better edit-ability).

The native openSUSE package by @marguerite currently installs
/usr/bin/appimaged-x86_64.AppImage and appimagetool-x86_64.AppImage.

To get appimaged to work, one has to

appimaged-x86_64.AppImage --install
# This gives an error, so we do the next step by hand:
cp /usr/bin/appimaged-x86_64.AppImage /home/linux/.local/bin/appimaged

By handling installation and/or packaging this a bit differently, this could be made automatic. I will write more about this when I have time to think about this. I need to provide additional information.

For example, I prefer to install all my AppImages in ~/Applications. I don't want appimaged to search my ~/Downloads again and again.
(I'm sorry for my bad English)

jdevera at AppImage/AppImageKit#806:

When appimaged is processing the Digikam appimage, it complains about the lack of Exec key in the found desktop file:

Jun 15 23:47:24 nexon appimaged[15311]: -> REGISTER /home/jdevera/.local/bin/digikam-5.9.0-01-x86-64.appimage
Jun 15 23:47:24 nexon appimaged[15311]: squashfs based type 2 AppImage
Jun 15 23:47:24 nexon appimaged[15311]: Got root desktop: digikam.desktop
Jun 15 23:47:24 nexon appimaged[15311]: TODO: Implement inode.base.inode_type 9
Jun 15 23:47:24 nexon appimaged[15311]: Desktop file has no Exec key

However, the digikam.desktop file inside the appimage contains the following line:

Exec=digikam.wrapper -qwindowtitle %c

The result is that no desktop entry is registered for Digikam

The current builds aren't signed since the extraction. We need to re-implement this.

Hey, sorry, huge newbie here but I was wondering if it was possible to add a custom directory to be monitored by the application?

Investigate whether we can use systemd Path Units rather than using inotify ourselves. This would simplify the tool, make it more flexible (could be triggered in different ways), and would even make the search paths user-configurable (through systemd).

https://www.linuxjournal.com/content/linux-filesystem-events-inotify (search for "Path Units under systemd").

Icon for Jitsi Meet gets shown in menu but not in file thumbnail; why?

XFCE on Clear Linux OS with the latest appimaged

$ /home/user/.local/bin/appimaged --version
appimaged, continuous build (commit 189b800), build 42 built on 2018-09-06 19:33:24 UTC

In elementary OS 0.4 Loki, clicking on the RetroArch icon launches a second icon.
This is when I use appimaged.

Is this a bug in the elementary OS 0.4 Loki dock, plank?

Where is the plank bugtracker?

We should migrate the existing open issues related to appimaged into this issue tracker.

The appimaged utility has a -h, --help CLI parameter, which currently prints this:

$> appimaged --help
Usage:
  appimaged [OPTION...] 

Help Options:
  -h, --help           Show help options

Application Options:
  -v, --verbose        Be verbose
  -i, --install        Install this appimaged instance to $HOME
  -u, --uninstall      Uninstall an appimaged instance from $HOME
  -n, --no-install     Force run without installation
  --version            Show version number

I. Add explanatory line on top

This help screen should print one or more additional lines giving a short explanatory info about what appimaged is good for at all:

An (optional) userland daemon which monitors various directories for AppImages.
If it detects some, it registers them with the system, so that they show up in
menus, displaying their icons, associating MIME types, etc. It also automatically 
unregisters deleted AppImages from the system. If firejail is installed, it runs
AppImages with it.

or, a bit shorter:

Optional userland daemon to auto-discover AppImages from a pre-defined set of directories
and register/un-register them (create menu entries with icons; associate MIME types, etc). 

II. Add an option to 'discover' monitored directories

The main README for AppImageKit lists the directories which are scanned by appimaged as:

$HOME/Downloads
$HOME/.local/bin
$HOME/bin
/Applications
/isodevice/Applications
/isofrom/Applications
/run/archiso/img_dev/Applications
/opt
/usr/local/bin

In the interest of better discoverability of how the different AppImageKit tools work, there should be a way to enumerate the list of scanned directories.

One possible solution would be to implement an additional flag, -l, --listmon, which would lead to the following output:

$>  appimaged --listmon

Directories monitored by appimaged for added, renamed and removed AppImage(s):
  $HOME/Downloads
  $HOME/.local/bin
  $HOME/bin
  /Applications
  /isodevice/Applications
  /isofrom/Applications
  /run/archiso/img_dev/Applications
  /opt
  /usr/local/bin

III. Complete new help screen

After implementing this request, the new -h could look like this below:

$>  appimaged -h

Optional userland daemon to automatically register and un-register AppImages
(creating menu entries with icons, associating MIME types, etc.), which are
stored in a pre-defined set of directories.

Usage:
  appimaged [OPTION...] 

Help Options:
  -h, --help           Show help options

Application Options:
  -v, --verbose        Be verbose
  -i, --install        Install this appimaged instance to $HOME
  -l, --listmon        List all directories monitored by appimaged
  -u, --uninstall      Uninstall an appimaged instance from $HOME
  -n, --no-install     Force run without installation
  --version            Show version number

We need to write a rpm spec file so that it can be included in gnome-software CI which is based on Fedora. This issue is to keep track of the progress.

cc @Conan-Kudo

Moved from https://github.com/AppImage/AppImageKit/issues/653

Hi,
appimaged repeats the version number over and over at the end of the application name (for Gravit Designer, put into ~/Applications, on Ubuntu Budgie 18.04, appimaged, continuous build (commit f888818), build 36 built on 2018-08-27 01:06:49 UTC). This is the resulting deskop file:

[Desktop Entry]
Name=Gravit Designer (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589)
Comment=gravit-designer
Exec=/home/user/Applications/GravitDesigner.AppImage
Terminal=false
Type=Application
Icon=appimagekit_478671d3a6e39aff6c4f3de89b3bdd0e_gravit-designer
X-AppImage-Version=3.4.4.2589
X-AppImage-BuildId=c31cc000-abe2-11a8-210a-03c435d7e5e3
Categories=Graphics;
TryExec=/home/user/Applications/GravitDesigner.AppImage
X-AppImage-Old-Name=Gravit Designer (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589) (3.4.4.2589)
X-AppImage-Identifier=478671d3a6e39aff6c4f3de89b3bdd0e

The original desktop file from the AppImage mount looks like this:

[Desktop Entry]
Name=Gravit Designer
Comment=gravit-designer
Exec=AppRun
Terminal=false
Type=Application
Icon=gravit-designer
X-AppImage-Version=3.4.4.2589
X-AppImage-BuildId=c31cc000-abe2-11a8-210a-03c435d7e5e3
Categories=Graphics;

The repeating version numbers also seem to get rewritten at login or boot if I manually delete it from the desktop file.

A popular hypervisor "VirtualBox" uses /opt/VBoxGuestAdditions-X.X.X on Ubuntu Guests to store information about the VM guest additions, common with each Ubuntu guest running inside a VirtualBox VM. At the time of writing this, this location has several files including 7 subfolders, source code and two desktop files.

Running appimaged in verbose mode shows many failed attempts to scan and recognize files in this directory.

From what I understand this is due to the monitoring of the /opt directory. I propose to omit/blacklist directories starting with /opt/VBoxGuestAdditions- to prevent common unwanted entries in the output log when daemon is initially launched.

Does such a blacklisted location already exist within the tool?

The Icon Theme Specification actually does not specify $XDG_DATA_HOME as a source for icons, hence applications in userspace do not have a standard way to place their icons. Although Ubuntu Unity, XFCE, and other desktops do pick icons up from there, but KDE Plasma doesn't.

https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

@ximion, am I reading the XDG spec correctly, and do you think we should propose a change?
https://bugreports.qt.io/browse/QTBUG-48417

This seems to be a 12-year old issue:
https://lists.freedesktop.org/archives/xdg/2004-September/003280.html

In the KDE Plasma GUI there is no notion of per-user icons either:
http://askubuntu.com/questions/788386/how-to-add-icons-on-the-kde-menu-editor-icon-source

In addition, KDE Plasma seems to ignore icons in $HOME/.icons.

Effectively leaving no way for an user-space application like appimaged to install icons for applications.

Nautilus (GNOME) and Caja (MATE) seem to need a restart in order to recognize new MIME types, whereas $ mimetype test.kdev4 works immediately.

Even after running

update-mime-database $HOME/.local/share/mime
update-desktop-database $HOME/.local/share/applications

How can this be solved? What does dpkg do?

Original issue: AppImage/AppImageKit#744

EDIT: Anyone reading this and interested in doing native distribution packages, we are on IRC on #AppImages on irc.freenode.net

@rickysarraf writes in AppImage/AppImageKit#325

I can speak on what is the case in Debian. I'm not sure about other distributions. ON Debian, on the buildd infrastructure, network access is disabled. And there are good reasons to do that. Your git submodules are just defined as a git repository.

I am not sure what is the best path of action here, but I will definitely support anyone who wants to make a native (in the sense of: part of the official debian distribution) debian package for appimaged. Also see the great work by @marguerite who has packaged it (and appimagetool) for openSUSE.

Perhaps @ScarlettGatelyClark wants to chime in?

Collecting here the need for a debian package:

• https://news.ycombinator.com/item?id=13422925
• LibrePCB/LibrePCB#140 (comment)

Hi,

On Tumbleweed appimaged (latest, from commit a3b100b) has started to crash, it used to run fine, but now I'm getting the error:

munmap_chunk(): invalid pointer
[1]    16855 abort (core dumped)  appimaged

. If you need any more information please do tell.

strace -o strace.log appimaged gives this strace.log: strace.log.zip. LD_DEBUG=libs appimaged &> debug.log gives this debug.log: debug.log.zip.

Thanks for your time,
Brenton

Instead of scanning a fixed set of locations like

• /isodevice/Applications
• /isofrom/Applications
• /run/initramfs/isoscan/Applications
• /run/archiso/img_dev/Applications
• /lib/live/mount/findiso/Applications

we should scan /Applications in every mounted partition.

This would give us support for distirbutions like Manjaro, where the Live medium is mounted at /run/miso/img_dev, without having to hardcode yet another location.

As a bonus, we should also monitor /Applications on freshly mounted partitions as they come and go (think removable drives).

@rszibele, do you want to have a go at this?

According to https://discourse.appimage.org/t/how-to-use-linuxdeployqt/275/15, appimaged should run

update-mime-database $HOME/.local/share/mime
update-desktop-database $HOME/.local/share/applications

(if these commands are available on the $PATH) in order to work correctly.

Note: This should not be done after each AppImage processed by appimaged in order to save CPU power, but only after the system has quiesced (e.g., no further AppImages have been processed in the last X seconds).

Idea by @RoyiAvital in #5 (comment):

Also scan location where appimaged resides itself

Current situation

Desktop Linux, mostly through freedesktop.org specifications, currently provides only static and inflexible ways to integrate applications with the system. It is assumed that applications are installed into fixed locations into the system. The system is not really built for dynamically ever-changing per-user applications. It also assumes that every application is only present in one version.

Deficiency of the status quo: Dealing with applications that come and go on the fly

This creates challenges for situations in which applications "come and go", e.g., when an external partition (or, say an AppImage, a Snap, a file server share...) is mounted that contains applications. One has to manually copy around desktop files, icon files to locations like $HOME/.local/icons/hicolor/ with varying subdirectories that may or may not exist and be recognized depending on whether the subdirectories were already present when the desktop environment was launched, MIME files to locations like $HOME/.local/share/mime/packages, and then trigger runs of tools like update-desktop-database and update-mime-database, which is a real pain:

• #34
• AppImage/AppImageKit#45
• https://github.com/AppImage/appimaged/issues/46

Some desktop environments then also need to update their own databases and caches, e.g., Sycoca on KDE Plasma. Whether or whether not this happens automatically and on which occasion has been a complicated mess since essentially forever.

If too many applications come and go at the same time, the system can come to a grinding halt due to the various databases and caches being updated a lot of times in short order:

• #12

Once the external partition containing applications is unmounted, one has to figure out which of the files that were previously copied around need to be deleted, and has to manually trigger various update-.... commands again.

This reminds one of the state of networking before WLAN, where everything was configured statically under the assumption that there is a static networking setup that is erected when the machine is installed. Once people had mobile devices and roamed around, NetworkManager was introduced and made network management dynamic, assuming that network connections would come and go. The same has not happened on "Desktop Linux" for applictions yet, but needs to happen.

Deficiency with the status quo: Multiple versions of applications

Many applications have different icons for different versions of the same application. Firefox, for example, has constantly been evolving their icon.

The current XDG standard is entirely ignorant of this, assuming all Firefox instances on the system are sharing the same Firefox icon. macOS does a much better job because icons are stored inside each application, rather than at one central place in the filesystem.

Similarly, when a HTML file is about to be opened, then there is no clear concept which version of Firefox will get to open it under the current XDG regime.

Current workarounds in AppImage

As an AppImage-specific workaround for the inflexible, static way of how applications are integrated with the system, we have (at least) 4 different, inclomplete ways to integrate AppImages with the system (which still suffer from the shortcomings of the status quo described above but try to work around them):

• A shell script that is contained inside some AppImages and that asks the user whether the AppImage should be integrated when an AppImage is executed for the first time. This is deprecated and no longer recommended nor supported
• The optional appimaged daemon which needs to be installed in the system. This will watch certain directories (most notably, /Applications and $HOME/Applications) for AppImages, and will integrate them into the system automatically. By design, it will never move anything anywhere and will never ask the user any questions. (Compared to the Mac, this solution is not yet ideal because it does not integrate AppImages stored in random locations yet and watching the entire system with inotify would be computationally too expensive.)
• The third-party AppImageLauncher which needs to be installed in the system (but not in addition to appimaged). It will ask the user with a popup to move every AppImage into $HOME/Application whenever an AppImage is launched that is not in that location yet. (Personally I find this too intrusive as I keep my AppImage in non-standard locations but apparently some users like this.)
• The AppImage desktop integration built into Nitrux OS.

Current workarounds in snapd

(to be written)

Current workarounds in Flatpak

(to be written)

What needs to be done

To come up with a much better (and more seamless) system than what we have now, we should

• First, propose to standardize (e.g., via freedesktop.org) some infrastructure for the Linux Desktop that is not AppImage specific but does cater to the AppImage use case (as it would for Snappy, Flatpak, traditional packages, applications installed via .tar.gz or .zip files, AppDirs and that would have to be implemented by desktop environments like GNOME, KDE Plasma, XFCE, Elementary OS, and the like and/or existing system-wide infrastructure such as systemd. We should do this in an open discussion involving the greater Desktop Linux community, including desktop environment projects, application authors, etc.
• Second, as a fallback, come up with something that does not require the collaboration of the desktop environments and/or systemd (but possibly hook into them using the existing interfaces they provide as of today, such as dbus, thumbnailers, and such)

The objective should be to get proper dynamic desktop integration for applications (like on the Mac) into the default installation of distributions. This pretty much excludes any solution that is AppImage-specific.

Learning from the Mac

Classic Mac OS, the various NeXT systems, and Mac OS X are still unparalleled in terms of ease-of-use when it comes to integrating applications into the system by mere drag-and-drop. It just seems to work phenomenally well, without the user having to fiddle around with desktop files, icon files, and the like.

I have written about this before.

It is about time that Desktop Linux gets the same level of usability, almost two decades later.

We have been attempting to re-create a similar level of simplicity with appimaged, but frankly, so far we have not reached the same level of "it just works" (and performance) yet. Possibly some changes are required on deeper levels of the system and the file managers.

Almost two decades ago, then Apple User Experience Architect @arnog gave insight into some of the concepts of how Mac OS X does what we would call "system integration" today in the WWDC 2000 Session 144, Application Packaging and Document Typing. The man must know, as he has been the "Architect and lead engineer of a complete rewrite of the Finder for Mac OS X", and according to his CV "Participated in weekly design meetings with Steve Jobs (and had a good time doing it)".

Applications on Mac OS X live in application directories, a subclass of what they interchangeably referred to as "bundles" and "packages" back then. Our equivalent would be AppDir. Those are often shipped inside dmg disk images, our rough equivalent of which would be AppImages.

How the system recognizes an application bundle

1. By a filesystem attribute ("bundle bit"). It is explicitly mentioned that this is not robust across different filesystems. Our equivalent would probably be something like an extended attribute, but like on the Mac, that would fall flat on non-native filesystems. Hence the following additional measures also make the system recognize an application bundle
2. A directory that ends in .app. Our equivalent would be .AppDir. It is explicitly mentioned that you are not forced to use that extension, since there is also a third option
3. A file called PkgInfo in the top-level diretory of the bundle. It is explicitly mentioned that this holds type and creator information redundant what is stored elsewhere, for performance reasons

What triggers system integration

1. When you put an application into one of several "well-known" Applications directories (most likely, /Applications, /Network/Applications, /Users/$USER/Applications. Our equivalent would be to watch /Applications, $HOME/Applications, and possibly /Applications on each newly mounted partition using inotify. Note that the Downloads directory is not part of those. It is explicitly mentioned that while applications get integrated into the system immediately when you put them there, you can also put them into other locations where they will be picked up by the following additional measures
2. When you launch an application. Our equivalent would be to catch each application launch, possibly using binfmt, and silently integrate the application into the system when it is launched. It is mentioned that once they integrate an application, they also check the directory containing that application for other applications (but most likely not the directory's subdirectories to prevent situations like these).
3. When you "look at" an application. Presumably they mean viewing a directory in the Finder. Our equivalent would be a thumbnailer (normally used to render preview icons) that gets executed whenever one "looks at" a directory.

Registers an application, designated by URL, in the Launch Services database.

According to (Singh, 2006) system integration is also triggered

5. When the system is booted (What exactly happens then?)
6. When a user logs in (What exactly happens then?)
7. When the Finder locates a new application, such as on a newly mounted disk image - say, one that has been downloaded from the Internet (What exactly happens then?)

Additionally,

8. When an application explicitly triggers integration. An application, such as a web browser downloading an application or an archive manager unpacking an application, can call LSRegisterURL(_:_:). Note that one cannot rely on applications doing this. Our equivalent would be to offer a dbus message that when called would trigger system integration.

What happens when you double-click

• Each application has a type and a creator code (four characters each - this concept is inherited from Classic Mac OS)
• The system keeps a database, built from metadata that travels inside each AppDir's Info.plist file, containing, among other things, the file types the application can handle and the application version. Our equivalent would roughly be the desktop file amended with the X-AppImage-Version field. (Possibly we should settle on a YAML file that would combine what is in .desktop and AppStream metainfo files today.) The database is populated by the triggers described above
• When a file ("document" in Apple terminology) is double-clicked, the database is queried for the newest version of an application that can handle this type of file
• It is possible to tell the system that certain files shall be opened by certain applications (e.g., one jpg in Photoshop and another jpg in Dreamweaver)
• When you double-click a document for which there is no known application, then you are presented with a file chooser window that will select you the application to open the file with
• No icons are copied around. Presumably the system queries the database to display application and document icons

Note that the only time the system asks the user something is when it doesn't know which application to open a file with, which rarely happens in practice, given the combination of the three triggers described above.

The database

The Launch Services registration database can be dumped like this:

(Singh, 2006)

Additional information

A year later, the concepts were covered again in WWDC 2001 Session 114, Application Packaging and Document Binding.

"Document Binding is what associates, on the fly, documents in the file system with the applications that can handle them, it's what makes double click work".

In Desktop Linux, we are not doing this "on the fly" yet. We should!

Bindings Database

Note that applciations also can make use of "packages", that is folders displayed as files.

The relevant Property List keys start with CFBundle (it's all defined by Core Foundation).

It gets populated by reading the Info.plist files that travel inside the applications (and other types of packages). Today, one would probably use YAML or JSON instead of XML.

Applications and documents have type and creator codes. The type of an application is always APPL. The creator code is what generally binds, e.g., text files which have the type TEXT (roughly equaling a MIME type) to one certain application that can handle text files (e.g., the SimpleText application). This concept seems to be missing in Desktop Linux entirely, which is why documents of the same MIME type never get opened by the application that created them, but rather by some "random" application that happens to also handle the same MIME type.

Do we need to invent/specify "MIME creators" in addition to MIME types to match what the Mac has had for a long time?

1. The user can set a certain document to open with a certain application manually
2. The system checks for the creator code of the document and looks up applicaion(s) with that type. In case there are multiple apps with that type, the latest version is taken. If there are multiple apps with the same version, the app with the latest modification date is taken
3. Extensions. User can say "open all html files in the browser"
4. OSType

"Launch Services is the engine that does document binding." "It maintains the Bindings Database." (Not to be confused by the deprecated Classic Mac OS "DesktopDB".) On Desktop Linux, xdg-open is similar to using Launch Services to open something ("Essentially the same as double-clicking"), and mimeinfo is similar to using Launch Services to get the binding (but not quite yet!).

TODO: Check LaunchServices.h header documentation and the Launch Services TechNote.

How do you ensure that you are in the Bindings Database?

The Finder (file manager) is solely responsible for updating the Bindings Database. Whenever the user logs in, the Finder looks in some well-known places auch as the main Applications folder and the user's application folder. It scans the sub-folders as well. Other applications are added to the database when launched from the Finder.

On Desktop Linux, file managers don't do this (yet). So we have to have some other part do this job, e.g, something like appimaged in combination with thumbnailers?

Application installers can send kAFSync AppleEvent. The Desktop Linux equivalent would be to send a dbus message to appimaged.

Linux needs a bindingsd to handle

• Applications
• Documents
• Icons
• MIME types
• URL schemes
• Creators
  and how they work together, DYNAMICALLY ON THE FLY.

Without the collaboration of file managers, we can abuse thumbnailers to do part of the job.

How can we "properly" achieve similar results on Desktop Linux?

• Desktop Linux so far seems to be lacking the equivalent of Launch Services. Could systemd be a place for it? I've talked about this at https://media.ccc.de/v/ASG2018-174-2018_desktop_linux_platform_issues
• Would the XDG specifications need to be changed or amended?

Singh, A. (2006). Mac OS X Internals. Boston: Addison Wesley Professional, pp. 828-830.

Possible stakeholders

System integration for applications and "document binding" a.k.a. file association is a community-wide topic and should be addressed as such. Possible stakeholders might be:

• Snappy. snapd currently needs to copy around files in order to achieve desktop integration. Snappy would benefit from a Launch Services equivalent
• Flatpak. It, too, currently needs to copy around files in order to achieve desktop integration. Flatpak would benefit from a Launch Services equivalent
• GNUstep. A free software implementation of the NeXT/Apple desktop for Unix-like operating systems. Especially we should check what their GWorkspace file manager does in terms of desktop integration, and whether there are .app bundles/AppDirs of some sort. http://www.gnustep.org/experience/screenshots/GWorkspace-screenshot.jpg has a promising-looking screenshot with /System/Applications. Does it work like the real deal, though?
• https://github.com/darlinghq/darling. A runtime for Mac apps on Linux. If the new proposed system could recognize existing Mac bundles, such apps could be integrated into the system properly
• File manager developers (e.g., Nautilus, Dolphin, etc.)
• Sycoca/kded developers. It is a per-user database for servicetypes, mimetypes and services) that gets updated when certain triggers occur. Might be turned into or replaced by the system described above. Currently seemingly limited to KDE (not cross-desktop like systemd, dbus and the like)
• Deepin Linux. A Linux distribution with some AppImage support in their file manager
• Nitrux OS. A Linux distribution that comes with AppImage integration out of the box
• Electron app authors. Electron apps are often produced by cross-platform developers who may or may not be Linux users, and often distribute applications for Windows, Linux, and the Mac e.g., in zip files. Maybe @develar as the maintainer of widely-used Electron tools would be interested to represent this group

What would be a suitable forum for driving this topic community-wide?

• The Linux Foundation. Probably not a good match since what we colloquially call the "Linux" desktop is not really limited to that particular kernel. But then, the Linux Foundation is also driving other projects that are not strictly limited to the kernel of the same name. However, they seem to focus on topics that are relevant to paying member corporations, which currently happen to be more interested in server-side technologies such as containers and container orchestration rather than the desktop. Yet still, Linus Torvalds claims the desktop is relevant to him... Looking at https://www.linuxfoundation.org/projects/hosting/#getstarted it seems they are open to hosting open source projects, but out topic would initially be more of a discussion and conventions-forming effort. It is currently unknown whether that group is interested in the subject.
• freedesktop.org, specifically XDG. A group that standardizes conventions for the "Linux Desktop" for use in desktop environments such as GNOME, KDE, and Xfce. It is currently unknown whether that group is interested in the subject but according to their Wiki, they "host any 'on-topic' software projects" and "developers working on any Linux/UNIX GUI technology are welcome to participate". Looking at Specifications currently in the planning/requirements-gathering stages it seems like this topic would definitely be a good fit there, even at this early stage. The shared-mime-info-spec describes a database for aspects of this overall topic (and has an implementation) and might be folded into or replaced by something with a broader scope than just MIME types. A list of the current "owners" of the XDG specs can be seen here.
• The systemd project. So far concerned with integrating services and dynamically launching services on Linux. Could possibly be extended to handle desktop applications as well. To do this, has much of the infrastructure in place that might be needed for a Launch Services and "document binding" equivalent. It is currently unknown whether that group is interested in the subject. Being hosted on freedesktop.org, it may be part of the technical solution but it seems that discussion of this topic should occur in the umbrella project.

So, on first sight it appears that freedesktop.org might be a suitable place for this kind of discussion and standardization, if we can get "non-distribution" people (like application authors and users) involved there, too.

Scope

What exactly would be the scope of "this topic"?

• A per-user dynamic application database used by the system (file manager and other components) to store information about applications available to the user (installed on the system or otherwise accessible, e.g., on attached storage media or network shares), application metadata, file associations, MIME types, icons, including user choices about per-file application/document associations. This should be generic enough as to also apply to "traditional" systems that do not use AppImage, AppDir, Snappy, Flatpak or any such systems. The spec should define the logic of how this database gets populated/updated, the meaning of its contents, and how the information should be used by the system. It should also define how to interact with this per-user database, e.g., over dbus. It does not necessarily have to define the inner workings of the database, which can be considered implementation details.
• A specification for application (bundle) metadata, e.g., an updated AppDir specification. This should describe how metadata that shall travel along with applications (e.g., in a bundle, a zip file, a snap, etc. - everywhere except in a package manager package) should be stored, so that the dynamic application database can read it. Possibly this could be made generic enough so as to also cover the metadata coming with Mac OS X bundles, Snaps, Flatpaks etc.

Somewhat related, but we should take care to keep this separate:

• Possibly even the AppImage specification (which would basically say that it is a self-mounting fileystem containing an AppDir). This should be updated to point to the above where required.

For apps such as LibreOffice, having one application icon is not always enough, for example, it might be useful to have LibreOffice Writer, LibreOffice Calc etc.

Is it possible to do this with appimaged?

See curl -sSL https://get.rvm.io | bash -s stable --ruby how it informs about missing keys.

Thumbnailer does not work in all locations watched by appimaged, e.g., $HOME/bin:

When moved to $HOME/bin, then the AppImages do show their icons for me. Xubuntu 16.04 Live ISO.

(from AppImage/AppImageKit#577)

Currently we are writing desktop files as soon as we have extracted them to .local/share - this triggers some desktop managers to rebuild the menus after every desktop file, resulting in a major slowdown of the system.
So instead, we should extract them to a temp location and only after we are "done" (as in: we did not process any new AppImages in the last second or so), move them in together at once.

The the desktop file is a symlink, then it currently does not work. (libappimage should handle those implementation details, with no actual integration code to be left in appimaged.)

My AppImages are not set executeable automatically.

I am using Xubuntu 18.04 Bionic.
I installed the appimage of appimaged.

Everything else seams to work.

my terminal output:

(appimaged:7559): GLib-CRITICAL **: 12:25:27.996: g_file_test: assertion 'filename != NULL' failed
Updating desktop...
gtk-update-icon-cache: The generated cache was invalid.
Warning: gtk-update-icon-cache retuned non-zero exit code:
kbuildsycoca5 running...
Finished updating desktop in 374 milliseconds.

I think it would be good if we were able to set recursion level.

I have several big libraries/frameworks in Applications folder (Android studio, android sdk, 4-5 versions of Qt, golang, etc), on start appimaged take a long time to check all the files.

wget -c "https://github.com/AppImage/appimaged/releases/download/continuous/appimaged_1.0_amd64.deb"
from https://github.com/AppImage/appimaged
gives me 404: Not found

I have a multiboot system where I can boot into 32-bit and 64-bit systems using SystemImageKit and many different Live ISOs.

When I boot into a 32-bit system, I don't want appimaged to register 64-bit AppImages, and vice versa. So only AppImages from the matching architecture should be registered by appimaged.

This can probably be achieved by checking some more magic bytes.

Since the move into this repository, 32-bit builds are now missing @TheAssassin

I placed GitHubDesktop-linux-1.6.0-linux1.AppImage in a folder appimaged scans.
/home/$USER/.local/bin/

Then appimaged crashed with:
munmap_chunk(): invalid pointer
Aborted (core dumped)

So do not place it in common folders for appimaged.
But run it once, then it will create its own working starter.

https://github.com/shiftkey/desktop/releases/download/release-1.6.0-linux1/GitHubDesktop-linux-1.6.0-linux1.AppImage

openSUSE-Leap-15.0-GNOME-Live-x86_64-Current.iso

Hangs around

-> Registering type 1 AppImage: /isodevice/Applications/Atom-1.4.0-x86_64.AppImage
_________________________
Blindly assuming AppImage type 1
The author of this AppImage should embed the magic bytes, see https://github.com/AppImage/AppImageSpec
AppImage type: 1
Opening /isodevice/Applications/Atom-1.4.0-x86_64.AppImage as Type 1 AppImage
Closing /isodevice/Applications/Atom-1.4.0-x86_64.AppImage
ISO9660 based type 1 AppImage
Got root desktop: atom.desktop
.upd_info offset: 33651
.upd_info length: 512
Installing desktop file
/tmp/appimagekit_85842ddfe0bca6805c9873382d0fd022_atom.png has nonstandard size w = 1024, h = 1024; please fix it

Investigate whether we can use systemd Path Units rather than using inotify ourselves. This would simplify the tool, make it more flexible (could be triggered in different ways), and would even make the search paths user-configurable (through systemd).

https://www.linuxjournal.com/content/linux-filesystem-events-inotify (search for "Path Units under systemd").

Continuation of #6 (comment)

Profile CPU usage to find out what causes appimaged to consume 100% CPU at startup for 10+ seconds.

For CPU bound applications:
Use a profiler in DEBUG mode to identify questionable parts of your code
Then switch to RELEASE mode and comment out the questionable sections of your code (stub it with nothing) until you see changes in performance.

https://stackoverflow.com/questions/375913/how-can-i-profile-c-code-running-on-linux/378024

I tried latest version after build::
..
-> Skipping file /home/build/.ccache/a/7/3ebc5795520dd1b3d811667b71ffa2-221899.stderr
Unrecognized file '/home/build/.ccache/a/7/35df42cef21ca8f2f81c21aee72aa0-1971750.o'
-> Skipping file /home/build/.ccache/a/7/35df42cef21ca8f2f81c21aee72aa0-1971750.o
Unrecognized file '/home/build/.ccache/a/7/01a65572cb4b074af8a9ba745e5b74-876796.stderr'
-> Skipping file /home/build/.ccache/a/7/01a65572cb4b074af8a9ba745e5b74-876796.stderr
Unrecognized file '/home/build/.ccache/a/7/31d45aa27737fc79647612e5f30c34-6353.manifest'
-> Skipping file /home/build/.ccache/a/7/31d45aa27737fc79647612e5f30c34-6353.manifest
..
Why scanning this path? I patched main.c and I tried isolate scanning to ~/bin but seem this is not enough

¿Can we have a compilation readme for this? I can't get it to compile

Clear Linux OS is a performance-oriented distribution by Intel with interesting features (that align well with AppImage philosophy), without a traditional package manager. It boots from scratch to a full desktop in about 4 seconds(!) on my moderate system.

We should get appimaged packaged properly for it. The appimaged AppImage runs just fine on Clear Linux OS after having made the FUSE kernel module load automatically like this:

sudo su
mkdir -p /etc/modules-load.d/
echo "fuse" > /etc/modules-load.d/fuse.conf
reboot

Original issue: AppImage/AppImageKit#754

appimaged_1-alpha-gitabc1464.travis9_amd64.deb should link libappimage statically since the library does not have a stable public ABI yet