Description:

After the installation script reaches the "◆ RUNNING THE INSTALLATION SCRIPT FOR" step, all error messages are getting cleared out before reaching the "◆ CONFIGURING "***" " step. This makes it challenging for users to diagnose installation issues and understand what went wrong.

Problem:

The stderr messages are being cleared out, and users are unable to read error messages generated during the installation process, hindering proper diagnosis of installation problems.

Suggestion:

It is recommended to modify the installation script so that stderr messages are not cleared out before reaching the "◆ CONFIGURING "***"" step. This will enable users to identify and troubleshoot issues during the installation process more effectively.

Steps to Reproduce:

1. Execute the installation script.
2. Observe that error messages generated during the installation process are cleared out before reaching the "◆ CONFIGURING "***"" step.

Expected Behavior:

Error messages should be retained and displayed to users even after the "◆ RUNNING THE INSTALLATION SCRIPT FOR" step, allowing for proper diagnosis of any installation issues.

Environment:

• Operating System: Archlinux
• Shell: ZSH
• Version of the application: 5.3.1-5

Additional Information:

When first running appman it asks you to create a storage folder for the appimages but only gives you the option to do so within the users home directory. I would like to be able to run appman from root and have it install the appimages storage folder into /opt. Would it be possible to modify appman so that absolute paths can be utilized for the appimage storage folder and not just folders that get placed under home? Thank you.

Hi folks,
I'm planning a solution for the bigger issue of AppMan: the updates.

We have a lot of AppImages without inbuilt instructions about furter updates, and for now I've tried to solve this situation with the reinstallation of the program with appman -i <program>, but it is not sufficient enough to made the final user aware on the availability of new versions of the software.

However, by typing <program> --help on some AppImages, it is possible to see the actual version installed.

My idea is this, I want to implement a script in the app's directory to call with the appman -u command only if is in /opt/bin, after checked the version's number for of that program, and here are two cases:

1. if the output of <program> --help has the same value of the program available in its source, no action needed;
2. if the output is lower than a new version of the software in the source, do appman -i <program>.

Obviously the script must contain the link to the source of the package to do so.

There is a lot of work to do, if I'll have time I'll try to do some experiments. Any idea is welcome.

PS: I can already implement a solution for those AppImages with an external .zsync file (for example Libreoffice), but for now the main goal is to write a script for this issue first, then downloading .zsync files will be easier.

I was recently tasked with figuring out a solution for userspace application management in Linux revolving around desktop apps.

I am a big fan of the work you are doing, but I am unsure if maintaining custom appimages is sustainable as the format outside of electron packaging seems to be sliding in adoption with people favoring bubblewrap and flatpak. I actually got the inspiration for just put the whole OS in userspace from your recent app-images leveraging bwrap.

This issue is more for communication feel free to close it, my hope is we can work together on some level to expand this idea:

https://github.com/linuxserver/proot-apps

I needed stuff to run inside of Docker for a related project https://github.com/linuxserver/docker-webtop so while I want to leverage bwrap down the line I actually found that if you compile the latest version of proot on an ancient glibc, you get a portable binary runtime that has broad compatibility and almost no overhead because of the seccomp_filter accelerator as long as the underlying host is running a relatively recent kernel (4.8 and up) . PRoot still works on hosts older than this but takes a large performance hit.
I combined this with using Docker as the build env to facilitate packaging and distribution.
This means all of the packaging work that has been done with AM and ingesting arch packages could work in this userspace system without heavy modification. Right now I have focused on Debian for non MUSL stuff and Alpine to keep it lean, but an Arch baseimage is easy to create and aur install on top of to generate user consumable apps.

The format is pretty simple with most of it being copy and paste to install a single package from the distros repo and then customize it's desktop file. IE https://github.com/linuxserver/proot-apps/tree/master/apps/filezilla

If anything just looking for other people interested in this space for pointers and your stuff certainly stands out, I love the concept that your home directory is your workspace and you can distro hop on demand while bringing your apps and settings with you.

