dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2282a7d521
FEnigma/packaging/windows
History
Dominik Roth 2282a7d521 packaging/windows: fix BTRFS+QEMU boot-loop, document what's confirmed 
Real issue hit on a real run: dockur/windows warns about BTRFS storage
but it's not idle -- on this host it boot-looped Windows Setup for
hours (same log lines repeating forever, disk barely growing), a known
bad combination for QEMU disk images on a copy-on-write filesystem.
build_windows.sh now disables COW on storage/ itself (chattr +C,
harmless no-op on non-btrfs or an already-populated dir from a prior
run). README updated to reflect both real fixes now confirmed needed
on this host (this one, plus the earlier SELinux :Z mount fix) instead
of the original "written but never run" status.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-11 21:16:24 +02:00
..
oem Fix id-namespace regression, add StrikeRequest type, kill full-panel 2026-08-11 20:48:57 +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 BTRFS+QEMU boot-loop, document what's confirmed 2026-08-11 21:16:24 +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.
  • BTRFS + QEMU disk images boot-loop Windows Setup for hours with no error, just the same boot-manager log lines repeating forever and the disk barely growing — dockur/windows warns about this itself ("you are using the BTRFS filesystem for /storage, this might introduce issues with Windows Setup!"), and on this host it wasn't idle chatter. Fixed by disabling copy-on-write on storage/ before the VM ever writes to it (chattr +C, only affects files created after it's set, so it needs an empty directory) — build_windows.sh now does this itself on every run. No-op on a non-btrfs filesystem.

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.