"AM" 7.1.1

Continuation of version 7.1 and other little improvements

Installation scripts that can build AppImage packages on the fly will each have their own dependencies to declare. If you come across one of these scripts, the installation module "install.am" will check whether the second script (the one dedicated to building the app) requires specific dependencies, and if it is not installed, the installation will be aborted.

For example:

• you want to install the APP1, that requires "tar"
• also you want install the APP2, that requires "gcc"
• you have "tar" installed, but "gcc" is not installed
• only APP1 will be installed

Currently the list of possible optional dependencies for that kind of script includes:

ar, convert, gcc, glib-compile-schemas, make, tar and unzip

NOTE, THEY ARE NOT "AM" DEPENDENCES, don't worry 😉

This enhances new functionality available with version 7.1.

If you need to create installation scripts to build AppImages on the fly, let me know what are dependences they may need.

Please, reference to https://github.com/ivan-hc/AM/tree/main/appimage-bulder-scripts for the correct path of these scripts.

Also see the video examples from the previous release, now also available on the README.

---

Among other changes:

• the "-f" option now shows the number of installed libraries (which for now is only one available in the database, obviously "libfuse2")
• always the "-f" option will show if there are multiple apps and libraries installed (plural) or there is only one (singular)
  

Full Changelog: 7.1...7.1.1

Also, new homepage is now available for https://portable-linux-apps.github.io

"AM" 7.1

The beauty of DIY: building AppImages on the fly, like an AUR package!

Creating installation scripts for AppImages on the fly (option "-t" or "template", preference 1) is even easier now.

The two functions, assembly and installation, have been divided into two separate scripts:

1. the installation script, which is the same as the AppImages (option "-t", preference "zero") will only have to intercept the package version (necessary for updates) and install the ready-made AppImage;
2. the "assembly" script (with ".sh" extension) will be downloaded by the installation script into the temporary "tmp" directory created at the start of the installation process, so as to be executed and independently build the AppImage, before delivering it to the installation script.

To show you what I mean:

In this video we see how "calibre" is installed (note that a "calibre.sh" file is downloaded during the process):

calibre-installation-2024-07-10_01.46.59.mkv.mp4

In this video, I run the aforementioned "calibre.sh" script in a separate directory, in a completely standalone way:

calibre-standalone-2024-07-10_01.45.04.mkv.mp4

This method replaces the previous one which included both functions in a single body (and which led to the creation of scripts that were too long and complicated to manage).

NOTE, assembling AppImages on the fly can be a time-consuming and resource-intensive operation, depending on the size of the program you want to build.

I suggest contacting upstream developers to convince them to release official AppImage packages, or at least, create them on your own repositories using Github Actions, as I have done over the years.

On the other hand, the advantage of this method is that the update is continuous, using upstream packages and without being limited by the packager, be it official or third party.

You can upload other build scripts at https://github.com/ivan-hc/AM/tree/main/appimage-bulder-scripts

---

If you are a user of my AppImage creation tools

• consider using AppImaGen, it is a simpler and more natural approach for this type of packages.
• try NOT to use Archimage, as build times are longer and more resource intensive.
• try NOT to use Snap2AppImage, it may be resource-intensive too, as Snap packages tend to be very large.

From the next release there should be suitable patches for other tools that use gcc, make and other software assembly systems.

---

Full Changelog: 7...7.1

"AM" 7

Cleaning and conversion of all installation scripts

In this last week we have tested and converted all the installation scripts, using the new @Samueru-sama templates, and as I had already anticipated in the previous version, the path and name of the .desktop files have changed, like this and for all installation scripts, from today, 8 July, 2024:

/usr/local/share/applications/$PROGRAM-AM.desktop

AppMan users will only notice that on new installations the launcher change from "AM-$PROGRAM.desktop" to "$PROGRAM-AM.desktop".

But this is not the only news:

All installation scripts have been selected, tested, corrected and improved exponentially!

As of now 99% of all installable applications are upgradeable. Apps with a linear download URL will rely on repology.org to determine the latest version (newer, or unique), however intercepted URLs will primarily rely on the primary source, if available.

All installation scripts now use a single template, one for AppImages and one for other apps.

