You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 2, 2026. It is now read-only.
Improved AppImage Build Process for Better Compatibility
The previous AppImage was built on a rolling-release distribution (Arch Linux), which caused compatibility issues for users on stable distributions with older package versions. This meant they couldn't run the AppImage unless they built it themselves—something I admittedly should have tested on other distributions. Lesson learned.
What's Changed
To ensure broader compatibility across distributions, we've introduced a new build process:
Docker-Based Build: The AppImage is now built inside a Docker container, which the script sets up and cleans up automatically.
Clean Builds Every Time: The script runs in no-cache mode, ensuring a fresh build with every execution.
Mac Compatibility: The script should theoretically work on macOS as well, which is useful since Andrew plans to build it locally. The free plan of Docker should be sufficient, possibly without requiring an account.
Detailed Documentation: A comprehensive README is included to guide users through the process.
This update should provide a more reliable and consistent AppImage experience across different Linux distributions.
This is good! Is there a way to do it for Windows and present a Unified Script? The builds take really long and if containers can solve for all OS then building in cloud over a script would be amazing. More of a CI/CD Process. When a new version tagged, CI/CD trigger and build on cloud instance -> dump to S3(or any storage). Would save a lot of time tbh!
This is good! Is there a way to do it for Windows and present a Unified Script? The builds take really long and if containers can solve for all OS then building in cloud over a script would be amazing. More of a CI/CD Process. When a new version tagged, CI/CD trigger and build on cloud instance -> dump to S3(or any storage). Would save a lot of time tbh!
There is no reason to adapt it to Windows the Binaries are already available in the Beta Releases
all my script does is to pack the prebuild Folder into a Single binary for Linux Andrew can just offer a single Binary instead of a folder
Thanks for this, this is great.
Is there a reason to rename to void-...? I have some other scripts that use this file so would ideally keep it vscode, is this used anywhere in the script you added?
Thanks for this, this is great. Is there a reason to rename to void-...? I have some other scripts that use this file so would ideally keep it vscode, is this used anywhere in the script you added?
do you mean the rename in the gumpfile ? that change wasent made by me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Improved AppImage Build Process for Better Compatibility
The previous AppImage was built on a rolling-release distribution (Arch Linux), which caused compatibility issues for users on stable distributions with older package versions. This meant they couldn't run the AppImage unless they built it themselves—something I admittedly should have tested on other distributions. Lesson learned.
What's Changed
To ensure broader compatibility across distributions, we've introduced a new build process:
Docker-Based Build: The AppImage is now built inside a Docker container, which the script sets up and cleans up automatically.
Clean Builds Every Time: The script runs in no-cache mode, ensuring a fresh build with every execution.
Mac Compatibility: The script should theoretically work on macOS as well, which is useful since Andrew plans to build it locally. The free plan of Docker should be sufficient, possibly without requiring an account.
Detailed Documentation: A comprehensive README is included to guide users through the process.
This update should provide a more reliable and consistent AppImage experience across different Linux distributions.
Let me know if you have any questions! 🚀