dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
6a61bffb22
FEnigma/packaging/windows
History
Dominik Roth 6a61bffb22 Fix taking-fire ally misclassification; Windows build fixes; Field Gun 
OCR (src/fenigma/ocr.py):
- A "taking fire" report's reporting unit was added as a hostile Target,
  not a friendly Ally -- no "Friendly"/"Hostile" prefix word exists in
  that grammar for the usual inference to key off of, so it silently
  defaulted to not-ally. Fixed with an explicit force_ally override
  (_TAKING_FIRE_RE), and the shell/deadline (which an Ally tuple has no
  fields for) now always splits into a synthetic StrikeRequest target at
  the reporting position, even for the no-offset "on our position" case
  that previously kept them on the entity itself.
- "Enemy <Type>#<id> Destroyed" kill-feed lines were silently dropping
  for shorter/less distinctive type words (e.g. "Enemy Field Gun#1") --
  _ALLY_PREFIX_RE only ever stripped "Friendly"/"Hostile", never
  "Enemy", so the whole "EnemyFieldGun" token got alias/fuzzy-matched
  against "Artillery" and missed by a mile. Longer type words
  ("Enemy Mechanized Infantry#2") only ever worked by fuzzy-match
  accident. Now strips "Enemy" too (lookahead guards a BARE "Enemy#N"
  report, which IS TargetType.ENEMY itself, from being stripped to an
  empty, unresolvable string).
- "Field Gun" added to _TYPE_WORD_ALIASES as plain Artillery under
  another name (confirmed by the user), not a missing unit type.
7 new/updated regression tests, 54 total passing.

Windows build (packaging/windows/): three real bugs found and fixed by
actually booting and driving the build VM live (VNC), not just guessing
from the README's "UNTESTED end to end" note:
- install.bat's MSYS2/WiX provisioning previously left NOTHING behind
  once C:\OEM stopped existing (a 2-day-old BUILD_REQUEST sat unclaimed
  the whole time) -- the build.bat/watch_build.bat persistence fix
  (C:\FenigmaBuild instead of C:\OEM) is real and now confirmed live:
  after a full container restart, the watcher auto-starts on login and
  picks up a pending request with zero manual intervention.
- pip install pytesseract needs --break-system-packages (MSYS2's
  mingw64 Python enforces PEP 668).
- mingw-w64-x86_64-opencv is the C++ library only; the actual Python
  bindings are the separate mingw-w64-x86_64-python-opencv package,
  never in install.bat's dependency list.

With all three, import fenigma.app succeeds and a real build attempt
gets through source copy, sanity check, dist-tree assembly, and WiX
harvest+compile -- further than this pipeline has ever gotten. Full
findings, including the still-open light.exe timeout and the OCR
multi-shell/deadline-phrasing/phantom-header gaps found along the way,
logged in TODO.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-13 22:02:17 +02:00
..
oem Fix taking-fire ally misclassification; Windows build fixes; Field Gun 2026-08-13 22:02:17 +02:00
build_windows.sh packaging/windows: fix BTRFS+QEMU boot-loop, document what's confirmed 2026-08-11 21:16:24 +02:00
docker-compose.yml Fix id-namespace regression, add StrikeRequest type, kill full-panel 2026-08-11 20:48:57 +02:00
README.md packaging/windows: fix build watcher never firing, correct earlier 2026-08-12 11:57:28 +02:00

README.md

Windows .msi build (via dockur/windows)

Builds a Windows installer for FEnigma on a Linux host with no Windows machine and no GitHub, by booting a real Windows VM inside a container (dockur/windows, QEMU+KVM under the hood, no license key needed for the eval install it fetches automatically) and driving the whole build over a shared folder.

Status: has actually been run. Two real environment issues hit and fixed so far (both already applied in this directory, see "Confirmed issues hit" below); Windows install itself was still in progress as of last check. oem/install.bat onward (MSYS2/GTK4/WiX provisioning, the actual .msi packaging) has NOT been reached/exercised yet — treat that part as still a debugging session, not a push-button success. Watch it happen at http://localhost:8006 (dockur's noVNC viewer) if it stalls.

