electron-userland
[Feature Request] Switch to the static AppImage runtime.
Context:
https://github.com/FreeTubeApp/FreeTube/issues/5714#issuecomment-2370607804 https://github.com/FreeTubeApp/FreeTube/pull/5747
libfuse2 is EOL and distros no longer ship it by default, the appimage folks have a static runtime that fixes this issue, but it lives in this repo: https://github.com/AppImage/type2-runtime
Said runtime is already used by default in appimagetool and go-appimage.
Using the static runtime also allows to create appimages that work on musl distros, since the old runtime links against libc as well.
Has anyone tried this? @Samueru-sama, did you try this? How do you integrate it? not able to find any relevant document.
Has anyone tried this? @Samueru-sama, did you try this? How do you integrate it? not able to find any relevant document.
The static runtime is used by default in appimagetool and go-appimage.
So for example the AppImages of Cemu, PCSX2, Zen Browser, etc do use it by default already.
electron builder does not use it and as result all appimages produced by it use the old runtime with the libfuse2 dependency, see https://github.com/FreeTubeApp/FreeTube/pull/5747
Thank you @Samueru-sama for response.
Just noticed your comment and the original edit.
The steps are just extracting the appimage and using the appimagetool I linked before to turn the squashfs-root directory back into an AppImage.
It's not clear where the binary they use is coming from https://github.com/develar/app-builder/blob/master/pkg/package-format/appimage/appImage.go
will get it from another repo: https://github.com/develar/app-builder/blob/580c34f2e19347061bc2243fa6ab6e57e9bbd2a6/pkg/linuxTools/tool.go#L13
which is full of other binary blobs: https://github.com/electron-userland/electron-builder-binaries/tree/master/AppImage
Looks like this PR would fix this issue.
With that said I don't like the idea of storing the runtime this way, it should always come from the type2-runtime repo.
EDIT: For example the armv7l runtime was replaced for armv6 to make it compatible with the original raspberry pi.
It's not clear where the binary they use is coming from
Yeah, it's extremely confusing.
Thank you @Samueru-sama for response.
Just noticed your comment and the original edit.
The steps are just extracting the appimage and using the appimagetool I linked before to turn the
squashfs-rootdirectory back into an AppImage.
Those steps fix the fuse2 problem but break auto-update functionality. Unless you found a way to enable it.
Having things hardcoded like this https://github.com/develar/app-builder/blob/580c34f2e19347061bc2243fa6ab6e57e9bbd2a6/pkg/linuxTools/tool.go#L13 makes integrating appimagetool in electron-builder extremely difficult.
Has anyone found a working solution? Other than asking users to install libfuse2 (which is dangerous on some systems, like Ubuntu 23).
Those steps fix the fuse2 problem but break auto-update functionality. Unless you found a way to enable it.
The way for appimages to update is with the embedded update information in the runtime that you can add with appimagetool, that info is then parsed by AppImageUpdate
I saw something similar with tauri that they use their own method as well, which just complicates things.
why does repacking break auto-update?
Because of the sha256 in latest.yml. AppImage was recreated so sha doesn't much anymore.
Unless:
- You calculate sha and update
latest.yml - Recreate AppImage before
latest.ymlis generated
This is on my lengthy todo list of investigations as I am attempting to build pipelines for compiling each asset in a reproducible manner, for both github artifact attestation and more secure distribution. The pipeline scripts will also allow you to easily build the artifacts locally, as just like you called out https://github.com/electron-userland/electron-builder/issues/8686#issuecomment-2590620365, it's not clear where the release artifacts are coming from. (Which has honestly seems like I found the hardest task I could possibly find, as I'm basically reverse engineering each build script from what the release asset is.)
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment, or this will be closed in 30 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment, or this will be closed in 30 days.
This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment, or this will be closed in 30 days.
This issue was closed because it has been stalled for 30 days with no activity.
Reopening this per request, but it's not on my already-lengthy to-do list currently. If anyone would mind investigating the changes required to do this, that'll be a great start in any direction. Best guess in terms of code "ownership" would probably be to migrate any app-builder code from Go into JS within electron-builder
Reopening this per request, but it's not on my already-lengthy to-do list currently. If anyone would mind investigating the changes required to do this, that'll be a great start in any direction. Best guess in terms of code "ownership" would probably be to migrate any app-builder code from Go into JS within electron-builder
https://github.com/electron-userland/electron-builder-binaries/pull/57 does that, all that needs to be done is update the download links and artifacts.
Picked this up in https://github.com/electron-userland/electron-builder-binaries/pull/103
Once released, will need to run full e2e pipeline to validate appimage runtime update. First thing I can do is open the appimage runtime downloader in electron-builder to accept an env var that can point at a pre-downloaded/cached runtime+toolset directory so that we can test local download from electron-builder-binaries without an official release of electron-builder. (This is the same flow/approach already taken for nsis toolset + nsis resource on-demand tooling from electron-builder-binaries repo)
Once this infra is set up, would anyone be willing to also test the updated runtimes locally for their project? I have a few VMs I will ofcourse test with + e2e tests for auto-update flow in docker containers, but I'm sure there's other project setups that have more custom requirements/environments required.
As an additional question I'd like to pose to this group.
I can try to loop this into a v26 minor semver bump, but support will not be long-term for it. Reason for that is that I intend to update this project to Node 22 engine to synchronize with updates from upstream electron/* dependencies (which are also now node 22 req + ESM). In order to match the electron ecosystem, I also plan to upgrade electron-builder to ESM. In this case, support for updated AppImage Runtime would be long-term in the new v27 ESM+node22 release (the CI/CD doesn't allow me to backport fixes to previous versions once the major semver bump happens)
How would you folks like to sequence this appimage runtime update?
Not sure how inner workings of electron builder work, the ideal result is that projects don't have to manually update to new runtime.