On Sun, 9 Jul 2017 16:33:54 +0200 maderios <mader...@gmail.com> said:
> On 06/08/2017 02:46 AM, Carsten Haitzler (The Rasterman) wrote:
> > 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...
> >
> >
>
> Hi
> Sorry for the long time...
> Thanks for this technical answer.
> I change the kernel 4.9 -> 4.11
> Problem is still present.
i'm not touching appimage as last time it left my machine hosed with mounts i
couldnt unmount because syscalls became hung and unkillable processes ensued...
--
------------- 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
