NEW MAINTAINER IN NEED

[azubieta]

For personal reasons I'm not able to provide the love (and the time) this project needs. Therefore we will be looking for a new maintainer.

Please use this issue to post your request.

[guihkx]

I appreciate the work you've put into this great tool, thank you for that!

If it's not too much to ask, would it be possible for you to make a new release before a new maintainer takes over?

[nicolasnoble]

I'm an active user of appimage-builder, and I am depending on it. I don't necessarily want the burden of another OSS project to maintain, but if nobody else stands up within the end of this upcoming week, we can discuss.

[azubieta]

Hi @guihkx, let me check if the build pipelines still work.

@nicolasnoble thanks a lot

[Lord-Kamina]

I have been trying (unsuccesfully) to produce a working build over at https://github.com/ooshlablu/appimage-builder/tree/fix-deps-2

Even when the tests and build pass, the end result is not usable.

[guihkx]

@Lord-Kamina All I had to do to fix mine was to install the git version of appimage-builder with pip, and then I added comp: zstd under the AppImage section of my YAML recipe.

[Lord-Kamina]

I was trying to fix the CI as well, and Ideally update the dependencies.

[Lord-Kamina]

So... weird thing here:

koji@MacbookPro-Linux:~/appimage-builder$ ./appimage-continuous.AppImage --appimage-extract
QSocketNotifier: Can only be used with threads started with QThread
This doesn't look like a squashfs image.
Failed to open squashfs image

That's the continuous release AppImage for appimagetool. Tried both continuous and 1.9.0, both with the same error.

[guihkx]

The x86-64 continuous build from here extracts just fine on Arch:

❯ sha256sum appimagetool-x86_64.appimage
363dafac070b65cc36ca024b74db1f043c6f5cd7be8fca760e190dce0d18d684  appimagetool-x86_64.appimage
❯ file appimagetool-x86_64.appimage
appimagetool-x86_64.appimage: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=effd916894d8c36c58e607b194ca27f9ef939cec, stripped
❯ ./appimagetool-x86_64.appimage --version
appimagetool, continuous build (git version 7cfafc4), build 251 built on 2025-06-01 16:06:33 UTC
❯ ./appimagetool-x86_64.appimage --appimage-extract
❯ du -sh squashfs-root
36M	squashfs-root

[Lord-Kamina]

The x86-64 continuous build from here extracts just fine on Arch:

❯ sha256sum appimagetool-x86_64.appimage
363dafac070b65cc36ca024b74db1f043c6f5cd7be8fca760e190dce0d18d684  appimagetool-x86_64.appimage
❯ file appimagetool-x86_64.appimage
appimagetool-x86_64.appimage: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=effd916894d8c36c58e607b194ca27f9ef939cec, stripped
❯ ./appimagetool-x86_64.appimage --version
appimagetool, continuous build (git version 7cfafc4), build 251 built on 2025-06-01 16:06:33 UTC
❯ ./appimagetool-x86_64.appimage --appimage-extract
❯ du -sh squashfs-root
36M	squashfs-root

That particular issue turned out to be AppImageLauncher's fault. I don't know whether it's been fixed but I was using a very old build of it so I disabled it and extraction works.

The AppImage still doesn't launch, however, which I think is due to the interaction of a bug in AppRun as well as one in appimage-builder:

1. appimage-builder is not putting the ld-linux under runtime/compat/lib64/
2. AppRun determines the runtime to use by comparing the libc versions between the bundle and the system. The problem is the comparison is written as (pseudocode) if (system > bundled) use default; else use compat, so when both have the same version, it tries to use the ld-linux from the bundle and fails to find it.

[Lord-Kamina]

BTW, my fork now has a version of appimage-builder that should have the above fixed, as well as having been packed on ubuntu 24.04 with python 3.12 among other things.

[pepijndevos]

What I've been doing for projects I don't have time for anymore is just be liberal with giving out commit access to people who submit good PRs. That doesn't place the burden on a single person. I think you can configure github so that a review is required for a PR to build some distributed consensus.

[james-lawrence]

@Lord-Kamina @azubieta i can offer light maintenance work on this project. aka: ensuring code reviews/builds/releases/minor fixes. from my local usage there isnt much beyond some modernization that kamina seems to have taken care of. i think this project is important enough to keep going as when it works its magical. =) the problem is its just bit rotted a bit.

[azubieta]

Thanks a lot @Lord-Kamina @james-lawrence for stepping up. Will give you commit access. I'm inviting you to our telegram channer so we could coordinate work.

t.me/appimagecrafters

[james-lawrence]

@azubieta sounds good, I joined the channel (i think, telegram is a little wonky ux wise for me) =). can see the pinned messages but not post anything I assume i need to be enabled somehow =)