As a result of the update of the installation scripts, the "install.am" module has also been adapted, removing a large number of patches and updating those on checking individual apps that require a specific dependency (tar, zip, deb or zsync).

The "template.am" module has also been improved, allowing users to choose whether to use repology.org as the basis for version comparison, to make all new installation scripts updatable.

Furthermore, 78 of the AppImages that were already present in the name were renamed by removing "-appimage" from the name and aligning them with the other applications.

Clean up

The obsolete templates have all been removed, you can view the ones currently in use here.

Unfortunately, many apps have been removed, mainly because many upstream developers have decided to remove support for portable apps (AppImage included) in favor of other platforms, either by hiding their apps behind a paywall, or basically because a project is dead.

Other apps were removed because they were no longer updated but a constantly updated counterpart was already available.

For all excluded apps you will be able to use them using the "--launcher" option, as always (see here). From now on the uploading requirements will be more stringent in this sense, so as not to flood the database with various duplicates.

Future

Future releases will see more use of my other project, AppImaGen, to convert the majority of software packages from deb to AppImage, in order to enjoy the benefits of "AM" and the Aisap sandbox (see here).

Conclusion

Having found so many packages to remove, reading their history and motivation, I remembered the mission I have as the creator of this project:

"AM" was created to enhance the AppImage packages, which are anything but second-class packages to be dragged around.

If among the disadvantages that led to its constant abandonment were the poor visibility, the unavailability and the lack of automatic updates, this project does everything to erase these prejudices, and tries in every way to bring attention of other developers to adopt this packaging format.

Let's make AppImage popular again, we will recover all lost apps!

Full Changelog: 6.16...7

"AM" 6.16

Rewriting installation scripts, with one less dependency

• Removed "jq" dependency, from installation scripts, modules and the main CLI
• Use of new installation scripts for AppImage packages and other standalone apps
• The new scripts will install application launchers no longer with the "AM-" suffix, but with the "-AM.desktop" extension, so you can list the launchers the way you want
• New installation scripts for "AM" will install launchers in /usr/local/share/applications by default rather than as an alternative to /usr/share/applications

NOTE: converting all installation scripts to the new template is still in progress.

Older installation scripts are still using the "AM-" suffix in .desktop files and .desktop files will still use /usr/local/share as an alternative to /usr/share. Keep an eye out for changes in the section https://github.com/ivan-hc/AM/commits/main

---

Among other changes:

• the "template.am" module has dedicated functions to manage applications from "sourceforge.net"
• introduced new conditions for creating installation scripts based on "github.com"
• improved interaction with the "-t" option
• added support for "torsocks" in the "template.am" module
• introduced new variable "$BINDIR" in modules, by @Samueru-sama
• improved version control and application types in "files.am", by @Samueru-sama
• new installation script templates, by @Samueru-sama
• various improvements and bug fixes

Full Changelog: 6.15.1...6.16

"AM" 6.15.1

Improved the "-f" or "files" option for listing installed programs

• Display the type of script (launcher/bash/dash/posix/awk/simple script) and executable binaries (static/dynamic) and improved the functions to identify the type of program, almost completely eliminating the number of apps identified as " other";
• Improved and simplified syntax in the "files.am" module.

by @Samueru-sama

Other changes

• update AppImage typology in "-f" after sanboxing ("--sandbox" option), by @Samueru-sama;
• fixed crash that occurred when there is more than one dbus in /tmp for all future sandboxed AppImages ("--sandbox" option), by @Samueru-sama;
• fixed a bug that added the security patch several times to the "/opt/am/remove" file of "AM";
• the "/opt/am/remove" script for new "AM" installations will be POSIX compatible, by @Samueru-sama;
• while I'm writing this, whe have 2108 installation scripts for the x86_64 architecture and another dozen to add is pending into an (for now still) open issue.

Full Changelog: 6.15...6.15.1

"AM" 6.15

Various improvements and bugfixes

Now option "-f" or "files" shows if Appimages are sandboxed or not

The AppImages for which the sandbox has been enabled will appear in the list with a symbol "🔒" next to the type. By @Samueru-sama