Let me know if you think there is any overlap here.

Hello @ivan-hc, will AppMan be downloadable as an AppImage? Thanks.

I just installed Debian on a laptop, this time with a XFCE and lightdm login manager. I noticed .profile did not get sourced (probably because I wasn't logging in through tty) and .local/bin was not on my $PATH at all.
I installed appman and a few appimages including gimp, appman added the 2 lines to my .bashrc but did not edit .profile because my $PATH didn't have .local/bin in the beginning as per the latest fix.
echo $PATH showed .local/bin at the end as per .bashrc, BUT gimp would not run!
After commenting out the lines in .profile gimp ran!
I think the Archimage is sourcing .profile even if the system locally is not.
Once I commented out the lines in .profile I even tested changing the order of $PATH in .bashrc to put .local/bin first and gimp still ran. That shows that the Archimage doesn't care about .bashrc only about .profile.

Can you test on your system?
Do the following:
Download gimp appimage somewhere in $HOME (such as ~/Downloads)
touch ~/.local/bin/gimp
chmod +x ~/.local/bin/gimp
Then, try to run gimp appimage that you downloaded (even without renaming)
I'm pretty sure it won't run

The fix is to edit Debian default .profile always like before.

Hi Ivan,
Have you ever try to make VirtualBox Appimage?
https://www.virtualbox.org/wiki/Linux_Downloads

I installed gimp using appman, it won't open at all! No feedback from the terminal just immediately returns to the prompt. The appimage itself works well. I tried running it from the directory appman installs to (.local/share/AppImages/gimp) using ./gimp still nothing,
I also installed google-chrome using appman, that runs just fine.
What can be the problem?

Hi there! Thanks for such great application manager!

I recently tried to install the RPCS3 emulator using the appman CLI, but unfortunately it downloads a very old version for the app - FYI version rpcs3-v0.0.18-12817-fff0c96b.

After looking in the official repository releases I noticed that the releases are not sorted by date.

Also, I found this discussion in github community: Releases out of order #8226

So, I'm opening this issue to inform this problem and also ask if is there some simple solution for it. One possible workaround could be parse the latest release link directly from the github main page - knowing that it could change in future...

Thanks in advance. Greetings!

If you do not meet the requirements and you do not have sudo access, there is no workaround to use it anyways, correct? I get the following error trying to initiate the script:

"ERROR: ar not found, required by some installation scripts.

ERROR: curl not found, required by some installation scripts.

ERROR: zsync not found, required by some installation scripts."

In README.md ubdate should be update.

Thank you very much for this!

I found this utility today and wanted to try it out.
I installed balenaEtcher and the version I got was 1.19.4 which is a pre-release.
I was expecting it to download 1.18.11 instead.

I have an old code snippet that downloads Etcher and this is what it looks like:

curl -s https://api.github.com/repos/balena-io/etcher/releases/latest | grep "browser_download_url.*AppImage" | cut -d \" -f4 | xargs wget -q --show-progress -O balenaEtcher.AppImage
chmod 755 balenaEtcher.AppImage

Emphasis on the end of the URL /releases/latest which redirects to the latest one that IS NOT a pre-release.

Don't know if I did something wrong, but I just installed simplex-chat (Thanks for adding to AM repo!)
I am on openbox now.

App was added to start menu, but pointing to simplex-chat directory where actual simplex-chat is.
Not to simplex-chat executable.

I'm so sorry I didn't test properly.

Although echo $PATH in the terminal gives correct result, unless the $PATH is set correctly in .profile gimp will still not run, at least on my system.
I edited .profile for myself, so I'm fine, I just wanted to let you know that the issue could still be present on Debian systems even after the fix. Perhaps because $PATH set in .bashrc is only recognized by bash on the host system and the Archimage still sees the user-wide $PATH set by .profile.

Once again I apologize. I should have tried to run gimp, all I did was check the $PATH...

Description

When using the appman tool on a shared network, there are instances where the IP gets rate-limited by the GitHub API, leading to installation failures with the following error: "ERROR 403: rate limit exceeded."

To address this issue and improve user experience, I propose adding an option to append a header with the GitHub Personal Access Token (PAT) for every request made to api.github.com. This will allow users to authenticate their requests and avoid rate limiting issues.

Suggested Enhancement

Introduce a new command-line option or configuration parameter that allows users to specify their GitHub PAT. This PAT will be appended as a header for every API request made by appman.

Example Implementation

# Example command with the proposed enhancement
appman --github-pat <your_github_pat> -i <package_name>

Current Workaround

I am currently using a workaround by manually modifying the API request headers in their installation script. However, having a built-in solution within appman would greatly simplify this process and improve the overall usability.

# Current workaround function in the installation script
HeaderAuthWithGITPAT='--header "Authorization: token github_pat_**************"'
function _install_GITPAT_auth_header(){
    sed -i "s#https://api.github.com#$HeaderAuthWithGITPAT https://api.github.com#g" ./$arg
}

Thank you for considering this enhancement request. Let me know if you need any further clarification or information.

I am able to open the app from pacman repo. Also, I was able to open xournal++ from appman but it's seems broken after appman update or I made mistake someway...

Error:

 xournal++                                                                                                                         ─╯
Gtk-Message: 09:49:30.745: Failed to load module "xapp-gtk3-module"
Gtk-Message: 09:49:30.747: Failed to load module "canberra-gtk-module"
Gtk-Message: 09:49:30.813: Failed to load module "canberra-gtk-module"
Gtk-Message: 09:49:30.813: Failed to load module "pk-gtk-module"
xopp-Message: 09:49:30.814: TEXTDOMAINDIR = /tmp/.mount_xournaNVsRnl/usr/share/locale:, Platform-specific locale dir = /usr/share/xournalpp/../locale, chosen directory = /tmp/.mount_xournaNVsRnl/usr/share/locale
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2721:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2721:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2721:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_dsnoop.c:567:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm_dmix.c:1000:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
xopp-Message: 09:49:30.867: Plugin "MigrateFontSizes" UI initialized
Error: in load: file "/usr/share/uim/lib/sigscheme-init.scm" not found

is there a way to change the path of install directory, instead of home it is possible to change to /opt/appimages etc

I tried setting /opt/appimages in config but it puts an opt/appimages folder in my home dir also tried the -H flag but didn't work

Hello,
while trying to install the discord appimage I was getting the following error

tail: cannot open '+2' for reading: No such file or directory

 "==>" is NOT a valid argument, please try again!


mv: cannot stat './tmp//home/jagg2/Applications/appman/.cache/install-args': No such file or directory
chmod: cannot access './/home/jagg2/Applications/appman/.cache/install-args': No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
sed: can't read .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
/home/jagg2/.local/bin/appman: line 676: .//home/jagg2/Applications/appman/.cache/install-args: No such file or directory
 ◆ "/HOME/JAGG2/APPLICATIONS/APPMAN/.CACHE/INSTALL-ARGS" INSTALLED (1 MB OF DISK SPACE)
rm: cannot remove '/home/jagg2/Applications/appman/.cache//home/jagg2/Applications/appman/.cache/install-args': No such file or directory

looking at the install logic looks like it's trying to head the first 2 lines of install-args using tail +2 $AMPATH/.cache/install-args which is causing the error.

when I changed it to tail -n +2 $AMPATH/.cache/install-args it worked without errors

looking through the script it looks like every call to tail is like this.

I would recommend change it to uses the -n flag

Thanks,
JAGG2

The script to add appman portable to the system assumes you are running it from ~. If it is run from any other directory it will create a .bashrc in the working folder instead of updating the true .bashrc.

mkdir -p ~/.local/bin && echo 'export PATH=$PATH:$(xdg-user-dir USER)/.local/bin' >> ./.bashrc

Using ~/.bashrc instead would work.