Confirmed issues hit (on Fedora + BTRFS)

  • SELinux blocks the bind mounts ("Storage folder (/storage) is not writeable!") — fixed with :Z on every volume in docker-compose.yml. Harmless no-op on a host without SELinux.
  • The repeated "loading/starting Boot0004" log lines are NOT a boot loop — that was an earlier misdiagnosis here (blamed on BTRFS+QEMU, "fixed" with chattr +C on storage/). Checked the actual noVNC screen instead of just the text log and it was genuine, progressing Windows Setup the whole time ("This might take a few minutes" → "Please keep your PC on and plugged in" → desktop) — Setup legitimately reboots the VM multiple times, each one re-prints those same firmware log lines. The chattr +C disables copy-on-write for the VM's disk image regardless (a real, independently-documented dockur/QEMU/BTRFS caveat), so it's staying, but it likely wasn't fixing an actual problem this time. Lesson: check the screen, not just the log, before concluding something's stuck.
  • The build watcher registered as a SYSTEM-context Scheduled Task never fires in practice: Z:\ (the /shared mount) is mapped per interactive session, invisible to a task with no session of its own, so it spun forever on watch_build.bat's own if not exist Z:\ wait — confirmed by a build request sitting unclaimed for hours. Fixed in install.bat: an All-Users Startup-folder entry instead, which runs in whichever user's session actually logs in.

How it fits together

  • docker-compose.yml — boots the VM. Needs /dev/kvm on the host.
  • oem/install.bat — one-time provisioning, auto-run by Windows's own unattended setup on first boot (dockur/windows's /oem mechanism): installs MSYS2, then GTK4/libadwaita/PyGObject/numpy/Pillow/OpenCV/ Tesseract through it, plus the WiX v3 toolset, and registers a boot-time watcher task. This is the slow part (Windows install itself, then package downloads) and only ever happens once — it lives on the VM's persistent disk (./storage, gitignored) from then on.
  • oem/watch_build.bat — runs at every boot from here on, polls the shared Z:\ drive for a build request.
  • oem/build.bat — the actual per-build packaging: assembles a dist tree (bundled MSYS2 mingw64 runtime + the fenigma package), harvests it into WiX components with heat.exe, and links it into an .msi with candle.exe/light.exe.
  • oem/product.wxs — the hand-authored shell around that harvested file list: install directory, Start Menu shortcut, and the PYTHONPATH environment variable the shortcut needs (mirrors run.sh's PYTHONPATH=src python -m fenigma.app).
  • build_windows.sh — run this. Starts the VM, copies ../../src onto the shared folder, drops a request file, waits for the .msi to come back, copies it to ../../dist-windows/.

Running it

cd packaging/windows
./build_windows.sh [version]

First run: full unattended Windows install + provisioning, likely 30-90 minutes, unattended (no interaction needed, but it needs to actually finish — don't kill it early). Every run after that: just boot the already-provisioned VM and build, a few minutes.

Requires /dev/kvm (virtualization enabled, your user in the kvm group) and Docker with Compose.

Known rough edges / likely follow-up work

  • The dist tree is fat, not lean. build.bat bulk-copies the entire mingw64/ runtime rather than tracing the actual DLL/typelib/icon- theme/schema dependency closure of the app — reliable, but probably 1GB+. Trimming it (e.g. by walking pythonw.exe's and the compiled extension modules' actual dependencies) is a real but separate project.
  • heat.exe's default harvest options are a starting guess for a tree this large and this GTK-specific (icon caches, gschemas, typelibs); it may need -t transforms or manual exclusions to produce a working component set.
  • Not tested against a real GTK4/libadwaita Windows install at all — MSYS2 ships these, but this is the first time this specific app has been pointed at them; expect a missing-DLL or schema error on first actual launch, not just a packaging error.
  • No code signing — Windows will show an "unknown publisher" warning.