Skip to content

Releases: ivan-hc/AM

"AM" 8.4

16 Oct 16:28
0a32219
Compare
Choose a tag to compare

Custom snapshots

Improved the -b or backup option, now you can customize the snapshot name:

  • by default, just press ENTER to use the classic mix date+time of the snapshot creation;
  • if you press "1", the snapshot version will be used as the name;
  • finally, you can simply write the name to give to the snapshot (spaces will be replaced with a "_").

Also, a check has been added to verify if a directory with the same name already exists.

In the screenshot below are listed a series of tests, in the first attempt I chose to use the version as the name, but it gave me error because the directory already existed, in the second instead I left it empty, thus creating a snapshot based on the date and time (default), finally I gave a custom name using a phrase with a space:

Istantanea_2024-10-16_15-40-29 png

Note that a final message will also indicate the name of the just created snapshot.

In the use that we will make of it, through the option -o or overwrite, we will have a result like this:

Istantanea_2024-10-16_15-44-55 png

Now snapshots are more user friendly!

Tips and Tricks

You can use the -b option for snapshots, and where applicable, you can use the downgrade or --rollback option to install older versions of a program. This way, whenever you want to use a different version of the same program, you can use -o, using the snapshot you prefer.

For example, suppose you want to alternate "Kdenlive 24.08.1" (at the time of writing, it is the latest release available) with "Kdenlive 23.08" which still supports QT5, here's how to do it:

  1. do a backup with am -b kdenlive, press y and press 1, this will create the snapshot "24.08.1";
  2. run the command am downgrade kdenlive and select the version 23.08 from the list;
  3. run a backup again with am -b kdenlive, press y and press 1 to create the snapshot "23.08";
  4. from now on, to switch between them, just use am -o kdenlive and select between "24.08.1" and "23.08", from the list.

You can create as many snapshots as you want and switch them this way according to your needs!

What's Changed

  • Option "-b" or "backup", give the name you want to the snapshots by @ivan-hc in #1006

Full Changelog: 8.3.2...8.4

"AM" 8.3.2

14 Oct 02:38
e1a1706
Compare
Choose a tag to compare

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.

Istantanea_2024-10-14_03-52-21

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:/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).

Istantanea_2024-10-13_18-51-24 png Istantanea_2024-10-13_18-58-23 png

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

Full Changelog: 8.3.1...8.3.2

"AM" 8.3.1

11 Oct 03:44
1d21623
Compare
Choose a tag to compare

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"
Istantanea_2024-10-11_04-27-56 png

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

Full Changelog: 8.3...8.3.1

"AM" 8.3

27 Sep 13:24
ccff40a
Compare
Choose a tag to compare

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.

Istantanea_2024-09-27_14-51-40 png

Here's what happens when you have "torsocks" installed in these cases.

Istantanea_2024-09-27_14-53-19 png

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"...

Istantanea_2024-09-27_02-47-14 png

...and with "torsocks" (note my slow connection for this 4 MB app)

Istantanea_2024-09-27_02-47-54 png

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:


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

16 Sep 22:45
783af21
Compare
Choose a tag to compare

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

New Contributors

Full Changelog: 8.2...8.2.1

"AM" 8.2

05 Sep 04:22
146d43c
Compare
Choose a tag to compare

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:

Istantanea_2024-09-05_06-06-31 png Istantanea_2024-09-05_06-05-04 png
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

Full Changelog: 8.1.1...8.2

"AM" 8.1.1

31 Aug 23:50
df4fdd1
Compare
Choose a tag to compare

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.

  • Move completions file to ~/.local/share/bash-completion/completions by @ivan-hc in #905

New Contributors

Full Changelog: 8.1...8.1.1

"AM" 8.1

29 Aug 16:54
8badc23
Compare
Choose a tag to compare

"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.

Istantanea_2024-08-29_18-16-18 png

Istantanea_2024-08-29_18-15-52 png

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

Full Changelog: 8...8.1

"AM" 8

26 Aug 04:17
c91bfac
Compare
Choose a tag to compare

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.

Istantanea_2024-08-26_04-47-01 png

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

25 Aug 18:50
49d43b6
Compare
Choose a tag to compare
"AM" 8beta1 Pre-release
Pre-release

Third day of improvements:

  • modules are now only 5
    Istantanea_2024-08-25_20-25-03

  • Option "help" or "-h" improved, with colors and shorter messages

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