Windows crash chain (exposed by the embedded-node default):
- main.cpp: force the QtQuick software renderer. The Mining tab's QQuickWidget
drove the default RHI/GL path and faulted (0xc0000005) on broken-GL hosts
(VirtualBox VMSVGA), crashing the app and orphaning the embedded node.
Real hardware was unaffected.
- ChildProcessGuard + DaemonManager/TorManager: kernel-level die-with-parent
(Windows Job Object KILL_ON_JOB_CLOSE / Linux PR_SET_PDEATHSIG) so the
embedded wownerod and bundled tor never survive a wowlet exit or crash.
- DaemonManager: verify-before-adopt via get_info (nettype/height) instead of
trusting a bare open RPC port, so a stale/orphan node is never adopted.
Node/Tor lifecycle + remote-node connectivity:
- config: torPrivacyLevel default -> allTorExceptNode. NEVER sync blocks over
Tor; the wallet's node connection is always clearnet. Tor is only for tx
broadcast, so remote nodes work with or without Tor.
- nodes: add Nodes::reconnect() (clear failure blocklist + force reconnect);
node/Tor toggle handlers use it so a transient outage no longer strands the
wallet at "Disconnected".
- MainWindow/SettingsDialog: reconnect on node/Tor toggle and on the async
daemonStateChanged (closes the start() race; a freshly-toggled local node
connects immediately).
- TorManager: reset retry/unpack state in init() so a system<->bundled Tor
re-toggle can start again; quiesce on stop(). Linux unpackBins() rework
(mkpath + presence-based unpack + graceful return-false), getVersion() arg
fix, and a missing-binary start guard.
- build.yml: derive TOR_VERSION from the embedded tor binary (a hardcoded
bundle number made unpackBins rewrite Tor every launch).
- depends/funcs.mk: confine cross-cmake find_package to the depends sysroot so
host -dev libraries don't leak into the build.
v5.0.0 ships Windows x86_64 + Linux x86_64. arm64/riscv64 (Qt static-link gap) and macOS deferred to v5.0.1. continue-on-error keeps the cross job from failing the release run while I keep iterating it.
libxkbcommon 1.13.1 meson.build adds empty pkgconfig vars when xkeyboard-config is absent from the cross sysroot (XKEYBOARD_CONFIG_ROOT='') while has_extensions_directories is true -> meson hard-errors at pkgconfig.generate. Pass non-empty -Dxkb-config-(un)versioned-extensions-path.
Add restore-keys to all 4 depends cache restores: a busted exact key (any packages/* edit) now falls back to the newest prefix match, so make resumes from the partial built tree instead of rebuilding the static-Qt6 toolchain from scratch.
Cross-build wowlet via depends for aarch64/riscv64 (reusing the zeromq/ICU/qt/testlib fixes), embed the matching wownerod + depends-built tor, package an AppImage via contrib/AppImage/build-appimage.sh (its hardcoded /feather runtime path relativized to GITHUB_WORKSPACE). Cached per-host, save-always.
wowlet.exe reached 27% then hit 'zmq.h: No such file' — feather strips zeromq from depends (its wallet does not use zmq) but wownero cryptonote_core/net does. Port the wownero zeromq.mk + patch, register it in packages. Also switch the depends caches to restore + save(if:always) so the completed toolchain banks even when the wowlet build fails (auto post-save is skipped on job failure).
Disk fix let it run 50min (vs ~10min) before the runner lost communication again -> OOM during the parallel Qt6 compile, not disk. Drop both builds to -j2 and add a 10G swapfile for headroom. Slower but should complete + cache depends for fast future runs.
First run was killed mid depends build (runner lost communication = CPU/Memory/disk starvation). Inside a container we cannot reclaim the runner's pre-installed bloat, leaving the static-Qt6 build only ~14G. Run on ubuntu-latest directly, free ~25G (dotnet/android/ghc/CodeQL), sudo the apt steps.
Builds wowlet.exe via contrib/depends (static Qt6 + tor), embeds wownerod.exe from the wownero mingw release, packages a .zip. Caches the depends tree so only the first run pays the ~1h toolchain cost. Tor shipped loose next to the exe (TOR_INSTALLED).
So wowlet works for users without a system Tor. The build fetches the
tor-expert-bundle (linux x86_64), patchelfs the tor binary + its libs to
$ORIGIN, and passes -DTOR_DIR/-DTOR_VERSION so cmake embeds them into
:/assets/tor and sets HAS_TOR_BIN=1. wowlet then extracts + manages its own
Tor daemon -> remote node connections route over Tor out of the box.
such-gitea
jwinterm