Releases: ivan-hc/AM
"AM" 8.3.2
Stop pretending that Ubuntu is a "canonical" GNU/Linux distro!
The recent changes that Canonical has imposed on Ubuntu, leads to the failure of some applications, and not only those supported by "AM"/"AppMan", even Flatpaks are affected! The more efficient and flexible Bubblewrap in the first place, being an essential resource for all these projects, fails because of the restrictions imposed in AppArmor in Ubuntu 23.10+.
They say that "Ubuntu Desktop firmly places security at the forefront, and adheres to the principles of security by default" (source), when in fact all they do is force the use of Snaps, "inexplicably" breaking the normal functioning of other alternative package formats!
For this release, @Samueru-sama added a warning in case your distribution adds restrictions to Linux namespaces.
Unlike the previous release, the message will not block the use of "AM"/"AppMan", but the message will always be shown to remind you that, in case you have problems running programs, and in particular for those that use Bubblewrap, the fault is Ubuntu, or rather, the way the permissions have been set.
Instructions for working around this problem are available in this section of the README https://github.com/ivan-hc/AM#ubuntu-mess
See also this interesting discussion at linuxmint/mint22-beta#82.
Personal considerations
Spoiler
Again, a release that aims to suppress the wrongs of others. Today in particular, the github actions workflows based on "ubuntu-latest" on about 50 AppImage packages managed and distributed by me have all failed because of this change (see screenshots below).
![]() |
![]() |
---|
I had to downgrade the runners to "ubuntu-22.04" in all my repositories dedicated to "Archimage" packages to bypass the problem, also because setting up containers did not work.
The "releases" section is becoming the "blog on a developer's discomfort" rather than a section where to expose short tutorials on how to deal with new versions. I'm sorry for that.
If on the one hand adding warning messages does not make this a release, on the other hand there is the danger that other people's projects on which many other projects are based, risk being demolished, both work-wise and media-wise.
What should an amateur developer do to work peacefully? I don't know.
What's Changed
- added apps by @Sush-ruta in #1000
- Add check and warning for restricted access to user namespaces by @Samueru-sama in #1001
Full Changelog: 8.3.1...8.3.2
"AM" 8.3.1
The Exorcism of AppImage (No, It's Not a New Movie)
Have you ever tried to run an AppImage from the command line and got this error message?
execv error: No such file or directory
and have you ever used "AM" or "AppMan" for the first time, installed a program in AppImage format and got error messages like this?
This doesn't look like a squashfs image.
Failed to open squashfs image
This doesn't look like a squashfs image.
Failed to open squashfs image
sed: can't read ./evince.desktop: No such file or directory
mv: cannot stat './evince.desktop': No such file or directory
the latter messages are caused by the inability to extract AppImages during the installation process, and as a consequence, neither the icons nor the launcher can be extracted from the package... while in the first case you are not able to run an AppImage at all from command line!
Strange, isn't it? And who is to blame? "AM"/"AppMan"? Poorly built packages? Or some... "demonic" entity?
That's right! A "daemon" is to blame... a system daemon!
There is a system daemon running on your system, and perhaps other files were modified when you installed it.
Did you install AppImageLauncher via DEB package (Debian, Ubuntu and derivatives...)? Or RPM (Fedora, Mandriva...)? Or via AUR (Arch Linux and derivatives)?
If so, you made a huge mistake!
If you like AppImageLauncher...
...always use it as AppImage package! No other formats!
It doesn't matter if you download it from the official repository, from appimagehub or with the command am -i appimagelauncher
/appman -i appimagelauncher
: it must be an AppImage!
The AppImage does not require root permissions, and does not modify or add files to the system that may be essential for managing AppImages, which is what the DEB/RPM/PKGBUILD versions of AppImageLauncher do!
This release solves a big issue with AppImageLauncher!
This release of "AM"/"AppMan" will perform an exorcism... er... a check of system daemons that may compromise the operation of command-line AppImages in general, whether they are managed by "AM" or by other managers.
If you have the above errors, "your installation of AppImageLauncher may have been done via DEB, RPM, or AUR, which interrupts the natural operation of "systemd-binfmt" in addition to a system daemon. To avoid problems with AM/AppMan and any other AppImages helper, it's preferable to use "only" the standalone AppImage of AppImageLauncher, whose official updated release can also be installed via "AM". But as long as you have the currently installed version, you can't use this CLI."
The daemons in question are appimagelauncherd
(present in all installable packages) and appimaged
(which is available as a separate AppImage, but which may still cause additional and unwanted launchers to be added to the menus, as well as messing up the "AM"/"AppMan" update system).
These are the two messages that will appear in the "blacklist"
You won't be able to use "AM"/"AppMan" if you haven't removed the above commands, and above all, I'll explain why. So that you can be aware of a wrong that my CLI and surely many other utilities out there have suffered because of those cursed system packages.
And if you don't believe me, take a look at the issue where all this search was started #988, listed here are just a few of the problems I have personally faced, and which some of you may have encountered in recent years.
NOTE, I appreciate AppImageLauncher, it has made a significant contribution to the management of AppImages... but as long as it leaves room for other projects to manage AppImages, like this one here, and without causing problems, there will be more contributors, like me, or better than me, to grow the ecosystem of AppImages, helping them to spread more quickly!
What's Changed
- added apps by @Sush-ruta in #964
- fix issue preventing glob expansion by @Samueru-sama in #965
- Add
keepassxc-devel
by @Samueru-sama in #966 - added apps by @Sush-ruta in #968
- remove workaround and update music-assistant-companion by @Samueru-sama in #972
- add wireguard-gui by @Samueru-sama in #974
- Remove version check in .zsync files by @ivan-hc in #976
- add puddletag appimage by @Samueru-sama in #980
- added apps by @Sush-ruta in #981
- Update management.am: fix bad arguments in "icons" by @ivan-hc in #982
- added mrwriter + changed calmly-writer script by @Sush-ruta in #987
- Change ryujinx appimage to hard-fork by @Samueru-sama in #989
- fix missing var and export PATH by @Samueru-sama in #992
- Update zen-browser to latest stable release by @Samueru-sama in #994
- Add a blacklist for files that may cause issues to "AM"/"AppMan" by @ivan-hc in #995
Full Changelog: 8.3...8.3.1
"AM" 8.3
No limits!
This release brings with it a major change, made possible by extending support for "torsocks" as an optional (not mandatory) dependency, but if present in the system, it will break the API access limits of some sites with time restrictions, allowing unlimited updates and installations!
"Torsocks allows you to use most applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects any traffic other than TCP from the application you're using."
NOTE: you can reach super-fast connections as well as slow-as-hell ones.
Below are the advantages of this implementation in "AM" and "AppMan".
Option -u
or update
In this screenshot, I reached API access limit for a website where three applications are hosted, so the update fails... so this is the message that would appear if "torsocks" is not installed.
Here's what happens when you have "torsocks" installed in these cases.
From now on, you will know for sure when updates will be possible for a certain application hosted on a specific site... and how to bypass these restrictions!
Option -i
or install
Same goes for applications to install! No more error skulls if "torsocks" is installed on the system!
Without "torsocks"...
...and with "torsocks" (note my slow connection for this 4 MB app)
Options -e
or extra
and -ia
or install-appimage
Since the options -e
or extra
(to install Appimages from github.com outside this database) and -ia
or install-appimage
(to install only AppImages-related scripts from this database) are based on -i
or install
, they will enjoy the same benefits of -i
or install
and -u
or update
, thanks to "torsocks"!
How to install "torsocks"
Search "torsocks" in your system package manager.
About "torsocks"
I attach some useful links here:
- TOR Project official site https://www.torproject.org/
- TOR Project official site (reference) https://support.torproject.org/glossary/torsocks/
- Official repository https://gitlab.torproject.org/tpo/core/torsocks/
- Repology.org https://repology.org/project/torsocks/versions
- Pkgs.org https://pkgs.org/download/torsocks
- Arch Linux Wiki https://wiki.archlinux.org/title/Tor#Torsocks
Other changes
Our database has grown with the addition of 140 new programs to install since the previous release : 2400 unique apps, and of these, 2054 are Appimage packages and 346 are standalone/portable programs! Thanks @Sush-ruta !
Visit https://portable-linux-apps.github.io for more!
Full Changelog: 8.2.1...8.3
"AM" 8.2.1
Fixed a…distraction issue
With the introduction of colors in some lists (especially in "-l
" and "-h
") many users without the "less
" command started to see "strange" messages that were nothing more than the ASCII characters intended for coloring messages.
In this minor release the "less
" command has become a "core" dependency (i.e. without which you cannot use "AM"/"AppMan"), and not only that. Now it is possible to combine the options -a
, -f
, -h
, -l
and -q
with other commands, in a clean way, without colors and without ASCII characters.
For example, suppose that mistakenly, the unaware user wants to combine the command less
with -l
(which already includes such a command), this is how the message will appear:
simplescreenrecorder-2024-09-17_00.19.40.mkv.mp4
same thing if you want to project the output of a command into a text file, for example:
simplescreenrecorder-2024-09-17_01.06.53.mkv.mp4
Among other changes
- fixed a bug related to the "
downgrade
" option, which did not update the downgraded app version at the end of the process; - fixed a bug in "
-l
" which did not correctly display the number of available AppImages in the list; - hijacked the list of available AppImages using the relative catalog page in Markdown format;
- introduced support for "appimageupdatetool" to get delta updates in AppImages (works only if "appimageupdatetool" is installed), by @Samueru-sama ;
- added dozens and dozens of new applications to the database, our database now counts 2260 unique applications (so excluding "helpers"), divided as follows: 2013 Appimages and 247 standalone/portable programs. Yes, our catalog is the first to exceed 2000 applications in AppImage format! Thanks @Sush-ruta
Finally, more categories/tags have been added to the catalog for a total of 23, with more to come (if requested).
Visit https://portable-linux-apps.github.io to learn more.
What's Changed
- Add Neovide install script by @TKK13909 in #927
- Added apps (sorry if I made any mistake) by @Sush-ruta in #932
- Initial appimageupdatetool support by @Samueru-sama in #928
- add appimageupdatetool support to some apps by @Samueru-sama in #935
- disable appimageupdatetool when downgrading, management.am by @Samueru-sama in #938
- added a few apps by @Sush-ruta in #940
- update appimagetool to AppImage/appimagetool by @Samueru-sama in #941
- added more apps by @Sush-ruta in #943
- Added CLI apps by @Sush-ruta in #945
- Create lists of AppImages from the related page of the catalogue by @ivan-hc in #947
- added apps by @Sush-ruta in #948
- Add "less" among core dependences by @ivan-hc in #949
- Allow use of "less", printing messages on files etcetera... by @ivan-hc in #950
New Contributors
- @TKK13909 made their first contribution in #927
- @Sush-ruta made their first contribution in #932
Full Changelog: 8.2...8.2.1
"AM" 8.2
System icon theme support (optional)
By default, apps installed via "AM"/"AppMan" have a "Desktop Entry" for the icons that points to the full path to the icon (without extension) in the .desktop file, in order to ensure the forced presence of icons within the application menu.
For example, here is how normally "AM"/"AppMan"'s installation scripts will made the .desktop file pointing to the icon:
![]() |
![]() |
---|---|
avidemux in "AM" | anydesk in "AppMan" |
So no way to implement an icon theme pack support... until this release!
Wait a moment! We have not implemented theming "by default" but have made it optional, thanks to the new option "icons
" or "--icons
"!
USAGE:
am icons $PROGRAM
am icons --all
or
appman icons $PROGRAM
appman icons --all
In brief
You can specify the name of one or more applications for which you want to enable customization (recommended) or apply the change to all applications by adding only the "--all
" flag (not recommended).
Technical details
The option uses "sed
" to zero out the icon path inside the .desktop file (entry "Icon="), and also creates the symbolic link (with extension) for all installed apps, in $HOME/.local/share/icons/hicolor/scalable/apps (if a file with the same name already exists, it will NOT be overwritten).
Unneeded icon's symlinks
If you remove an app or use this new command, "AM/"AppMan" will automatically detect if there are broken symbolic links in that location and remove them.
Examples
In this example, I will change the icon only to "lxtask", using the one from my personal icon theme, you will see that the .desktop file will have the icon path changed. To update, you need to open the theme manager for the icons (in my case, the XFCE one).
simplescreenrecorder-2024-09-05_05.03.34.mkv.mp4
NOTE, only "AM" needs root privileges to modify the .desktop file, as it is in /usr/local/share/applications, "AppMan" does not have these problems.
In this other example I will show how icons are added via symlink, using "AppMan" with four AppImages: Anydesk, Chromium and the two "metapackages" Kdegames and Kdeutils (containing dozens of applications). You will also notice how the icons are automatically removed if I remove the related applications. I will first apply the change to "kdegames" and then I will use the "--all
" flag.
simplescreenrecorder-2024-09-05_05.41.29.mkv.mp4
This new option works especially well with AppImages, since classic portable programs (see Firefox and Thunderbird) often have their icons in different directories than those commonly used in most scripts.
I hope this option will make customization maniacs happy.
Recommendations:
- the $HOME/.local/share/icons/hicolor/scalable/apps directory will be created automatically by starting this option, but not all Desktop Environments are able to support these specifications, check if your DE supports that path;
- the icons in the icon pack must have the same name as the applications, those provided via "AM"/"AppMan" in the "icons" directory of the application are renamed like this;
- every new app installed will have the default settings, with the .desktop file pointing to the "icons" directory of the application, this being the safest path to guarantee launchers with icons. Use the option again after installing the app.
What's Changed
- database.am refactoring by @ivan-hc in #915
- Update install.am: refactoring by @ivan-hc in #916
- Update management.am: refactoring by @ivan-hc in #917
- use while instead of for loop sandboxes.am by @Samueru-sama in #919
- Update sandboxes.am: refactoring by @ivan-hc in #920
- Fix modules source in developer mode by @ivan-hc in #923
- Add .png or .svg symlinks to icons management.am by @Samueru-sama in #925
- Fix modules usage from 3rd-party repos by @ivan-hc in #926
- "AM" 8.2: added an option to remove icon path and allow the use of custom icon themes by @ivan-hc in #924
Full Changelog: 8.1.1...8.2
"AM" 8.1.1
Minor update about BASH/ZSH completion usage
The BASH/ZSH completion file is now in ~/.local/share/bash-completion/completions
, named "am" or "appman", depending if you use "AM" or "AppMan", so they have a dedicated file and no more need the old ~/.bash_completion
.
On first use, if the old ~/.bash_completion
file exists, the line referring to AM or AppMan will be automatically removed. If you don't need that file, you can safely remove it.
New Contributors
- @marco-calautti made their first contribution in #906
Full Changelog: 8.1...8.1.1
"AM" 8.1
"AppMan" can install apps also in directories that are not the $HOME, "AM" can be packaged for distributions and a new option -ia
for AppImages is now available!
As the title suggests, this release brings with it three very important new features, let's proceed in order.
1. "AppMan" can install apps also in directories that are not the $HOME
From now on you can choose a directory other than $HOME for the installation of your applications, even an external partition, as long as you have permissions to write to it.
This new feature makes "AppMan" already a step forward compared to "AM".
Thanks to @Samueru-sama for this improvement!
2. "AM" can be packaged for distributions
For those who decide to package "AM" for the repositories of some distribution, it is necessary to take into account this function inside the APP-MANAGER script, which is the heart of "AM"/"AppMan":
# DETERMINE WHEN TO USE "AM" OR "APPMAN"
if [ "$(realpath "$0")" = "/opt/am/APP-MANAGER" ]; then
_am
mkdir -p "$MODULES_PATH" || exit 1
elif [ "$(realpath "$0")" = "/usr/bin/am" ]; then
_am
AMPATH="$AMCACHEDIR"
MODULES_PATH="/usr/lib/am/modules"
else
_appman
fi
the above function specifies that if the "am" command is in /usr/bin, the "AMPATH" variable will be set to a writable directory (in our case we used "AMCACHEDIR", the $HOME/.cache/am directory) while the "MODULES_PATH" variable will be set to the system directory "/usr/lib/am/modules" you created, thus overriding the default values of "AM".
for this to work, you need to rename the "APP-MANAGER" script to "am" and place it in /usr/bin, while the "modules" directory must be placed in /usr/lib/am. Here is how a package structure should look like, according to the definitions currently in force:
/usr/bin/am
/usr/lib/am/modules/database.am
/usr/lib/am/modules/install.am
/usr/lib/am/modules/management.am
/usr/lib/am/modules/sandboxes.am
/usr/lib/am/modules/template.am
the above scheme has already been tested on Debian Stable, a demo video is available here.
For this "special" redistribution, module updates and the CLI itself will be disabled, which will instead have to be managed by the package manager in use (APT, DNF, Emerge, YAY...).
NOTE, the above scheme may be changed, according to the distribution packagers' decisions. Suggestions for improving the implementation are welcome.
3. New option -ia
for AppImages is now available
Like the option -i
/install
, but for AppImages only! Its now available the new option "-ia
" or "install-appimage
"!
USAGE:
am -ia {PROGRAM}
am -ia --debug {PROGRAM}
am -ia --force-latest {PROGRAM}
or
appman -ia {PROGRAM}
appman -ia --debug {PROGRAM}
appman -ia --force-latest {PROGRAM}
In this example, I'll run the script brave-appimage
but running brave
, that instead is the original upstream package:
install-appimage-2024-08-29_17.49.07.mkv.mp4
in the video above I first launch a "query" with the -q
option to show you the difference between brave
and brave-appimage
, and then -q --appimages
to show you only the appimages from the list.
All the new option "-ia
" does is to check on the AppImage's list if the "argument" exists, if not, another check will be done by adding "-appimage" at the end of the argument. If no argument is found, the command -i
will not not be launched, while if the argument exists, the option -i
will take care of the installation of the script and also of the flags --debug and --force-latest, if they exist.
NOTE: by definition, the AppImages themselves "are not installed", but by installation we of the "AM" team mean adding the package, with its symbolic link, the version file, the icon directory and the script to update the application all, overall, in the dedicated paths. Generalizing, and above all for practical reasons, of language and syntax, we simplify the whole thing by calling this option "install-appimage
", or simply "-ia
", in PacMan/YAY style.
What's Changed
- allow appman to work outside
$HOME
take 2 by @Samueru-sama in #889 - improve detection of
$BINDIR
APP-MANAGER by @Samueru-sama in #890 - fix conversion of old appman config APP-MANAGER by @Samueru-sama in #891
- Fix appman mode usage in AM for unprivileged users by @ivan-hc in #892
- Update CONTRIBUTING.md by @ivan-hc in #893
- "AM" 8.1 by @ivan-hc in #894
Full Changelog: 8...8.1
"AM" 8
Let's improve for the future!
There are some major changes in this release, and they were already announced in the three pre-releases of the past few days. Here's what's changed.
BASH/ZSH completion, by default, and rootless
The bash completion file will be updated locally, in $HOME, as it already happened with "AppMan", the same will happen with "AM". But for both modes, the change will be dynamic, so you can constantly update the file responsible for the keywords to use.
"AM" users are advised to remove the old "/etc/bash_completion.d/am-completion.sh" file used previously, it is no longer needed.
Changed destination for lists and configuration files, locally!
Both "AM" and "AppMan" will share the new "AM" directory that will be created in ~/.local/share, and in which the lists will be updated, both of the applications and of the keywords to be used in the BASH/ZSH completion. And not only that, all the configuration files for betatests and third-party repositories will be saved there.
The .cache directory is being retired
From now on, versions and info about installed apps, and the processes of installing scripts from the database will be done in ~/.cache/am and ~/.cache/appman, so that any dedicated client, like BleachBit, can handle temporary files.
To remove old files and the old .cache directory previously used, run "AM" or "AppMan" with the -c
option.
Halving of modules
The modules have been reduced from 10 to 5. This results in faster update speed of "AM" and "AppMan".
Size
This release come with 1,286 additions and 2,295 deletions in the code, so "AM" and its modules are overall 3/4 of the previous version.
More readable help message
Not only has the help message (option "-h
") been simplified, but colors and more complete formulas have been added, which show in concrete terms how to use the commands.
help-2024-08-26_04.56.12.mkv.mp4
Replacement of "wget" in favor of "curl" for some functions
The functions related to downloading scripts and modules have undergone the replacement of "wget" in favor of "curl", so that you can also easily manage offline files. Why? It is soon explained in the next paragraph.
Offline/online repos, your own fork or a third-party one... to manage them is simplier!
Completely rewritten the procedure for creating and managing third-party repositories, made easier with simple commands to use. You can drag a directory with the same structure as this repository or a link to a branch (in "RAW") to a fork or a repository similar to this one, as long as the structure is similar, and you will be able to install applications, consult lists and update from there, as long as the selected repository is active. You can learn more in the dedicated section of the README, or run the "-h
" option and search for "newrepo" or "neodb". In the meantime, here is a demo video:
newrepo-2024-08-26_05.01.03.mkv.mp4
Start of distribution packager support
"AM" is always meant to be installed and used in /opt/am with a symbolic link in /usr/local/bin/am. This will not change, but it will also be supported by alternative paths that will be selectable by those who decide to implement "AM" in their distro. Other improvements in this regard will be added in the coming days, or weeks.
Conclusions
The most important aspect of this release is to bring "AM" to a much more open level, since it is designed to install applications at system level and update them without root privileges. We have done the first step now, moving the bulk of the files normally used from "$AMPATH" (the APP-MANAGER directory) to ~/.local/share/AM, shared with "AppMan". Now we only have to work on APP-MANAGER and the few remaining modules, to allow the use of "AM" to all privileged users, not just the owner of "AM".
Bringing some files known to be managed only by the owner of "AM" to a lower level is already a step forward towards the extensibility of this CLI, which from now on will have an easier path to new implementations.
Thanks for the support, and thanks to @Samueru-sama who helped me a lot!
Full Changelog: 7.8.1...8
"AM" 8beta1
- Day 1 https://github.com/ivan-hc/AM/releases/tag/8alpha1
- Day 2 https://github.com/ivan-hc/AM/releases/tag/8alpha2
Third day of improvements:
help-2024-08-25_20.27.17.mkv.mp4
- Option "newrepo" or "neodb" is now totally rewrited. New support for third-party repositories, managed directly from the main CLI, its enough to use the suboption add followed by the path to an offline directory or a "RAW" URL that will be added to a list, needed to select one of the repos that will replace the main one. To enable/disable it use on/off
newrepo-2024-08-25_20.32.43.mkv.mp4
to allow this behaviour, some modules and commands have been converted to curl
usage.
To test the new features, run the command
am --devmode-enable
or
appman --devmode-enable
the release its quite ready, now its time to finalize some little details before it become Stable.
Please open a discussion or a issue if you have a suggestion to improve this release. Thank you for your attention.
Full Changelog: 7.8.1...8beta1
"AM" 8alpha2
Day one, see https://github.com/ivan-hc/AM/releases/tag/8alpha1
In the day 2 of this work, we have reduced the number of modules from 10 to 7:
- database.am contains '-f, '-a', '-l' and '-q'
- management.am contains '-b', '--rollback', '--launcher', 'lock', 'unlock', 'nolibfuse', '-o' and 'remove'/'-R'/'-r'
- install.am contains '-i', '-e' and '-d'
- option 'apikey' has been moved to APP-MANAGER
- other modules have been almost untouched
Start reworking on single options, now "AM" has a better detection of its status, to be used as "AM" or "AppMan", and we are preparing made it installable/usable from /usr/bin, for furter implementations in distro packages.
Removed references about third-party repos and neodb from all options using them, since we are starting on a total rework of the support for third-party repositories, by merging options "neodb" and "newrepo", for now still in the "devtools.am" module.
This pre-release come with 986 additions and 1,601 deletions.
We are planning to move the modules to a different directory from /opt/am/modules, please open a discussion or issue if you have any ideas.
For now, it is certain that the lists and configuration files will be moved from /opt/am to ~/.local/share/AM, for a shared use of the lists between AM and AppMan, while the "cache" files (installation scripts running, information files about installed apps and their versions) will be moved to ~/.cache/am and ~/.cache/appman
If you are curious to test the future AM 8, run
am --devmode-enable
am -s
or
appman --devmode-enable
appman -s
and help us with your feedback, it will be much appreciated.
Full Changelog: 8alpha1...8alpha2