AppImage is disappeared

[ivan-hc]

Hi, I helped you with @Samueru-sama here #164

I noticed that your AppImage is no more available, all latest checks in my workflows trough my package manager AM have failed for this

It's not a problem for me; I can temporarily disable your app for further testing in the meantime this issue is not solved.

I just wanted to ask if you need help? Or have you decided to permanently remove the AppImage?

[psygreg]

The appimage was having recurring problems, so I opted to disable it. I never really had time to troubleshoot or fix it, so it has remained that way ever since. Any help in the development repository to make it a viable option for users would be much appreciated

[Samueru-sama]

what happened with the appimage I made here? #164 (comment) I didn't get feedback if it worked fine.

@psygreg I can setup a repo in pkgforge-dev to make appimage releases if you don't want to deal with maintainership, but I would like to get the appimage releases linked in the repo here, we do something similar with Varia and Pinta already.

[psygreg]

what happened with the appimage I made here? #164 (comment) I didn't get feedback if it worked fine.

@psygreg I can setup a repo in pkgforge-dev to make appimage releases if you don't want to deal with maintainership, but I would like to get the appimage releases linked in the repo here, we do something similar with Varia and Pinta already.

That would be fine by me. I don't really have much time available to maintain and test thoroughly that packaging, so I appreciate the effort

[Samueru-sama]

eh what is this 😅

This is the aur package on Artix linux, this used to run fine before.

Well anyways, just a little harder to figure out how to package it xd

[ivan-hc]

This is the aur package

According with the PKGBUILD, this is just th portable version hosted on both github and codeberg.

And according to this...

The appimage was having recurring problems, so I opted to disable it. I never really had time to troubleshoot or fix it, so it has remained that way ever since.

If the PKGBUILD in Arch Linux does the same that my script do #164 (comment) this means two things:

1. if for @Samueru-sama it does not work from AUR, the problem is the standalone binary
2. if for @psygreg the AppImage does not work, it has been compiled with a non-compatible method

@psygreg how have you built the AppImage?

• if you have used the method of @Samueru-sama , Anylinux, it should bundle also dependencies from Arch Linux, but basically should work anywhere without issues and without the need of dependencies on the host system

• if you have used my method, both the standalone version and my AppImage should be the same thing, and all malfunctions are related to the standalone binary, not to the AppImage. My kind of AppImage based only on what you provide standalone is like a TAR or a ZIP, with the difference that you have no need to extract it to use it

• if you have used other methods, I risk to give you the wrong answer, obviously

[Samueru-sama]

The app coded this in, which prevents me from running it, it is not an issue specific to the packaging format, the dev just directly only supports these systems:

linuxtoys/p3/app/compat.py

Lines 106 to 117 in 33d46f8

	supported_os_keys = {
	"debian",
	"ubuntu",
	"cachy",
	"arch",
	"fedora",
	"suse",
	"ostree",
	"ublue",
	"zorin",
	"solus",
	}

I will be doing my tests with distrobox then.

[Samueru-sama]

Alright it's done I think:

https://github.com/pkgforge-dev/LinuxToys-AppImage/releases

[psygreg]

The app coded this in, which prevents me from running it, it is not an issue specific to the packaging format, the dev just directly only supports these systems:

linuxtoys/p3/app/compat.py

Lines 106 to 117 in 33d46f8
supported_os_keys = {
"debian",
"ubuntu",
"cachy",
"arch",
"fedora",
"suse",
"ostree",
"ublue",
"zorin",
"solus",
}

I will be doing my tests with distrobox then.

Artix should be read as Arch, unless the developer changes the os identifiers without leaving any reference to Arch in /etc/os-release.

LinuxToys determines the host OS by checking both $ID and $ID_LIKE from that file. If 'arch' or 'archlinux' is found in either of them, and the $ID is not a match for cachyos, then it's determined to be arch.

EDIT: yes, they removed all references to Arch in their /etc/os-release. What on earth...

[Samueru-sama]

It seems a bit odd that you would determine this by reading /etc/os-release

I would instead check the thing I need, for example check if pacman, apt, dnf, etc are on available. If you need systemd, then check that the systemd process is running and so on.

I also noticed that the AUR package lists bash a dependecy, but the only thing that needs bash is a shell script in /usr/bin/linuxtoys that is already POSIX, and a few helper installer scripts in this which after taking a quick look I didn't see any bash specific feature that would make it hard to conver them to POSIX shell as well.

Anyways, the appimage is ready.

[psygreg]

It seems a bit odd that you would determine this by reading /etc/os-release

I would instead check the thing I need, for example check if pacman, apt, dnf, etc are on available. If you need systemd, then check that the systemd process is running and so on.

I also noticed that the AUR package lists bash a dependecy, but the only thing that needs bash is a shell script in /usr/bin/linuxtoys that is already POSIX, and a few helper installer scripts in this which after taking a quick look I didn't see any bash specific feature that would make it hard to conver them to POSIX shell as well.

Anyways, the appimage is ready.

The procedure is done this way because not all systems running the same package manager are equal. CachyOS and Arch for example have considerable differences that make me have to omit some features for one and show for the other. Same applies to Zorin, Ubuntu and Debian. Reading from /etc/os-release allows us to set more precise execution standards for platforms that may need it.

While most of LinuxToys is generally POSIX-compliant, not all of it is, as some people had issues in the past attempting to run scripts from LT on CachyOS due to their shell being fish. Since bash is the shell language I'm the most familiar with, and the most feature-rich of them, that's what I stick to when I can't do something efficiently remaining POSIX-compliant - in this case, bash remains a dependency to both ensure all scripts run as intended, and as a facilitator if we need to do something non-POSIX.

[psygreg]

Alright it's done I think:

https://github.com/pkgforge-dev/LinuxToys-AppImage/releases

I'll update the readme and stuff in the main repo and it will mirror to GitHub soon. Thank you!

[psygreg]

Updates already reflected at https://git.linux.toys/psygreg/linuxtoys (mirrors in a few hours here) and in the latest release here and there. Feel free to use my git server too if you see fit.

I'm working from there and mirroring the relevant repositories every 18 hours (there's a setting that allows you to do it for any repository without having to make workflows), then when people download the app, it fetches the releases from GitHub or my git server if that fails, since outages have been a pain lately with both GitHub and Codeberg (which I tried to migrate and work with).

[psygreg]

I'll open a new discussion for AppImage maintenance, closing the issue.