In case ~/.local/bin is not in $PATH, "AppMan" asks you if you wish to add it or not

Previously, AppMan applied the patch directly, giving ~/.local/bin the right priority. Now it is no longer necessary. The user will be able to choose if it is not available. By @Samueru-sama

The installation script for LibreOffice has been improved with 12 references to choose

Also added "basic", for English/American users only.

Also, allow "LibreOffice" to be updated with both "zsync" and "versions comparison" methods. This is important for users that have converted their AppImage to a Type3 one (option "nolibfuse").

Other changes

• Implemented an option "--disable-sandbox" also in "AM"/"AppMan", by @Samueru-sama
• Fixed an issue with "-i" or "install", where failed installations where keeping move on
• Fixed "update + conversion" for AppImages converted from Type2 to Type3 with the option "nolibfuse" , by @Samueru-sama
• Improved new templates for archives and AppImages, by @Samueru-sama
• the installation scripts now available for the x86_64 architecture are 2092, equal to approximately 2000 AppImage packages.

I hope I have not forgot anything.

What's Changed

Full Changelog: 6.14...6.15

"AM" 6.14

Greater freedom in sandbox permission choices

@Samueru-sama's tireless work makes this command line look more and more like a "Flatseal" for AppImages:

• Added more XDG directories to select;
• Free choice of directories to authorize;
• Improved Bubblewrap support via "Aisap" for non-systemd distributions.

simplescreenrecorder-2024-06-21_17.25.05.mkv.mp4

Don't let the few commits fool you!

Making the most of the existence of AppImages as a software package format, extracting all the hidden characteristics from them, highlighting their potential... is the purpose for which this project was born!

Far too many developers have abandoned AppImage in favor of more "convenient" solutions to maintain, and far too many people have demonized AppImage packages, highlighting only taboos and defects that we, with this project, are trying to erase!

Sandboxing is one of them, and every improvement we make by supporting the AppImage format is a punch in the face of skeptics!

Full Changelog: 6.13...6.14

"AM" 6.13

Major improvements aimed at speeding up the addition of new apps

At this moment the database contains 2059 installation scripts for the x86_64 architecture, which is equivalent to approximately 2050 programs, of which at least 1900 are AppImage packages!

And with this release, the number is destined to increase more and more, guaranteeing our users the transparency and availability of sources, through the options -a (get information about the apps), -d (download the installation script) and out site portable-linux-apps.github.io.

This release will make it much easier for us all to upload installation scripts for archived programs and standalone binaries (option "-t" or "template", select "2").

Option "-t", template for the selection 2 (archives, scripts and various programs)

The new script already incorporates support for 7z, tar and zip archives, and can also be used to install AppImage packages that do not require launchers. In fact, adding a launcher for this template is optional. The icon must be downloaded via a URL, which if not available, will be replaced by the icons available on portable-linux-apps.github.io.

In the example, we create a script for OBS Studio AppImage, complete with a custom launcher, and without an icon:

simplescreenrecorder-2024-06-21_06.19.31.mkv.mp4

Thanks to @Samueru-sama for all the help!

Option "-t", templates for the selection 1 (build Appimages on-the-fly)

Also fixed issues in the two templates available for the selection 1, those needed to build AppImages on-the-fy!

In this example, we build Abiword AppImage from Debian:

simplescreenrecorder-2024-06-20_17.16.53_edit.mkv.mp4

NOTE, to work with pkg2appimage and appimagetool is needed Imagemagick installed on your system. These two are Type3 AppImages, so you don't need "libfuse2" to use them.

Code refactoring

Additionally, the "template.am" module, the templates in use and 60+ new installation scripts have been refactored.

Full Changelog: 6.12.1...6.13

"AM" 6.12.1

AppImage sandboxing improvement!

You decide which directories to whitelist, in your language!

This release is the continuation of version 6.12, with varius improvements to the option "--sandbox".

As already mentioned in the previous version, "Aisap" is a frontend for Bubblewrap which is aimed at sandboxing AppImages. Visit github.com/mgord9518/aisap for more information.

"AM"/"AppMan" implements "Aisap" to create and manage sandboxes... and this release is a huge step forward in this regard!

