Commit Graph
17 Commits
Author SHA1 Message Date
jwinterm db151c2920 fix(ci/macos): bundle the QML modules the app actually imports
5.1.2 shipped a grey mining tab on macOS while Linux was fine. The app said
why: 'qrc:/qml/mining.qml:2:1: module "QtQuick.Layouts" is not installed',
and Contents/Resources held only appicon.icns and qt.conf, with no qml
directory at all. macdeployqt cannot scan .qrc resources, and it was called
without -qmldir, so the bundle shipped no QML modules; scene.qml survived only
because it imports nothing beyond QtQuick.

Pass -qmldir, then blanket-copy the QtQuick and QtQml trees as the AppImage
build already does, because qmlimportscanner does not follow a module's own
qmldir depends chain. Both happen before the dylib passes so new plugin deps
resolve, and before signing, which already sweeps every non-framework Mach-O.
A guard fails the build when a module is missing, because an absent QML module
is invisible until someone opens the tab.
2026-09-12 20:49:23 -04:00
jwinterm 3d38fdd135 ci(macos): bundle Qt image-plugin dylib deps (webp/sharpyuv/brotli) for clean-Mac runtime
macdeployqt bundles Qt frameworks but not the plain @rpath/*.dylib brew
deps of its image plugins, so a no-Homebrew Mac couldn't load webp. Add a
Qt-safe pass that resolves @rpath/*.dylib (never @rpath/*.framework) from
brew, copies them in, rewrites load paths, and fails the build if any
remain. Sign step now re-signs by Mach-O type (not exec bit) so the
install_name_tool-modified plugins get valid signatures.
2026-08-30 05:34:04 -04:00
jwinterm f2c3ce45a0 ci(macos): link boost statically (Boost_USE_STATIC_LIBS=ON)
The 100%-linked app dynamically referenced brew's libboost_*.dylib, which
macdeployqt failed to bundle — the app would fail to launch on any Mac
without Homebrew (notarization doesn't check runtime dylib resolution).
Static boost matches how guix/depends release builds work and removes the
runtime dependency entirely.
2026-08-30 05:08:01 -04:00
jwinterm 87d5977243 ci(macos): CPATH/LIBRARY_PATH to brew prefix so feather finds boost headers
monero's static libs built fine, but the feather target includes monero
headers pulling boost/variant.hpp, and clang doesn't search
/opt/homebrew/include by default (modern BoostConfig leaves
Boost_INCLUDE_DIRS empty).
2026-08-30 04:55:20 -04:00
jwinterm 9e6d85c246 ci(macos): disable Trezor (USE_DEVICE_TREZOR=OFF)
brew's protobuf pulls Abseil headers that require C++17, breaking the
feather compile (DEVICE_TREZOR_READY gates the protobuf link). Trezor
hardware does not support Wownero, so this removes a useless dependency
rather than working around it — the Linux lane only tolerates it because
its depends system pins an old protobuf.
2026-08-30 04:42:14 -04:00
jwinterm 0f6892c123 ci(macos): ad-hoc sign tor before embedding — arm64 macOS SIGKILLs unsigned binaries, including the runtime-unpacked copy on user machines 2026-08-29 14:17:26 -04:00
jwinterm 1fedbf0faa ci(macos): ship libevent dylib next to tor (@executable_path linkage) 2026-08-29 14:06:15 -04:00
jwinterm 410df0c8ff ci(macos): extract wownerod into an explicit dir — find(1) does not descend the /tmp symlink 2026-08-29 13:55:16 -04:00
jwinterm 1853ebf558 ci(macos): disable pipefail around yes|brew (SIGPIPE 141 when brew asks nothing) 2026-08-29 13:47:37 -04:00
jwinterm a2b34f5ebc ci(macos): embed tor (expert bundle 15.0) — arms daemon --tx-proxy via HAS_TOR_BIN, parity with linux lane 2026-08-29 13:44:28 -04:00
jwinterm 8b846a8dc0 ci(macos): pin CMAKE_PREFIX_PATH to brew qt6 (qt@5 keg coexists unlinked on the runner) 2026-08-29 13:37:41 -04:00
jwinterm dc5f940801 ci(macos): pipe yes into brew — Homebrew 6 prompts for dependency installs regardless of NONINTERACTIVE 2026-08-29 13:27:05 -04:00
jwinterm 36d878e7bf ci(macos): also skip dependent upgrades in brew install 2026-08-29 13:16:13 -04:00
jwinterm a526061d97 ci(macos): place appicon.icns into the bundle 2026-08-29 13:15:24 -04:00
jwinterm f4c5ec3c25 ci(macos): non-interactive brew 2026-08-29 13:10:03 -04:00
jwinterm 1217ce174c ci(macos): sign + notarize with Developer ID cert via desktop-lane secrets 2026-08-29 12:17:21 -04:00
jwinterm 914fa1ed32 ci: native macOS lane for the Gitea self-hosted runner
Dispatch-only workflow in .gitea/workflows (GitHub ignores the
directory): brew dependencies, native cmake build with the embedded
wownerod fetched per-arch, unsigned app bundle artifact. Runs on the
mac runner whose work dir lives on DataSSD and is outside every backup
path. Signing/notarization follows once a Developer ID Application
certificate is provisioned as repo secrets.
2026-08-29 07:04:39 -04:00