Skip to content

Releases: ivan-hc/AM

"AM" 9.0.2

07 Nov 15:57
bb681f6
Compare
Choose a tag to compare

Allow to use icon theme immediately after installation

Normally in "AM", an installation would patch the .desktop file to use a well-defined path for icons, i.e. /opt/{PROGRAM}/icons, and then to use an icon theme it was enough to run am --icons {PROGRAM}.

From now on the --icons option can be used as a flag for the -i or install and -ia or install-appimage installation options, like this:

am -i --icons {PROGRAM}

or

am -ia --icons {PROGRAM}

and works with the pre-existing --debug, --force-latest and --user flags.

Changes will only be made to apps installed when the above commands are run.

As in am --icons, icons for other installed apps will be symlinked to ~/.local/share/icons/hicolor/scalable/apps, but launchers will remain intact.

NOTE, if you use the --user flag together with --icons, only local apps will be considered. Use am --user if you also want to use icons of apps installed at system level.


PS: this is the second release in thwo hours, please don't miss the other one https://github.com/ivan-hc/AM/releases/tag/9.0.1

"AM" 9.0.1

07 Nov 13:04
4a6e97c
Compare
Choose a tag to compare

Shut up! I "AM" updating!

New options to disable/enable notifications when updating apps.


--disable-notifications

	am --disable-notifications

Description:

Disable notifications during apps update.


--enable-notifications

	am --enable-notifications

Description:

Eable notifications during apps update (nulls "--disable-notifications").


All they do is comment/uncomment lines containing notify-send in the AM-updater files of installed apps.

simplescreenrecorder-2024-11-07_13.58.26.mkv.mp4

NOTE, if you really hate notifications, run the command after every install or new apps will not be patched.

NOTE2, apps that use zsync to update will rely on version comparison or appimageupdatetool if installed and supported by the app.

"AM" 9

01 Nov 22:33
9007ec7
Compare
Choose a tag to compare

Install and manage applications both at the system level... and locally!

From now on "AM" will be able to install and manage also local applications, installed with AppMan or... directly installing them from "AM", using the new implementation of the --user option as a "flag" for the pre-existing installation options, namely:

  • -i or install, for normal installations;
  • -ia or install-appimage, to install only AppImage packages;
  • -e or extra, to install AppImage packages from github outside this database.

But let's proceed in order.


Install applications locally or at system level

In this video I will first install an app locally, and then one at system level. The root password is asked only in the second case.

install.mkv.mp4

All this whitout switching to "AppMan Mode" or using "AppMan"!


The --user flag

The "--user" option can also be used just as a flag for installation options. For example:

  • Use it to install applications locally, option "-i" or "install":

     am -i --user {PROGRAM}
    
  • Also suboptions of "-i" can work with this flag:

     am -i --user --debug {PROGRAM}
     am -i --user --force-latest {PROGRAM}
     am -i --user --debug --force-latest {PROGRAM}
    
  • Same for AppImages only, option "-ia" or "install-appimage":

     am -ia --user {PROGRAM}
     am -ia --user --debug {PROGRAM}
     am -ia --user --force-latest {PROGRAM}
     am -ia --user --debug --force-latest {PROGRAM}
    
  • External AppImages can be installed like this as well, option "-e" or "extra":

     am -e --user user/project {APPNAME}
     am -e --user user/project {APPNAME} {KEYWORD}
    

But that's not all that's changed... "AM" 9 or higher is also able to, update and manage apps locally, by default, and without having to switch to "AppMan Mode"!


List installed programs

"AM" will list all the apps it can handle both in -f...

files.mkv.mp4

...and in -l...

list.mkv.mp4

...thanks to the configuration file for "AppMan", which, if not existing, will be created the first time you start an app installation locally.

config-file.mkv.mp4

Here is a small demonstration of how the data changes, removing the file.


Refresh everything, for real!

But if you think lists are just "fluff"... here's what happens if you refresh with the -u option.

update.mkv.mp4

All locally and system-wide installed apps will be updated!

The mechanism this time involves starting the related AM-installer scripts following the entire file path, and no longer running the script in individual directories.


Removing applications

But unlike installations, which are either for local-only or system-only apps... the removal happens all at once!

Here's what happens if I use the am -R command, listing a local app first, then a system app, then a local app again.

