packaging.yml: ship aMuleGUI.app in macOS Universal2 .dmg - #529
Merged
Conversation
The macOS pipeline builds aMuleGUI.app correctly per arch (packaging/macos/build.sh sets BUILD_REMOTEGUI=YES; CMake produces aMuleGUI.app via MACOSX_BUNDLE TRUE on the amulegui target), and the per-arch .dmg that build.sh emits does contain it (make_dmg stages it next to aMule.app at the dmg root). The two-job CI pipeline then dropped aMuleGUI.app on the floor: macos-build (per arch) -> uploaded aMule.app only. macos-universal2 -> downloaded aMule.app, lipo-merged, dmg. aMuleGUI.app never crossed the artifact boundary, so the released Universal2 .dmg shipped only aMule.app. Verified by mounting the b719355 macos-universal2 artifact: dmg root contained aMule.app plus the /Applications symlink, no aMuleGUI.app. Linux is unaffected: - AppImage: build.sh:56 lists amulegui in EXTRA_BINS, linuxdeploy is invoked with --executable .../amulegui so its .so deps are bundled, AppRun:45 dispatches via argv[0]. - Flatpak: org.amule.aMule.yaml.in:318 sets BUILD_REMOTEGUI=YES; cmake install puts amulegui at /app/bin/amulegui, reachable via `flatpak run --command=amulegui`. Windows is unaffected (.zip already contains every .exe.) Changes: - macos-build (per arch): upload aMuleGUI.app as a second artifact (macos-gui-${arch}). Add a per-arch dmg sanity check that aMuleGUI.app is present at the dmg root before upload, so a silent BUILD_REMOTEGUI regression would fail the job loudly. - macos-universal2: download both arches' aMuleGUI.app, lipo-merge + ad-hoc-codesign the same way as aMule.app (existing inline lipo loop refactored into a merge_app shell function called twice), and stage both bundles in the Universal2 .dmg.
This was referenced May 27, 2026
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
2 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.
Summary
The macOS pipeline builds
aMuleGUI.appcorrectly per arch —packaging/macos/build.shsets-DBUILD_REMOTEGUI=YES,src/CMakeLists.txt:389-397setsMACOSX_BUNDLE TRUEon theamuleguitarget, andmake_dmg()stages it at the per-arch dmg root next toaMule.app.The two-job CI pipeline then dropped it on the floor:
macos-build(per arch)build-macos/src/aMule.apponlyaMuleGUI.apptoomacos-universal2aMule.app, lipo-merged, wrapped in dmgaMuleGUI.appaMuleGUI.appnever crossed the artifact boundary, so the released Universal2 dmg shipped onlyaMule.app. Verified empirically by mounting themacos-universal2artifact from packaging-CI run25374200598(master tipb71935541) — dmg root contained onlyaMule.appand the/Applicationssymlink.Other platforms — not affected
packaging/linux/appimage/build.sh:56listsamuleguiinEXTRA_BINS,linuxdeployis invoked with--executable …/amuleguiso its.sodeps are bundled, andAppRun:45dispatchesamuleguivia argv[0]. The AppImage is a single self-contained bundle so there's no per-arch handoff to drop binaries at.packaging/linux/flatpak/org.amule.aMule.yaml.in:318setsBUILD_REMOTEGUI=YES;make install PREFIX=/appputsamuleguiat/app/bin/amuleguiinside the sandbox, reachable viaflatpak run --command=amulegui org.amule.aMule..exeis already in the zip; no merge step in the pipeline.Changes
macos-build(per arch) — uploadaMuleGUI.appas a second artifact (macos-gui-${arch}). Added a per-arch dmg sanity check thataMuleGUI.appis present at the dmg root before upload, so a silentBUILD_REMOTEGUIregression would fail the job loudly rather than silently propagating to the merge step.macos-universal2— download both arches'aMuleGUI.app, lipo-merge + ad-hoc-codesign the same way asaMule.app. The existing inline lipo loop is refactored into amerge_appshell function called twice (once per bundle); the umask/chmod and codesign comments are preserved verbatim. Both bundles are then staged into the Universal2.dmg.Test plan
packaging.ymlagainst this change on the fork (run25424603605, scopeonly=macos):macOS .app (arm64)andmacOS .app (x86_64)both succeeded — including the new sanity check thataMuleGUI.appis present at the per-arch dmg root.macos-gui-arm64andmacos-gui-x86_64artifacts uploaded.macOS Universal2 .dmgjob succeeded —merge_appran on both bundles, codesign succeeded on both, dmg built.macos-universal2artifact (aMule-4161bc5-macOS-universal2.dmg), mounted it, confirmed root contains bothaMule.appandaMuleGUI.app.lipo -infoonaMule.app/Contents/MacOS/aMuleandaMuleGUI.app/Contents/MacOS/aMuleGUIreportsx86_64 arm64for both.INSTALL_BINARIES.mdclaim thataMuleGUI.appships in the.dmgbecomes accurate once this lands.Why this only matters now
Before 3.0.0 the macOS pipeline produced just one
.app(the autotools build path didn't bundle remote-GUI as a separate.app). The Universal2 split-build / merge handoff is new in this release cycle, and the artifact list was written for the single-bundle case.