The compact build cannot complete itself off Linux: the fetcher serves no emulator for macOS or Windows

[A13xB0]

The compact builds in #509 are only a fair offer if they can finish themselves. On Linux they can: Configuration > Setup fetches the chip model, qemu-system-xtensa and renode, pinned by tag and checked by digest, about 105 MB once and cached for every scenario after. Off Linux they cannot, so a compact macOS or Windows build means building the forks by hand.

That is a reasonable thing to offer somebody who wants it. It is not a reasonable thing to hand over silently behind a button marked "compact".

What is actually missing

From internal/app/resource/toolchaincatalogue.go:

• macOS: the chip model has a darwin/arm64 asset and so, since v9.2.2-meshbench-sx1262-11, does QEMU - the fork's release matrix builds aarch64-apple-darwin and the catalogue pins its digest. What has never happened is anybody starting a board with it, so it is pinned and unproven rather than missing. Renode is the real gap: the fork publishes a macOS build tree rather than a portable package, with no launcher, and no nRF52 board has ever been brought up on macOS.
• Windows: nothing at all, refused by windowsHasNoEmulation. See Packaging and the runtime catalogue disagree about whether emulation works on Windows #513, because that refusal and the packaging job currently disagree.

And a smaller thing underneath it

formatOf in internal/app/resource/execformat.go recognises ELF and Mach-O and nothing else, so a PE binary fails the post-fetch check with "no ELF or Mach-O header" even if everything above it were solved. A Windows fetch needs a PE case (MZ, then the COFF machine word at the e_lfanew offset) before any of this can work.

Order

1. Add the PE case to execformat.go. Small, testable now, blocks nothing else.
2. Settle Packaging and the runtime catalogue disagree about whether emulation works on Windows #513, which decides whether Windows emulator assets are worth fetching at all.
3. Bring one ESP32 board up on macOS against the pinned QEMU, which is now a question of running it rather than of building it.
4. Get the Renode fork publishing a portable macOS package rather than a build tree, and bring one nRF52 board up on macOS to prove it. Setup must also place Renode's renode-support/ files, or a machine with both emulators still starts only ESP32 boards.

Until 3 and 4 land, the compact macOS chips on the download page say what they hand over: the fork URLs, the branch names, and MESHBENCH_QEMU / MESHBENCH_RENODE. Stock builds will not do, and that has to be the first line rather than a footnote: stock QEMU has no SX1262 device, and stock Renode sleeps for ever on a wake condition that is already true.

[A13xB0]

Parented under #568, which makes this the gate on offering compact per platform
rather than a loose end beside it.

The macOS inventory in this issue is out of date, in our favour. It says
radioserver has a darwin/arm64 asset and neither emulator does. That process no
longer exists: the chip is
virtual-sx1262, loaded by whichever
emulator runs the board, and it publishes macos-arm64 and windows-amd64
alongside Linux. So what is missing on macOS is the two emulators, not three
things, and the chip half of the problem is already solved on every platform.

The rest stands as written:

• QEMU for macOS is a runner question. Worth noting the fork's release matrix
  does build aarch64-apple-darwin and publishes it - v9.2.2-meshbench-sx1262-11
  carries it, and the catalogue pins its digest today. What has never happened is
  anybody starting a board with it.
• Renode for macOS still publishes a build tree rather than a portable
  package, and no nRF52 board has been brought up on macOS.
• The PE case in execformat.go is still the small independent piece, and
  still blocks nothing else.

#513 is closed, so step 2 of the order in this issue is done.

One addition to the list of what a working macOS or Windows Setup has to fetch:
Renode's support files, the .repl descriptions and our C# peripherals.
Nothing shipped them until now, and without them a machine with both emulators
installed can still only start ESP32 boards. Bundles carry them in
renode-support/; a compact install that fetches Renode needs them too.

[A13xB0]

Why the macOS Renode artefact is a build tree, and it is not what this issue assumed

-t has been working the whole time. Nothing is unsupported, and no Mac was
needed to find this out.

MeshBench/renode's build.sh -t calls
tools/packaging/make_${DETECTED_OS}_portable.sh, and make_osx_portable.sh
exists and does its job: it assembles a real portable Renode.app and then

hdiutil create -volname Renode_$VERSION -srcfolder $MACOS_APP_DIR -ov \
  -format UDZO $OUTPUT/renode-$VERSION.$RID-portable${HEADLESS_SUFFIX}.dmg

