On Thu, 8 Jun 2017 08:02:42 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> said:
> On Wed, 7 Jun 2017 17:59:40 +0200 maderios <mader...@gmail.com> said:
>
> > Hi
> > I can't launch avidemux or digikam appimage from icons i created.
> > I can launch these appimages inside terminal from the commandline
> > I can launch successfully any other applications from icons i created
> > I tested inside xfce4, i meet no problem with appimages.
> > My question: is it a known bug?
> > Thanks
>
> what is an "appimage" ? have you checked your ~/.xsession-errors or wherever
> your login session stdout/error is being logged?
ok found it. never heard of appimage. kind of cool. but it seems broken.
Cannot open /tmp/.mount_7IZlPL/.DirIcon
that's what comes up in my .xsession-error log... it does very temporarily
create that /tmp/.mount_7IZlPL dir... that works. but beyond that i don't
know. it breaks after that. i can't quickly find out why... because stracing
makes mount fail (security since strace -f is needed and mount is setuid). i
tried using sudo/root do it and it screwed my filesystem (it hung - i kill -9'd
it and i was left with this dir:
0 drwxrwxrwt 2 root root 40 Jun 7 09:12 .font-unix/
? d????????? ? ? ? ? ? .mount_KdFykk/
that 2nd one there... the strace of the appimage is unkillable hung in a kernel
call... this sounds a bit fragile... but i have no details. yes it works for me
from a terminal. it doesn't work when e launches it. why? i don't know. all e
does is fork() and exec() (using ecore_exe_run() - you can check the code). the
app will inherit the stdin/out of e. it will inherit the environment variables
etc. (well ok ecore_exe also does setsid() to create a new process group - but
its pretty normal stuff).
appimage has issues though - legally. it seems to happily snarf in binaries to
make your app run (into a squashfs filesystem that is mounted that is simply
appended after the appimage launcher binary at the start of the appimage) ...
if this contains binaries of any gpl, lgpl or similar software then you have to
ensure you provide the exact source used for building those too to comply with
licenses (or make it available on request etc.). it seems appimage totally
sidesteps this legal issue... while it's a technically working solution... at
least in some scenarios... it seems to have issues.
in fact the appimage runtime relies on inotifytools... it links to it (and
inotifytools has a library that's lgpl). thus just distributing an appimage
with the runtime at the front that's needed to launch your app requires you
comply with lgpl for inotifytools.... that is linked in. at least at a quick
glance.... i know this doesn't have to do with the technical problem... but
this project has legal problems... at least for anyone using it to distribute
their apps.
having a read of the src tho - it makes the tmp dir above, mounts the squashfs
image using fuse (if it fails you should get a notification - uses
libnotify). ... it seems to get that far... i can only imagine the mount has
something wrong (permissions, empty, ... something). the hard bit is catching
it... i know the dir exists as stracing the runtime launcher works and i can
see it successfully mkdir etc. ...
but i've been testing the subsurfacwe appimage... this is not current with the
current appimage src. it doesnt support the appimage args... if i try the
appimagetool appimage... it can't open the mount dir...
in fact... using the newer appimkages i see lots of junk mount dirs like above:
? d????????? ? ? ? ? ? .mount_9ogv72/
? d????????? ? ? ? ? ? .mount_FTsltu/
? d????????? ? ? ? ? ? .mount_KdFykk/
? d????????? ? ? ? ? ? .mount_SzPX5k/
? d????????? ? ? ? ? ? .mount_TgorDd/
? d????????? ? ? ? ? ? .mount_keqfkw/
every time i run the appimage (the appimagetool) i get a new junk garbage
directory... in fact it's almost like we have hit a kernel problem:
ls (the directory listing) reports the file as there - a directory... but stat
says ".mount_keqfkw".
hooray! we've found another kernel bug. at least that's what my stream of
thought is going to... the fact we can, from userspace, modify a directory
entry (add an entry to the directory pointing to an inode) BUT then not have
the inode exist... btw the mkdir works:
mkdir("/tmp/.mount_keqfkw", 0700) = 0
so 0 return code == success. the dir entry is there... fuse does something
really bad to this dir/inode... and it has to be at the kernel level to do
this as it's inside the vfs etc. layers inside the kernel. but fusefs_main at
least seems to indicate it works as no notification appears...
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
