where is the linux AppImage executable??

[Tcll]

on the download page, there's an ubuntu deb package download, but there's no executable appimage download.

do you guys plan on building one or do you just want to leave it up to the noobs to compile themselves??

[Jmgr]

Well, there is only one guy: myself ;) I have no immediate plans to do so because of a lack of time, but user contributions are always welcome.

[Tcll]

ah oof, I can't contribute myself due to too full a plate of my own projects... plus I have no idea how to set up a squash-fs virtual environment to distribute a proper portable appimage (I also don't need to worry about this, as I don't work with OS-dependent binaries, so I can just build basic appimages)

but I hope you can find time to automate the build process to make things easy on yourself :) hope my insight info helped at least ;D

[Tcll]

just wanted to update on this since you marked this as completed, but I can't seem to find the appimage...

I've been building appimages for a while now and it's extremely easy to do in any file manager, and potentially automate

I've also replaced the AppImageKit AppRun binary I used to use with a basic shell script you can modify to your liking:

#!/bin/sh
SELF=$(readlink -f "$0")
HERE=${SELF%/*}
export PATH="${HERE}:${HERE}/usr/bin/:${HERE}/usr/sbin/:${HERE}/usr/games/:${HERE}/bin/:${HERE}/sbin/${PATH:+:$PATH}"
export LD_LIBRARY_PATH="${HERE}/usr/lib/:${HERE}/usr/lib/i386-linux-gnu/:${HERE}/usr/lib/x86_64-linux-gnu/:${HERE}/usr/lib32/:${HERE}/usr/lib64/:${HERE}/lib/:${HERE}/lib/i386-linux-gnu/:${HERE}/lib/x86_64-linux-gnu/:${HERE}/lib32/:${HERE}/lib64/${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
export PYTHONPATH="${HERE}/usr/share/pyshared/${PYTHONPATH:+:$PYTHONPATH}"
#export MOZ_LEGACY_PROFILES=1 # Prevent per installation profiles
DEFAULT_XDG_DATA_DIRS='./share/:/usr/share/gnome:/usr/local/share/:/usr/share/'
export XDG_DATA_DIRS="${HERE}/usr/share/:${XDG_DATA_DIRS:-$DEFAULT_XDG_DATA_DIRS}"
export PERLLIB="${HERE}/usr/share/perl5/:${HERE}/usr/lib/perl5/${PERLLIB:+:$PERLLIB}"
export GSETTINGS_SCHEMA_DIR="${HERE}/usr/share/glib-2.0/schemas/${GSETTINGS_SCHEMA_DIR:+:$GSETTINGS_SCHEMA_DIR}"
export QT_PLUGIN_PATH="${HERE}/usr/lib/qt4/plugins/:${HERE}/usr/lib/i386-linux-gnu/qt4/plugins/:${HERE}/usr/lib/x86_64-linux-gnu/qt4/plugins/:${HERE}/usr/lib32/qt4/plugins/:${HERE}/usr/lib64/qt4/plugins/:${HERE}/usr/lib/qt5/plugins/:${HERE}/usr/lib/i386-linux-gnu/qt5/plugins/:${HERE}/usr/lib/x86_64-linux-gnu/qt5/plugins/:${HERE}/usr/lib32/qt5/plugins/:${HERE}/usr/lib64/qt5/plugins/${QT_PLUGIN_PATH:+:$QT_PLUGIN_PATH}"
EXEC=<insert program here>
cd "${HERE}/usr"
exec "${EXEC}" "$@"

or if you want to load from a .desktop file:

EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2 | cut -d " " -f 1)

hopefully I'll see an official appimage spawn out of this :)

I may have been building appimages for years, but an official source binary is more reliable than 3rd-party sources like me, because you ultimately know how your program works and what specifically is the required minimum for it to run. :)

if I were to build it, I'd just be picking and choosing what deps it may run with since I don't ultimately know that myself... (that and those deps may only work on my system at worst since I'd be building the AppImage with Artix binaries)

[Jmgr]

You are right, I'll set this as enhancement. My worry with this is not really building the app but rather the permissions that will be needed for the actions, as well as being able to simulate mouse and keyboard actions. I'm unsure if running an app via AppImage would then require Actiona to ask for additional permissions.

[Tcll]

hmm, that sounds like it's more something to do with polkit or whatever if not through libinput or some other input mechanism if some higher-level permission is required...

for a general use case though, it should be fine in theory

I know I'm going though similar conundrums involving input handling through the Xorg display socket vs my own async input daemon...

I personally don't use polkit, udev, or dbus, but I know those can leverage input permissions as well and I'm not sure if audit is the core control behind all of that on top...

but yeah if it needs any of that, well... currently I do a thing for Nheko where I've integrated dbus into it's appimage and run a portable session for that to run without issue.

in any case I'd be happy to test given my system basically doesn't have anything in /usr, so if it works for me, it should theoretically work for anyone else :)

[Tcll]

oh right, I forgot to mention I'm running an old 5.19 kernel on top

while that doesn't offer the greatest range of cross-distro support, it at least offers something for a modern range of distros :)

[Jmgr]

Well Actiona doesn't need root, it uses XTest (which means it won't work on Wayland until someone adds an automation portal). So if AppImage doesn't interfere with XTest usage then it should be fine.

[Tcll]

ok yeah xtest should work normally

also yeah I'm not personally a fan of wayland atm because of it's lacking nvidia support... heh not to mention other issues I've heard it has

meanwhile on xorg, the only real issues it has have to do with /usr/lib/*.so rather than Xorg itself and the display socket issues can be mitigated by sending the protocol correctly

but currently I'm still learning how to actually set that up :P all I have right now is just a basic socket connection to Xorg in python of all languages... lol

display = environ.get('DISPLAY',':0') # TODO: this is broken, is there a more direct method that doesn't involve procfs?

(proto,host),(dno,screen) = tuple( (s.split(c)+[''])[:2] for c,s in zip('/.',display.split(':')) )

# WARNING: this location is dynamic and can be located anywhere on the filesystem
addr = '/tmp/.X11-unix/X%s' % dno # TODO: list all AF_UNIX sockets (without procfs) and find those that belong to Xorg

# this block is temporary until I can figure out how to unbreak Linux

# why do we need this bloat over posix.open( addr )?
from socket import socket, AF_UNIX, SOCK_STREAM # bad
sock = socket(AF_UNIX, SOCK_STREAM) # bad
sock.connect(addr)
if hasattr(sock, 'set_inheritable'):
    sock.set_inheritable(False)
else:
    import fcntl
    fcntl.fcntl(sock.fileno(), fcntl.F_SETFD, fcntl.FD_CLOEXEC) # why don't we just write to the file we have?

# end temporary broken Linux block

^ yes I'm absolutely blaming Linux for not implementing open() on AF_UNIX inodes (it's a file, handle it like the file it is)

but anyways, Linux issues aside, I can absolutely use xtest through that just like using it through /usr/lib/libXtst.so which ultimately sends the same struct :)

I'd also argue doing things this way offers more stability (including kernel syscalls), since binary deps like to break (this is the reason I have nothing in /usr, updating your system is no different from playing Minesweeper... lol)

[utilisateuralpha]

Finally, will there be an appImage version of the application?

[Jmgr]

Maybe one day, but not by me. I already don't have enough time to work on the software itself unfortunately... Any contribution would be greatly appreciated @utilisateuralpha