A .dmg. The workflow's collect step looks for exactly one thing, copied
from the Linux job beside it:

for f in $(find output packages -maxdepth 3 -name '*portable*.tar.gz' 2>/dev/null); do

which matches nothing, so the fallback underneath fires:

if [ -z "$(ls -A dist 2>/dev/null)" ]; then
  tar czf dist/renode-meshbench-macos-arm64.tar.gz -C output/bin Release
fi

and the raw build tree ships instead. So the catalogue's stated reason - "the
fork publishes a macOS build tree rather than a portable package" - is a symptom
of a one-word mismatch, not a missing capability.

The real bug is the fallback

It made a broken artefact look like a successful build, for as long as this has
been true, with a green tick on every run. That is the same shape as the three
other faults found alongside it this week: the Windows job fetching emulators
before the compact tree was cut, verify-bundle.sh treating an unlabelled tree
as compact, and the updater matching two assets on one suffix. A silent fallback
in a packaging step is a bug in its own right, whatever it is falling back from.

Whatever else changes, that if should say what it did rather than do it
quietly.

What has to be decided, not just typed

The glob is the easy half. The harder half is what MeshBench should be handed,
because a .dmg is the right macOS shape and arguably better than a tarball:

1. Ship the dmg and teach the fetcher to open it. hdiutil attach is macOS
   only, which is fine - it would only ever run there - but it is a new archive
   kind in internal/app/resource/archive.go beside the tar and zip ones, and
   an attach/detach that has to survive a failure part-way through.
2. Unwrap it in the workflow and publish the Renode.app as a tarball, so
   the catalogue gains a fourth ordinary entry and nothing in MeshBench changes.
   Loses the disk image that a person downloading Renode by hand would want.
3. Publish both. Cheap, and the two audiences are genuinely different.

I would take (2): the fetcher already knows how to unpack a tarball into the
tools directory and find a binary inside it, and this keeps the macOS path
identical to the other two rather than special.

Either way it is a change to MeshBench/renode, then a digest pinned here, then
one nRF52 board brought up on the macos-m4 runner to prove it - which is the
part that still has to actually run.

[A13xB0]

Progress against the four ordered items, measured rather than assumed.

1. PE case in execformat.go — done (#569). formatOf reads MZ, then
the COFF machine word at e_lfanew, with a bounds guard. Windows can also
unpack a zip (Renode publishes one) and no longer finishes with a symlink,
which Windows grants only to an elevated process — the lookup searches the same
subdirectories on both sides instead (#572).

2. #513 — settled and closed.

4. The Renode macOS gap — the packaging half is fixed (#575). The fork's
job matched *portable*.tar.gz while make_osx_portable.sh produces a .dmg,
found nothing, and silently tarred the build tree — so the asset had no
launcher, which is why this issue called it a build tree. It now unwraps the
image and refuses to publish rather than substituting. meshbench-20260904-e7196ef
is pinned, and the catalogue serves darwin/arm64:

Root: "Renode.app", Binary: "Renode.app/Contents/MacOS/renode", Magic: machARM64

Verified live, not read: MESHBENCH_LIVE=1 TestEveryPinnedAssetIsWhatTheCatalogueSaysItIs
downloads and hashes all nine pins, and the launcher is a real
Mach-O 64-bit arm64 executable.

So every emulator is now fetchable on all three platforms. The catalogue's
only remaining Unsupported entries are darwin/amd64 (no Intel build) and
linux/arm64 for QEMU (published, never exercised).

What is still open, and it is the verification half

3. No ESP32 board has been started on macOS, and no nRF52 board either. No
workflow does it, so nothing would notice if it broke. The catalogue offers
these rather than asserting them, and says so in a comment beside the row.

A new one, found while checking item 4. renode-support/ — our .repl
files and the C# peripherals Renode has not got — is copied into the tree
after the macOS compact image is cut:

platform	renode-support copied	compact cut	in compact?
Linux	line 200	231	yes
Windows	659	666	yes
macOS	456	393	no

SupportDir() looks beside the binary and then falls back to the tools
directory, which a fetch never populates with these. So a compact macOS build
can now fetch Renode and still not start an nRF52 board — exactly what item 4
warned about, and now reachable because the fetch works. It is not a regression
(macOS could not fetch Renode at all before), but it wants fixing before the
macOS compact build is offered as complete.