Announcing v3.0.0

[TheAssassin]

After a lot of back and forth, cleaning up, refactoring and dealing with build issues, the time has finally come for the all-new version 3.0.0 to be released.

This announcement will be kept up to date until 3.0.0 has finally been released.

Changes

This new release features a new binary packages build system that was pretty much rewritten from scratch. It now uses linuxdeploy to build the native .deb and .rpm packages, too, using linuxdeploy-plugin-native_packages.

In addition to x86_64, there will now be official ARM packages for both the full and lite releases, both for 32-bit and 64-bit ARM.
Furthermore, support for i386 has been dropped, as there are hardly any distributions that still support it (the mainstream distros dropped i386 years ago), and the maintenance overhead clearly outweighs the benefits for the tiny user base.

With 3.0.0, we now ship an up-to-date libappimage version that supports the new static runtime which has been the default runtime for users of appimagetool and soon will be for users of linuxdeploy, too.

Another important change will be the new method to bypass binfmt_misc. Long-time users may already know that this feature of the Linux kernel is very important for AppImageLauncher's integration into the system, but also one of the main issues. AppImageLauncher may need to bypass it to be able to launch AppImages after treating them. Given the introduction of static runtimes, we can no longer rely on the old mechanisms. In fact, many people already have seen the strange error messages related to this (or nothing at all, meaning that the AppImage crashed silently).

The release further fixes a lot of bugs.

PPA

The PPA has apparently been abandoned and is no longer maintained. Therefore, it will no longer be advertised from the README. The new packaging system provides packages that work on almost every (glibc-based) distribution, at least on the more recent releases. A compatibility table will be included.

How to download and test the pre-release binaries

You can find the most recent builds in the moving continuous tag. The latest pre-release at the time of writing is v3.0.0-alpha-4. Please don't hesitate to download and test these and provide feedback whether they improve the existing issues.

Please refrain from reporting new issues found in alpha releases! There are a few known bugs that have not been addressed yet. Once v3.0.0 reaches the beta phase, issues may be reported.

[krale777]

I installed the rpm version, worked flawlessly, identified all my downloaded AppImages and made entries in the application menu. Good work and I'm so happy this projects lives, I thought it was dead, but to my surprise I see the 3 alpha. Fantastic.

[TheAssassin]

As pointed out occasionally, packaging was a nightmare and really demotivating. I already cleaned up most stuff last year, but then the planned ARM builds caused a lot of issues through QEMU with GitHub's runners specifically, so that again delayed the process. The introduction of hosted ARM runners by GitHub a few weeks ago sped up everything: the builds now take a fraction of the time (comparable to amd64-based runners) and there is no need to bring in QEMU any more at least on GitHub.

[TheAssassin]

Small update: AppImageLauncher's latest alpha release, v3.0.0-alpha-3, now supports static runtimes. It still uses the old binfmt_misc bypass algorithm based on extracting the runtime (and therefore also $TARGET_APPIMAGE), which should work well enough until a new AppImage type is engineered that provides a better solution.

[TheAssassin]

The next alpha release, v3.0.0-alpha-4, fixes most of the daemon-related issues users were facing. Please don't hesitate to try this release and provide feedback!

[protonenfalter]

Where and in which form should we provide feedback? If I understand correctly users should refrain from opening new issues. However, there doesn't seem do be a dedicated discussion either. Is this here the right place?

[TheAssassin]

Feel free to leave it here.

[wommy]

its working inside of chromeOS's bookworm lxc using the .deb
aka appimagelauncherd kinda works
but enough to get ditch appimaged

i know bookworm isnt specifically supported,
but trixie is due out in a few months now ( next 18 month stable )
could be a nice sprint

some issues i encountered

i originally went for the -lite.appImage
thinking smaller might have a higher chance of working
couldnt get that to work
but i dont think i uninstalled appimaged correctly,
and that might have been creating some interference
with the -lite.appImage and appimaged it failed on the modprobe line

was there a check for this before or am i conflating?

also i dont think it took until i did a reboot,
a similar prompt as this might be nice on the postinstall

if you could get this to work inside of an unprivileged Incus on ubuntu
itll work just about anywhere

looking forwards to the next alpha ✌️✌️

p.s.
totally installed binfmt-support trying to fix original install, and hit this
thought it was appimagelauncher's fault, just leaving this here in case it helps someone else

[TheAssassin]

Debian bookworm is going to be one of the supported (tested) releases.

[wommy]

thats great and should be done,

but my point is the trixie toolchain freeze is about to happen march 15

so aiming for a stable trixie, which is probably due out in august, would put you in the clear for 2 years

plus, bc trixie is newer, if you nail bookworm, trixie should be even more simple

so a touch bit more work for 2 years of 'just works' is probably worth it

it should go without saying but explicitly, im also down to help with that

[TheAssassin]

AppImageLauncher should work on all systems newer than bookworm. It's just the minimum required version. The new packaging makes it very portable.

[RedSnt]

I fell into the appimaged trap, which is an excellent daemon for sure, but not configurable and the updater tool is half a decade old and doesn't support a lot of things.
Glad I found this project, and looking forward to see what v3+ brings.

[boris099]

I am on the way to install Appimagelauncher and now noticing that there are new development activities - GREAT!!!
One question: When I now install the alpha4 instead the stable how can I update later to next alpha or stable without loosing my config?

[boris099]

OK installed alpha4 on Debian12 do have the application now sitting in Software, looks fine.
When starting it asks me for that one flag and the folder for the appimages.
I set and used a folder where I do have 3 appimages already.
When double click on my existent appimages they start as usual but there is no reaction from the launcher.
What should happen? Can I add these existent appimages into launcher can´t see how the launcher should work??

[boris099]

Wait a second .... I see the appimages in my standard applications listed incl. Icon - is it that?
If Yes this great :-)

[boris099]

Works flawless, this is how it should be

[TheAssassin]

Yep, that's how AppImageLauncher works. I try to avoid custom user interfaces wherever possible.

[boris099]

Perfect work! - maybe just a comment in your description explaining that it works like that, Ok I never used it before therefore wondering about the functionality

[PrudentMantis]

Hi, I'm running an Arch-based distro. So, not one that natively works with rpms or debs. I tried installing the AppImage Lite version, but it fails silently - the 'Integrate and Run or just Run Once' prompt doesn't even come up. When I run in terminal, I get execv error: No such file or directory. Is this a situation where I just have to bite the bullet and figure out how to get the rpm or deb to run? I'm new to Linux (Windows refugee), so I'm really hoping you don't say yes, lmao.

[TheAssassin]

Arch and derivatives aren't classic distros, i.e., I won't even try to guess what exactly you are running. You can imagine that that makes it really really hard to debug problems. But then again, AppImageLauncher is packaged in AUR as far as I remember. Maybe you can try that?

[PrudentMantis]

Starting to think I shoulda picked a different distro to learn Linux on...