Now AppImages can not only run in the sandbox, but they now have a more consistent appearance with the system, and the sandbox is no longer a limitation:

• integration of configuration files for system themes and user's defaults;
• greater mastery of the sandbox;
• interaction with the command line interface to authorize access to the XDG directories that you choose.

Brief syntax summary

To enable the sandbox:

am --sandbox $APP

or

appman --sandbox $APP

To disable the sandbox:

$APP --disable-sandbox

In the video we will use "Baobab" (GTK3 version), a disk space analyzer, available in the database as "baobab-gtk3", and giving it read/write permissions only in "Video" (the Italian for "Videos").

simplescreenrecorder-2024-06-20_01.59.00.mkv.mp4

While it's not quite the same as interacting with Flatseal for Flatpak, our project, completely based on SHELL, aims to make the user experience as friendly as possible.

Thanks @Samueru-sama for the hard work!

---

Among other things:

• fixed a bug in "template.am"
• 2050+ installation scripts for the x86_64 architecture are now available.

---

Find out everything you need to know about "AM" and "AppMan"!

Outside of the CLI itself, a lot of work in this repository has been done on rewriting the README, now all guides are updated and simplified, improving navigation between the various guides available, and almost all sections have a demonstration videos for each topic.

The new README aims to be as exhaustive as possible for both "AM" and "AppMan", also including the related installation guides.

For any improvements to be made, contact me via issue or open a pull request.

---

Full Changelog: 6.12...6.12.1

"AM" 6.12

Better sandboxing method for your AppImages!

Dropping Firejail for "Aisap", Bubblewrap frontend

Since version 5.3 you can use the --sandbox option to run AppImages using a sandbox, but from now Firejails has been dropped in favour of "Aisap", a Bubblewrap frontend for AppImages. The now obsolete --firejail option has been removed as well.

This method works as follows:

am --sandbox $APP

or

appman --sandbox $APP

• if the "aisap" package is not installed, you will be asked if you want to install it via "AM"/AppMan;
• requires replacing the symlink in $PATH with a script;
• to work, the Appimage will be set to "not executable", and the AM-updater will also have its chmod command set to a-x instead of a+x.

The default location for the sandboxed homes is at $HOME/.local/am-sandboxes, but that location can be changed by setting the $SANDBOXDIR env variable.

To restore the use of the AppImage without sandbox, you need to run the application command with the "--disable-sandbox" option:

$APP --disable-sandbox

Scenario, you've installed "Anydesk" and you want it to be sandboxed as first, but "Aisap" is not installed, so the new --sandbox option prompts if you want to install it before. In this video I anso enable/disable the sandbox for both Anydesk and Lxtask:

simplescreenrecorder-2024-06-15_20.15.46.mkv.mp4

NOTE, "AM" users will need to use the root password to replace the symlink in $PATH with the script, while AppMan users will need to close the terminal for the changes to take effect.

For more information aboit "Aisap", visit https://github.com/mgord9518/aisap

DISCLAIM: at the time of writing, "Aisap" is still experimental and the supported profiles are still few compared to the number of applications in this database. For example, in the video above, Lxtask was running in sandbox, Anydesk was not. So not all apps will run in sandbox. A Flatseal-style tool for Flatpak would be needed, but it is not available at the moment. Please support the "Aisap" project as much as you can.

Below are useful links to the official "Aisap" documentation:

• Available profiles are listed at https://github.com/mgord9518/aisap/tree/main/profiles
• To learn more about permissions, see https://github.com/mgord9518/aisap/tree/main/permissions

EXTRA: The behavior of this option can be tested in a completely standalone way by consulting the repository of its creator, at Samueru-sama/aisap-am

Thanks to:

• https://github.com/Samueru-sama/aisap-am by @Samueru-sama for the new --sandbox option
• https://github.com/mgord9518/aisap by @mgord9518 for "Aisap"

---

Other changes:

• Fix an inconsistency in "install.am" during patching the installation scripts for AppMan e6f1e27
• Fix a bug with suboption --debug and --force-latest in "install.am" ae3266d
• There are now 2034 installation scripts for the x86_64 architecture available in the database

Full Changelog*: 6.11...6.12