remove.mkv.mp4

This is done by determining the permissions in the remove file, which depending on the permission level, is executed to remove the app it belongs to.


But how many options have you changed?

This release has seen a major overhaul in most of the options, here is a complete list of all the changed options:

  • -a can detect if an app is installed or not in both ways
  • -b for backups of apps that may be needed for both AM and AppMan
  • -C to create potable .config directories
  • -e to install AppImages from github out of this database
  • -f to list the installed apps
  • -H to create portable .home directories
  • -i to install apps
  • -ia to install appimages
  • -o to restore backups/snapshots created with -b
  • -r and -R to remove apps
  • -u to update all the apps, modules and "AM" itself
  • --icons to get icons from installed apps, to use themes
  • lock to lock version and updates
  • unlock to undo "lock" (see above)
  • nolibfuse to convert old AppImages to the new runtime, without libfuse2 dependence
  • --sandbox to sandbox AppImages (but still require the root permissions, for now)
  • --disable-sandbox to undo --sandbox (see above)
  • --force-latest to downgrade a github app quickly if it is a dev build or an alpha
  • --rollback to downgrade the apps from a list
  • -c to clean unneeded files and the cache
  • -l to list all apps availeble, now shows both local apps and system apps
  • -s to check for installation scripts changes among the installed apps in this database, to update modules and "AM" itself, not the apps
  • -h (of course) by adding the new info about --user
  • --user that now is suggested as a flag instead of using it as an option to swith to AppMan Mode
  • -d but just the flag --convert to convert the installation scripts for "AM" to scripts for AppMan... or generally for a local installation

all other options (the few remaining ones) have remained unchanged.


Documentation

The README of this repository has been lightened, and has a subdirectory where tutorials and troubleshooting have been divided, creating dedicated pages.

They are accessible simply by scrolling the main page of this repository!

Conclusions

It's been a very intense week. Thanks to everyone who contributed to the tests in the "dev" branch of this repository.

This release is not a reason to break "AppMan", I made sure that the users of the latter do not notice the difference, preserving their user experience.

AppMan will still be maintained, being a portable edition of "AM", even if limited to the use of local apps only... and there are system configurations for which users do not have administrative privileges. "AM" belongs only to those who install it, as always. "AppMan" is even more flexible, in this respect... but now the difference between the two is almost zero.

I hope you all enjoy this release!

Sorry again for the wait... see you next!


What's Changed

  • Update install.am: fix AppImage list (option -ia) by @ivan-hc in #1043
  • Rename ntfy to ntfydesktop by @ivan-hc in #1061
  • Update install.am: add Torsocks patch for repology.org by @ivan-hc in #1065
  • Update readme (for "AM" 9) by @ivan-hc in #1068
  • "AM" 9: handle "AppMan" programs without switching to "AppMan Mode" by @ivan-hc in #1036

New Contributors

Full Changelog: 8.4.1...9

"AM" 9-RC2

31 Oct 03:28
616cf46
Compare
Choose a tag to compare
"AM" 9-RC2 Pre-release
Pre-release

How to install apps in a rootless way

Istantanea_2024-10-31_04-25-59 png

Check it out #1036

"AM" 9-RC1

30 Oct 13:09
ad3dec3
Compare
Choose a tag to compare
"AM" 9-RC1 Pre-release
Pre-release

Get ready for a whole new experience…

Istantanea_2024-10-30_14-12-36 png

...check #1036 to learn more!

"AM" 8.4.1

27 Oct 02:05
1a08a53
Compare
Choose a tag to compare

Templates now have quick support for codeberg.org

Creating installation scripts (option -t or template) for apps published on codeberg.org is as easy and fast as for apps hosted on github.com.

In addition, the code of the module responsible for creating the scripts has been revised and improved, so as to facilitate its extensibility for other web services. NOTE that for now, only sourceforge.net has a dedicated function, and we hope to extend this ease of use also to gitlab.com and the like.

"AM" database statistics

As of today, Sunday, October 27, 2024, the database contains 2096 AppImage packages and 385 portable programs, for a total of 2481 unique applications!

Visit https://portable-linux-apps.github.io for more!

What's Changed

New Contributors

Full Changelog: 8.4...8.4.1

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

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