appimage / appimagekit Goto Github PK

Right now, it seems that AppImageAssistant just selects the first *.desktop file in an app directory, even if there are multiple.

(apt-appdir's app directories, at the very least, can suffer from this problem. And the tool I wrote this afternoon that uses Mock has the same problem... if not worse, because usually more dependencies get pulled in).

Is it possible to handle this better? I would think that some combination of the below might be reasonable:

1. defaulting to $APP.desktop in the event of multiple files.
2. prompting the user/accepting a command line switch for "name of desktop file".
3. prompting the user/accepting a command line switch for the name/binary name (and defaulting to some template icon).

I'd be willing to contribute some code to make this better, but I figured I'd ask first. :)

According to http://listaller.tenstral.net/docs/chap-Listaller-ManualPages.html#idp15415040 ligcc is a wrapper around gcc. It allows you to create more portable executables:

• Forces the linker to link against older glibc symbols. Users who are using an older version of glibc will no longer get "undefined symbol GLIBC_2.4 in /lib/libc.so"-style error messages.
• Allows you to easily statically link to any other library.
• Automatically removes bogus dependencies. For example, your program uses libfoo. libfoo uses libpng internally, but your app does not. Yet the pkg-config file for libfoo specifies "-lfoo -lpng" is linker parameters. And tadaa - you now have a bogus dependency on libpng! LiGCC automatically removes the -lpng for you if your app doesn't use libpng directly.
• Add $ORIGIN/../lib to the binary's library search path. $ORIGIN is the directory in which the binary exists. This ensures that your binary can find library dependencies which are placed in the 'lib' folder under the same prefix. You might want to install custom libraries into /lib. If you set $APBUILD_PROJECTNAME, ligcc will also add $ORIGIN/../lib/$APBUILD_PROJECTNAME to the library search path.

[desktopintegration] Consider having AppImageAssistant/package do this automatically

It would be great if AppImageMonitor had an option for setting the location of the apps directory via a CLI option.

./monitorAppImages.sh --appimage-dir /Apps

Some other features that would be cool:

1. Multiple app paths i.e. /Apps or ~/Apps.
2. Install .desktop file to ~/.local/share/applications if the app image is in ~/Apps or install the .desktop file to /usr/share/applications if the desktop file is in a global location (i.e. /Apps)

Please let me know your thoughts. I'm happy to build this functionality and submit a pull request if this is something that would be useful for others.

