ci: build and attach native Linux packages (.deb / .rpm / Arch) to releases#11323
Open
BenJule wants to merge 1 commit into
Open
ci: build and attach native Linux packages (.deb / .rpm / Arch) to releases#11323BenJule wants to merge 1 commit into
BenJule wants to merge 1 commit into
Conversation
Compiles BambuStudio from source in each distribution's own container and packages the result natively, then uploads the .deb / .rpm / .pkg.tar.zst to the release (issue bambulab#11321). Unlike an AppImage wrapper, the GTK/GLib/X11/etc. libraries are declared as package dependencies and used from the system instead of being bundled, so these are proper distro-native packages. The build reuses the existing BuildLinux.sh (-u/-d/-s) plus three packaging scripts (scripts/build_deb.sh, build_rpm.sh, build_pkg_arch.sh) that turn the compiled build/package/ tree into each format. Runs on release publish or manual dispatch, with the dependency build cached per distro.
BenJule
force-pushed
the
ci/release-linux-native-packages
branch
from
a7f3b26 to
2c7fc5e
Compare
BenJule
changed the title
Contributor
Author
|
Updated: switched this from the lightweight fpm/AppImage-wrapper approach to a proper native build. It now compiles BambuStudio inside each distro's container and packages the compiled tree, so the GTK/GLib/X11/etc. libraries are real system dependencies instead of being bundled inside an AppImage. Heavier in CI, but the resulting .deb/.rpm/.pkg are genuine native packages. |
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Closes #11321. Publishes native Linux packages alongside the AppImage on every release, so Debian/Ubuntu, Fedora/RHEL and Arch users can install with their own package manager and get desktop/MIME integration.
This builds proper distro-native packages, not an AppImage wrapper: BambuStudio is compiled from source inside each distribution's own container, so the GTK/GLib/X11/etc. libraries are declared as package dependencies and used from the system rather than bundled.
When a release is published (or on manual dispatch against a tag) it produces and attaches:
bambustudio_<ver>_amd64.deb(Debian/Ubuntu)bambustudio-<ver>-1.x86_64.rpm(Fedora/RHEL/openSUSE)bambu-studio-bin-<ver>-1-x86_64.pkg.tar.zst(Arch)How it works
Each distro builds in its own container (
debian:trixie,fedora:42,archlinux:latest) and reuses the existing build entry point:./BuildLinux.sh -u— install build dependencies./BuildLinux.sh -d— build the bundled dependencies (cached between runs)./BuildLinux.sh -s— build the slicerBuildLinuxImage.sh -i— assemblebuild/package/(binary + libs + resources)The three packaging scripts (
scripts/build_deb.sh,build_rpm.sh,build_pkg_arch.sh) install the compiled binary under/usr/lib/bambustudio, ship a/usr/binwrapper, a.desktopentry and icons, and deliberately exclude GTK/GLib/X11/Wayland/DBus/fontconfig/etc. from the bundled libs so the system copies are used (declared viaDepends/Requires/depends). These are the same scripts I've been using on my fork, where the packages have been live and installable for a while.Test plan / notes
deps/build/destdircached per distro to keep subsequent runs reasonable.workflow_dispatchagainst the latest tag is the way to validate end to end. The packaging scripts are proven on my fork's custom build images; the main thing to confirm here is thatBuildLinux.sh -uprovisions cleanly on the stockdebian:trixie/fedora:42/archlinux:latestbase images. Happy to switch to prebuilt dep images or adjust anything to match your conventions.