# Ubuntu 15.10
me@host:~/AppImageKit$ ./AppImageMonitor
7222 (process ID) old priority 0, new priority 1
Directory /home/me/Applications/ doesn't exist
me@host:~/AppImageKit$ mkdir  /home/me/Applications/
me@host:~/AppImageKit$ ./AppImageMonitor
7237 (process ID) old priority 0, new priority 1
Watching /home/me/Applications/...
The databases in [//home/me/.local/share/applications] could not be updated.
./bin//monitorAppImages.sh: line 141: inotifywait: command not found

It should:

• Create the needed directories
• Watch $HOME/Downloads. It could ask whether it should do that.
• Make AppImages executable after asking
• Optionally install the .desktop file and icon into the system. It could ask whether it should do that.
• Use the same logic and location for the icon as runtime.c so that we don't extract the same icon in multiple locations

Currently I have to do yum install pygtk2 libpng12 to run AppImageAsistant on Fedora 23 even though I do not use the GUI at all. We should only import the GUI stuff if it is needed.

"CARE monitors the execution of the specified command to create an archive that contains all the material required to re-execute it in the same context. That way, the command will be reproducible everywhere, even on Linux systems that are supposed to be not compatible with the original Linux system. CARE is typically useful to get reliable bug reports, demonstrations, artifact evaluation, tutorials, portable applications, minimal rootfs, file-system coverage, ..."
http://reproducible.io

"Users can use the built-in mount/bind mechanism to access files and directories from the actual root file-system, a.k.a host rootfs, just as if they were part of the guest rootfs."
http://proot.me

Possibly this is a good way to generate AppDirs... or possibly we could integrate it with AppImageKit, so that CARE can generate AppImages directly...

On Fedora 23 I get:

sudo yum install git cmake binutils fuse glibc-devel glib2-devel fuse-devel gcc zlib-devel libpng12 vala libgee-devel
(...)
[ 23%] Linking C executable runtime
CMakeFiles/runtime.dir/runtime.c.o: In function `md5_buffer':
/home/me/AppImageKit/md5.c:178: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
libisofs.a(isofs.c.o): In function `isofs_parse_zisofs_header':
/home/me/AppImageKit/isofs.c:728: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
libisofs.a(isofs.c.o): In function `isofs_real_read':
/home/me/AppImageKit/isofs.c:1799: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
libisofs.a(isofs.c.o): In function `isofs_real_read_zf':
/home/me/AppImageKit/isofs.c:1716: undefined reference to `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
/usr/bin/ld: runtime: No symbol version section for versioned symbol `memcpy@GLIBC_DONT_USE_THIS_VERSION_2.14'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: Fehler: ld gab 1 als Ende-Status zurück
CMakeFiles/runtime.dir/build.make:96: recipe for target 'runtime' failed
make[2]: *** [runtime] Error 1
CMakeFiles/Makefile2:298: recipe for target 'CMakeFiles/runtime.dir/all' failed
make[1]: *** [CMakeFiles/runtime.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

[desktopintegration] Xdialog window does not scale when the text to be displayed is long

testappimage can be used to quickly test an AppImage on a bunch of Live ISOs. Right now it works with Ubuntu, Fedora, debian (like) systems.

We should make testappimage work with openSUSE Tumbleweed Live ISOs, too.

AppImageAssistant 0.9 runs perfectly fine, but AppImageAssistant 0.9.2 and 0.9.3 don't.

I receive this error in both:

Traceback (most recent call last):
  File "/tmp/.mount_xzkzoH/AppImageAssistant", line 54, in <module>
    import  gtk, vte
RuntimeError: could not find _PyGtk_API object

If I unpack the AppImage and run the AppRun, I get the same error, but if I run the AppImageAssistant instead, it works correctly.

If I place the AppRun from 0.9 into 0.9.3, it works, but as soon as I add this, it fails:

PYTHONPATH=./usr/share/pyshared:"$PYTHONPATH"

While https://github.com/probonopd/AppImageKit/tree/master/AppImageUpdate.AppDir does mostly what we need, we should check out

https://github.com/getlantern/autoupdate

which seems to follow a similar pattern.

Hey,

Great work on AppImageKit, it is a brilliant way to make Linux apps simple for end-users.

I'm actually building a Linux distro based on the AppImage concept, which will use AppImages as the primary way to install applications.

I saw a video on YouTube, which I believe you created, please correct me if I'm wrong: https://www.youtube.com/watch?v=uNmYrxjTkek

I'm really interested in using this integration, but I can no longer find any reference to it on the portablelinuxapps.org website.

Is there anywhere I can find the gnome integration, and/or the source code for it?

The topmost .desktopfile in the root directory of the AppDir/AppImage should be enriched with additional lightweight metadata related to the AppImage.

http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s11.html

PortableLinuxGames apparently already has defined some.

• X-AppImage-Name: Name of the application (e.g., Krita)
• X-AppImage-Version: Version of the application that is contained in the AppImage (e.g., 1.3.1)
• X-AppImage-Arch: Architecture of the AppImage (e.g., x86_64)
• X-AppImage-Release: Version or timestamp of the AppImage itself (added at AppImage creation time)
  ...

However. let's try not to be redundant to AppStream information. So let's not include the license, the URL, etc.

The AppStream specification describes the AppStream upstream XML format which is used by upstream software authors to describe the software component (application, firmware, font, ...) they provide, as well as the AppStream distro XML format that is used by distributions to ship the metadata in bundled and processed form to their users.

Ideally, apps would be packaged by the upstream projects, and a repository of apps including version and update information, screenshots, as well as stars (or AppStream kudos) could be built. When I tried to do this a decade ago for klik and later for PortableAppImages, cross-distribution metadata infrastructure was not available, but now it begins to fall into place.

AppStream distribution XML files could be parsed.
Debian collects icons and app metadata here:
https://appstream.debian.org/data/unstable/main/

It looks like AppStream is built with Xapian in mind. Xapian is an Open Source Search Engine Library, released under the GPL. It's written in C++, with bindings to allow use from Perl, Python, PHP, Java, Tcl, C#, Ruby, Lua, Erlang and Node.js (so far!)

cmake must be run in the top-level dir, or default make target fails:

$ git clone https://github.com/probonopd/AppImageKit.git
...
$ cd AppImageKit/
$ git describe --tags
20151218-50-g10b84ee

$ mkdir build
$ cd build/
$ cmake ..
-- The C compiler identification is GNU 5.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found glib-2.0: /usr/include/glib-2.0, /usr/lib/x86_64-linux-gnu/libglib-2.0.so
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/AppImageKit/build
rgareus@soyuz:/tmp/AppImageKit/build$ make
Scanning dependencies of target isofs
[ 12%] Building C object CMakeFiles/isofs.dir/isofs.c.o
In file included from /usr/include/stdio.h:27:0,
                 from /tmp/AppImageKit/isofs.c:24:
/usr/include/features.h:148:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
   ^
/tmp/AppImageKit/isofs.c: In function ‘isofs_parse_sa’:
/tmp/AppImageKit/isofs.c:1066:33: warning: passing argument 2 of ‘fprintf’ makes pointer from integer without a cast [-Wint-conversion]
                                 sue_len, sue_version);
                                 ^
In file included from /tmp/AppImageKit/isofs.c:24:0:
/usr/include/stdio.h:356:12: note: expected ‘const char * restrict’ but argument is of type ‘int’
 extern int fprintf (FILE *__restrict __stream,
            ^
[ 25%] Linking C static library libisofs.a
[ 25%] Built target isofs
Scanning dependencies of target fuseiso
[ 37%] Building C object CMakeFiles/fuseiso.dir/fuseiso.c.o
/tmp/AppImageKit/fuseiso.c: In function ‘del_mount_point’:
/tmp/AppImageKit/fuseiso.c:78:14: warning: implicit declaration of function ‘rmdir’ [-Wimplicit-function-declaration]
     int rc = rmdir(mount_point);
              ^
/tmp/AppImageKit/fuseiso.c: In function ‘isofs_init’:
/tmp/AppImageKit/fuseiso.c:110:5: warning: implicit declaration of function ‘run_when_fuse_fs_mounted’ [-Wimplicit-function-declaration]
     run_when_fuse_fs_mounted();
     ^
[ 50%] Linking C static library libfuseiso.a
[ 50%] Built target fuseiso
Scanning dependencies of target runtime
[ 62%] Building C object CMakeFiles/runtime.dir/runtime.c.o
/tmp/AppImageKit/runtime.c: In function ‘main’:
/tmp/AppImageKit/runtime.c:211:6: warning: implicit declaration of function ‘g_build_filename’ [-Wimplicit-function-declaration]
     ? g_build_filename(g_get_home_dir(), ".cache", NULL)
      ^
/tmp/AppImageKit/runtime.c:211:23: warning: implicit declaration of function ‘g_get_home_dir’ [-Wimplicit-function-declaration]
     ? g_build_filename(g_get_home_dir(), ".cache", NULL)
                       ^
/tmp/AppImageKit/runtime.c:212:7: warning: implicit declaration of function ‘g_strdup’ [-Wimplicit-function-declaration]
     : g_strdup(getenv("XDG_CACHE_HOME")));
       ^
/tmp/AppImageKit/runtime.c:210:18: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
   xdg_cache_home = (getenv("XDG_CACHE_HOME") == NULL
                  ^
[ 75%] Linking C executable runtime
[ 75%] Built target runtime
Scanning dependencies of target AppImageAssistant
cp: cannot create regular file ‘AppImageAssistant.AppDir/’: Not a directory
CMakeFiles/AppImageAssistant.dir/build.make:61: recipe for target 'AppImageAssistant' failed
make[2]: *** [AppImageAssistant] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/AppImageAssistant.dir/all' failed
make[1]: *** [CMakeFiles/AppImageAssistant.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

AppImageAssistant -t (aka testappimage) has issues with rpm: When trying to install packages, we can sometimes get

error: unpacking of archive failed on file (...): cpio: chown

Trying again a couple of times usually resolves these issues and finally rpm succeeds.

Maybe it is related to
https://features.opensuse.org/312718

librpm cannot deal with updating the attributes of a directory-type inode that has been hidden by a new directory-type inode of another vfsmount

On Fedora 23, python2 is no longer installed by default but python3 is. Can we make a wrapper that selects python2 or 3 to run our stuff if we make the stuff python3 compatible (maybe using from future import...)?

Hey, I just have a few quick questions. If anyone could give me some advice then that would be great. Just figured it would be a lot easier to ask, rather than tinkering for hours, trying to achieve something that someone else might have already achieved.

1. Just wondering if its possible to set AppImages as "default" apps in GNOME?

I have converted Epiphany (GNOME Web Browser) into an AppImage, and it works perfectly. However, there seems to be no way for me to set the AppImage as the default app for opening websites.

1. The Epiphany AppImage also doesn't add the "Search Provider" to GNOME. Could this potentially be something that is integrated into AppImageMonitor? Or is this too distro/desktop-environment specific?

lrwxrwxrwx 1 raziel raziel 76 Mar 20  2015 AppDirAssistant.AppDir/usr/bin/AppImageKit/bin/strace -> /home/liveuser/Desktop/AppDirAssistant 0.3.2p1.AppDir/usr/bin/strace_private

Shouldn't we include the proper strace binary?

So I got Cheese to work correctly by running my AppRun script directly.

I packaged the AppImage using the package binary in AppImageAssistant.AppDir, but I'm getting the following error when running the AppImage.

execv error: Exec format error

Gnome Software is supposed to be modular and supposedly supports plugins for other software distribution mechanisms such as AppImage. Is there any documentation on how to write a plugin, preferably in Vala?

Need to investigate gs-plugin-limba.c, too.

Fedora Mate 21 64bit
binary download from
http://portablelinuxapps.org/

$ ./"AppDirAssistant 0.3.3-64bit"
Traceback (most recent call last):
File "./bin//appimager", line 263, in
main()
File "./bin//appimager", line 249, in main
then = datetime.datetime.fromtimestamp(os.path.getctime(filefortime))
File "/usr/lib64/python2.7/genericpath.py", line 64, in getctime
return os.stat(filename).st_ctime
OSError: [Errno 2] file not found: '/usr/bin/ld'

ifireball/btsync-app#1 (comment):

I'd like to be able to build only what's needed for the 'package' script without the rest of the AppImageAssistant GUI. It would also be nice if there was a stand-alone release of that, so it could be packaged as a build tool in distros.

Pull requests are welcome.

Investigate WebTorrent (BitTorrent over WebRTC) for distributing apps.
https://webtorrent.io/

Maybe a small daemon could share the applications present on the system unless they have a "do not share" bit set.

Or https://github.com/inizan-yannick/libtorrent-c

Scribus-1.5.1.svn.20670-x86_64.AppImage on ubuntu-15.10-desktop-amd64.iso has this issue.
Interestingly enough, Subsurface does not have this issue.

zlib is ubiquitous, but it's a potential portability problem, and can be easily avoided linking statically: http://pastebin.com/GJJ3qjxM

Overhead in the runtime binary is about 32Kb

I'm trying to create appimages of Pale Moon for Linux on Xubuntu 14.04. AppDirAssistant correctly detects the files and folders installed, but does not create an Apprun and the .DirIcon file.

Latest released versions (available on portablelinuxapps.org) have been used for this purpose.

$ ./AppDirAssistant
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python: ../../src/xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
0
[<class '__main__.WelcomePage'>, 'Welcome']
Preparing <WelcomePage 'Welcome'>
Preparing <TooNewPage 'Warning'>
Preparing <InstallNowPage 'Install your application now'>
Preparing <ProfilerPage 'Profiling...'>

See the "DebConf 14_ QA with Linus Torvalds" video where Linus addresses some of the issues that AppImageKit tries to solve.

At 05:40 Linus highlights a core issue for Linux on the desktop, application packaging: "I'm talking about actual application writers that want to make a package of their application for Linux. And I've seen this firsthand with the other project I've been involved with, which is my divelog application. We make binaries for Windows and OS X. We basically don't make binaries for Linux. Why? Because binaries for Linux desktop applications is a major f*ing pain in the ass. Right. You don't make binaries for Linux. You make binaries for Fedora 19, Fedora 20, maybe there's even like RHEL 5 from ten years ago, you make binaries for debian stable, or actually you don't make binaries for debian stable because debian stable has libraries that are so old that anything that was built in the last century doesn't work. But you might make binaries for debian... whatever the codename is for unstable. And even that is a major pain because (...) debian has those rules that you are supposed to use shared libraries. Right. And if you don't use shared libraries, getting your package in, like, is just painful. But using shared libraries is not an option when the libraries are experimental and the libraries are used by two people and one of them is crazy, so every other day some ABI breaks. So you actually want to just compile one binary and have it work. Preferably forever. And preferably across all Linux distributions. And I actually think distributions have done a horribly, horribly bad job. One of the things that I do on the kernel - and I have to fight this every single release and I think it's sad - we have one rule in the kernel, one rule: we don't break userspace. (...) People break userspace, I get really, really angry. (...) And then all the distributions come in and they screw it all up. Because they break binary compatibility left and right. They update glibc and everything breaks. (...) So that's my rant. And that's what I really fundamentally think needs to change for Linux to work on the desktop because you can't have applications writers to do fifteen billion different versions."

Hence, we should package the Subsurface app and make it run on the above-mentioned distributions (and others):
https://subsurface-divelog.org/de/download/

Clean up AppDirAssistant, make it multiarch, and generate it as part of the CMake process

Is it possible to statically link libfuse.so.2 into runtime and still have a binary small enough to be embedded into the header padding of an ISO file?

This was suggested by @frerich in the discussion thread to Linus Torvalds' "This is just very cool" blog post.

If we attempt this, we should do so in a separate feature branch.

EDIT: Done, you can skip this thread right to #45 (comment)

I tried adding

set(BUILD_SHARED_LIBS ON)
set(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
set(LINK_SEARCH_START_STATIC TRUE)
set(LINK_SEARCH_END_STATIC TRUE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")

to the CMakeLists.txt but this did not work, as I get

[ 83%] Linking C executable runtime
/usr/bin/ld: attempted static link of dynamic object `libfuseiso.so'
collect2: error: ld returned 1 exit status
CMakeFiles/runtime.dir/build.make:96: recipe for target 'runtime' failed
make[3]: *** [runtime] Error 1
CMakeFiles/Makefile2:292: recipe for target 'CMakeFiles/runtime.dir/all' failed
make[2]: *** [CMakeFiles/runtime.dir/all] Error 2
CMakeFiles/Makefile2:304: recipe for target 'CMakeFiles/runtime.dir/rule' failed
make[1]: *** [CMakeFiles/runtime.dir/rule] Error 2
Makefile:196: recipe for target 'runtime' failed
make: *** [runtime] Error 2

Hi,

I've been successful at packaging most basic apps using AppImageKit. However, I'm trying to package the "Cheese" app into an AppImage, but I'm getting the following error.

GLib-GIO-Error **: Settings schema 'org.gnome.Cheese' is not installed

Any ideas?

Hi,

While working on the mock-appdir tool (#23), I noticed that you aren't excluding the compiled Python files (*.pyc) from version control. For example, this blob.

Is there a reason for this? It makes writing code, testing it, and then committing it slightly messier, because the *.pyc files change and are flagged as being "modified" by git.

On Fedora 23: sudo yum install pygtk2

I got an arch linux installation, download the OpenOffice, Inkscape and gPodder and none of them would start. I chmod +x and did the ./app and got:
'No such file or directory'

Could it be that is not 32/64 bits?

Regards.

Using Raspbian GNU/Linux 7 (wheezy), I get the following error:

pi@raspberrypi ~/AppImageKit $ LANG="" cmake .
-- The C compiler identification is unknown
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
  The C compiler "/usr/bin/gcc" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /home/pi/AppImageKit/CMakeFiles/CMakeTmp



  Run Build Command:/usr/bin/make "cmTryCompileExec1900124640/fast"

  /usr/bin/make -f CMakeFiles/cmTryCompileExec1900124640.dir/build.make
  CMakeFiles/cmTryCompileExec1900124640.dir/build

  make[1]: Entering directory '/home/pi/AppImageKit/CMakeFiles/CMakeTmp'

  /usr/bin/cmake -E cmake_progress_report
  /home/pi/AppImageKit/CMakeFiles/CMakeTmp/CMakeFiles 1

  Building C object
  CMakeFiles/cmTryCompileExec1900124640.dir/testCCompiler.c.o

  /usr/bin/gcc -o CMakeFiles/cmTryCompileExec1900124640.dir/testCCompiler.c.o
  -c /home/pi/AppImageKit/CMakeFiles/CMakeTmp/testCCompiler.c

  /home/pi/AppImageKit/CMakeFiles/CMakeTmp/testCCompiler.c:1:0: internal
  compiler error: Segmentation fault

  Please submit a full bug report,

  with preprocessed source if appropriate.

  See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.

  Preprocessed source stored into /tmp/cc4l7dHS.out file, please attach this
  to your bugreport.

  CMakeFiles/cmTryCompileExec1900124640.dir/build.make:57: recipe for target
  'CMakeFiles/cmTryCompileExec1900124640.dir/testCCompiler.c.o' failed

  make[1]: Leaving directory '/home/pi/AppImageKit/CMakeFiles/CMakeTmp'

  make[1]: *** [CMakeFiles/cmTryCompileExec1900124640.dir/testCCompiler.c.o]
  Error 1

  Makefile:114: recipe for target 'cmTryCompileExec1900124640/fast' failed

  make: *** [cmTryCompileExec1900124640/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:3 (PROJECT)


-- Configuring incomplete, errors occurred!

Should all these binaries be removed?

16:23:55 (experimental) ~/dev/AppImageKit$ find ./AppDirAssistant.AppDir/usr/bin/AppImageKit/{bin,lib}
./AppDirAssistant.AppDir/usr/bin/AppImageKit/bin
./AppDirAssistant.AppDir/usr/bin/AppImageKit/bin/cmginfo
./AppDirAssistant.AppDir/usr/bin/AppImageKit/bin/strace
./AppDirAssistant.AppDir/usr/bin/AppImageKit/lib
./AppDirAssistant.AppDir/usr/bin/AppImageKit/lib/libisoburn.so.1
./AppDirAssistant.AppDir/usr/bin/AppImageKit/lib/libburn.so.4
./AppDirAssistant.AppDir/usr/bin/AppImageKit/lib/libisofs.so.6

I guess all the libs are safe to remove, but that about the bins? Is cmginfo used at all anymore? It seems to be used from AppImage.py, but I don't know if that code is alive.

Especially for runtime.c and AppRun.c we should really use LibcWrapGenerator

[desktopintegration] Root = system wide install does not work

We should get this to build on travis-ci for Intel 32-bit and 64-bit and possibly for some other architectures as well. We should use https://github.com/probonopd/AppImageKit/blob/master/LibcWrapGenerator/README

Possibly we could even use travis-ci for some apps packaging testing and packaging workflow; especially if we could have some ISOs that we can loop-mount and chroot into.

That would be useful feature to use on systems where GUI environment is not present.

Hi there,

Are there any docs on creating AppImage's from pacman packages, or creating an AppImage from source?

[desktopintegration] When installed systemwide, then do not ask user

While glib is commonplace in most systems, it's not always available in many minimalistic systems, like TinyCoreLinux, and this dependency should be avoided in a truly portable package format.

Currently glib is used for:

• isofs.c
  * g_hash_
  ** g_strdup, g_strsplit, g_strconcat, g_strfreev, g_free, g_return_val_if_fail
• runtime.c
  ** g_build_filename, g_strdup

Possible solutions:

• Link glib statically
  ** Pros: No source code change needed
  ** Cons: +300Kb in the runtime binary (28K -> 328K)
• Modify isofs.c to remove glib dependency
  ** Pros: likely smaller
  ** Cons: lots of work

Regarding the first solution, linking glib (and zlib) statically is managed with this patch.

Regarding the second solution, the g_hash functions could be replaced by some alternative hash implementation in C (example), and the string manipulation functions should be pretty trivial to implement with string.h

Wrong $APPIMAGE env set when running AppImage from AppImageUpdate. This confuses desktopintegration. The result is that the wrong AppImage becomes "installed" in the .desktop file.

Probably we should not exec the AppImage.

Hi I would like to request an update on Apache OpenOffice, it can be download from here.
http://www.openoffice.org/download/
The current version is almost 1 year old, please let me know if you need some information about the current version.

Modernize the landing page on http://probonopd.github.io/AppImageKit/ using a Jekyll theme that ideally

• Is responsive
• One page
• Uses Parallax effects

Contributions welcome.

Some themes

• http://jekyllthemes.org/themes/singlepaged/ - good installation documentation
• http://jekyllthemes.org/themes/will-jekyll-template/
• http://jekyllthemes.org/themes/creative-theme/
• http://jekyllthemes.org/themes/freelancer/
• http://jekyllthemes.org/themes/agency/ - missing Parallax
• http://jekyllthemes.org/themes/landing-page/ - missing Parallax
• http://jekyllthemes.org/themes/grayscale/ - powerful opening but missing Parallax
• http://jekyllthemes.org/themes/devaid/ - very basic but missing Parallax

Optically I would like to come closer to something like

• http://forbetterweb.com/htmlandbootstrap/bootstrap-theme-basic-app/
• http://demo.web3canvas.com/themeforest/startupkit/index-webapp.html
• http://bootstrapbay.com/preview/dasam-bootstrap-landing-page-B47C3FA
• http://bootstrapbay.com/preview/lithium-one-page-template-B1A1A6C
• http://elkindnet.github.io/codedesign-basic-app/ - free template
• http://www.andreagalanti.it/lab/flatfy/ - free template
• http://www.bootply.com/render/85657

https://github.com/probonopd/AppImages/releases/download/travis/Subsurface-4.5.1.278-x86_64.AppImage gives me a 404

Running the 32 bit with chmod +x gives me

./Subsurface-4.5.1.251-i386.AppImage: error while loading shared libraries: libfuse.so.2: cannot open shared object file: No such file or directory

Binary used from
http://portablelinuxapps.org/
on Fedora Mate 64bit

$ ./"AppDirAssistant 0.3.3-64bit"
Traceback (most recent call last):
File "./bin//appimager", line 16, in
import AppImageKit, AppImageKit.AppDir, AppImageKit.timesavers,

AppImageKit.xxdg.DesktopEntry, AssistantKit # Needs to be bundled
File "/tmp/.mount_ECcD3T/usr/bin/AssistantKit/init.py", line 1, in
import os, sys, gtk, vte, threading
ImportError: libpng12.so.0: file not found
[@localhost Pobrane]$ uname -a
Linux localhost.localdomain 3.17.4-301.fc21.x86_64 #1 SMP Thu Nov 27 19:09:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux