enricobuehler
0bfc7fe913
apple / swift (pull_request) Successful in 1m43s
apple / distribute (pull_request) Skipped
apple / screenshots (pull_request) Skipped
windows-drivers / probe-and-proto (pull_request) Successful in 30s
windows-drivers / driver-build (pull_request) Successful in 1m49s
ci / docs-site (pull_request) Successful in 1m21s
ci / bun-nix (pull_request) Successful in 31s
ci / web (pull_request) Successful in 3m50s
ci / rust-arm64 (pull_request) Successful in 8m32s
android / android (pull_request) Successful in 7m22s
ci / rust (pull_request) Successful in 14m7s
windows-client / client (arm64, --no-default-features, aarch64-pc-windows-msvc, C:\t-a64) (pull_request) Successful in 3m6s
windows-client / client (x64, , x86_64-pc-windows-msvc, C:\t) (pull_request) Successful in 8m7s
Two merges, both of which exist to express an ordering Gitea cannot express across files, and both of which delete a duplicated build. release.yml -> apple.yml (as the `distribute` job) The name described neither what it did (Apple only — every other platform's release is its own packaging workflow attaching to the same Gitea release on a v* tag, with announce.yml as the manual "go") nor anything a reader would guess. The name was the smaller problem. Gitea has no cross-workflow `needs`, so nothing sequenced it against apple.yml's tests: a canary main push uploaded iOS, macOS and tvOS builds to TestFlight even when `swift test` had just failed on that same commit. It is now `needs: swift`, which is only expressible in one file. The two files' paths: filters had also drifted — apple.yml watched crates/**, release.yml watched crates/punktfunk-core/**. The merged filter takes the NARROW one, because that is the correct one: everything on this runner is built from punktfunk-core via build-xcframework.sh, and punktfunk-core's only path dependency is its own vendored fec-rs. That is checkable in one command, and the header says so, and says to widen it if that ever stops being true. Net effect on the shared mac mini: pushes that touch host-side crates no longer build or upload anything Apple. windows.yml + windows-msix.yml -> windows-client.yml The pair built the same three crates FOUR times per client push on ONE runner: debug x64 + arm64 for lint/test, release x64 + arm64 for packaging. windows-host.yml already records why a second (debug) dep tree on this machine is a liability rather than a cost — it re-runs openh264-sys2's vendored C++ through cc-rs's cl.exe fan-out and tips the runner into C1069, which is disk exhaustion wearing a compiler error's clothes. So there is one release build per arch now and clippy/fmt/test run against it, exactly as windows-host.yml does. The paths list went from three copies to one; PRs get the build/lint/test signal and stop before packaging. The rename is safe, and this is worth recording because the GitHub instinct is wrong here: `github.run_number` is REPO-WIDE in Gitea, not per-workflow — consecutive runs of DIFFERENT workflows get consecutive numbers (verified against the API: android 13226, apple 13227, arch 13228, ci 13229, deb 13230). The canary MSIX version <minor>.<run>.0 and Apple's CURRENT_PROJECT_VERSION therefore keep climbing across a rename. On GitHub the same rename would reset both to 1, sorting every new canary below the published ones and getting the TestFlight uploads rejected outright. 25 workflows, down from 27, and every `name:` now matches its filename. Cross-references in windows-host.yml, windows-drivers.yml, android.yml, flatpak.yml, sbom.yml, the provisioning scripts, gitea-release.sh and clients/windows/packaging/README.md updated.
107 lines
6.7 KiB
Markdown
107 lines
6.7 KiB
Markdown
# punktfunk Windows client — MSIX packaging
|
|
|
|
The Windows client ships as **signed MSIX** packages so Windows boxes get a real package (Start
|
|
tile, clean install/uninstall) instead of a loose exe. CI builds + publishes them from
|
|
[`.gitea/workflows/windows-client.yml`](../../../.gitea/workflows/windows-client.yml) to Gitea's
|
|
**generic** package registry (`https://git.unom.io/unom/-/packages`), on every `main` push that
|
|
touches the client (canary) and on `vX.Y.Z` release tags (stable) — see
|
|
[Release Channels](https://punktfunk.unom.io/docs/channels).
|
|
|
|
**Two architectures, one x64 runner.** Both `x64` and `arm64` packages are produced off the single
|
|
x64 Windows runner — `x86_64-pc-windows-msvc` builds natively, `aarch64-pc-windows-msvc` is
|
|
cross-compiled (the x64 MSVC toolset ships the ARM64 cross compiler; since M10 nothing in the
|
|
package links FFmpeg, so neither arch needs a per-arch `FFMPEG_DIR` tree staged on the runner —
|
|
one less thing the ARM64 leg can be missing). Artifacts are arch-suffixed
|
|
(`..._x64.msix` / `..._arm64.msix`, each with its matching `.cer`); `pack-msix.ps1 -Arch x64|arm64`
|
|
stamps the manifest `ProcessorArchitecture` and names the output. See
|
|
[`windows-client.yml`](../../../.gitea/workflows/windows-client.yml) for the cross-build rationale.
|
|
|
|
## What's in the package
|
|
|
|
`pack-msix.ps1` assembles a layout from a `cargo build --release` and runs `makeappx` + `signtool`:
|
|
|
|
| File | Source |
|
|
|---|---|
|
|
| `punktfunk-client.exe` | the release build (the WinUI shell) |
|
|
| `punktfunk-session.exe` | the release build — the Vulkan session client the shell spawns for every stream (sibling resolution, `src/spawn.rs`). Skia links statically; `vulkan-1.dll` is a GPU-driver component, never bundled. ARM64 builds it `--no-default-features` (no Skia console UI) until rust-skia ships aarch64-pc-windows-msvc prebuilts |
|
|
| `Microsoft.WindowsAppRuntime.Bootstrap.dll`, `resources.pri` | staged by the client's `build.rs` via `windows-reactor-setup::as_framework_dependent()` |
|
|
| `SDL3.dll` | auto-staged by the `sdl3` crate |
|
|
| `licenses\*` | the project's MIT/Apache texts + the generated `THIRD-PARTY-NOTICES.txt` (MSIX has no installer EULA page, so attribution ships as files) |
|
|
| `Assets\*.png` | checked-in tile/store logos (rasterized from `packaging/flatpak/io.unom.Punktfunk.svg`) |
|
|
| `AppxManifest.xml` | the template here, with `{VERSION}`/`{PUBLISHER}` substituted |
|
|
|
|
**No FFmpeg DLLs.** The client decodes natively since M10 (`pf-vkdecode` / `pf-dxvadec` /
|
|
OpenH264+rav1d — punktfunk-planning `design/client-native-decode.md` §6), so nothing here
|
|
link-imports `libav*` and the wildcard `avcodec/avformat/avutil/swscale/swresample-*.dll` copy is
|
|
gone, along with the FFmpeg LGPL notice that accompanied it — shipping that notice now would claim
|
|
a dependency the package doesn't have. The **host** installer is unchanged:
|
|
`packaging/windows/pack-host-installer.ps1` still ships those DLLs for its AMF/QSV encode path.
|
|
|
|
### Why an "unpackaged" WinUI app packages cleanly
|
|
|
|
`main` calls `windows_reactor::bootstrap()`, which runs `MddBootstrapInitialize2` with
|
|
`OnPackageIdentity_NOOP` (`crates/libs/reactor/src/bootstrap.rs`), so under MSIX **package
|
|
identity** the App SDK bootstrapper is a no-op and the runtime is resolved from the manifest's
|
|
`<PackageDependency>` on `Microsoft.WindowsAppRuntime.2` instead (reactor pins
|
|
`WINDOWSAPPSDK_RELEASE_MAJORMINOR = 0x20000` = 2.0). It's a full-trust Win32 app
|
|
(`EntryPoint="Windows.FullTrustApplication"` + `runFullTrust`) because it owns raw D3D11, Win32
|
|
low-level input hooks, WASAPI and SDL3.
|
|
|
|
## Versioning
|
|
|
|
MSIX requires a strictly 4-part numeric version. The workflow computes:
|
|
- `vX.Y.Z` tag → `X.Y.Z.0` (THE release; any `-rc`/`+meta` suffix is dropped for MSIX). Published to
|
|
the stable `latest/` alias and attached to the unified Gitea Release.
|
|
- `main` push / `workflow_dispatch` → `0.3.<run_number>.0` (canary, climbs by run number; `canary/` alias).
|
|
|
|
## Signing & install
|
|
|
|
CI signs every build with a **stable self-signed code-signing cert** (`CN=unom`, SHA-1
|
|
`CD1EFDEEEC9743AFC38F56C5AF30C5A3009BE941`, valid to 2036). Its public half is checked in as
|
|
[`punktfunk-codesign.cer`](punktfunk-codesign.cer); the private `.pfx` + password live in the
|
|
`MSIX_CERT_PFX_B64` / `MSIX_CERT_PASSWORD` Actions secrets. Because it's the *same* cert every build,
|
|
trusting it is **one-time, per machine** — once imported, every future build and in-place upgrade is
|
|
trusted with no further prompt:
|
|
|
|
```powershell
|
|
# once per machine (elevated): trust the publisher
|
|
Import-Certificate -FilePath .\punktfunk-codesign.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople
|
|
# then install the package for your CPU (and re-run for each upgrade — no re-trust needed)
|
|
Add-AppxPackage -Path .\punktfunk-client-windows_<ver>_x64.msix # Intel/AMD
|
|
Add-AppxPackage -Path .\punktfunk-client-windows_<ver>_arm64.msix # ARM64 (Snapdragon, etc.)
|
|
```
|
|
|
|
The matching `.cer` is also published next to each `.msix` in the registry, so it's always at hand.
|
|
|
|
The MSIX declares a dependency on the Windows App SDK 2.x runtime; install
|
|
[the App SDK runtime](https://aka.ms/windowsappsdk) if `Add-AppxPackage` reports a missing
|
|
`Microsoft.WindowsAppRuntime.2` framework.
|
|
|
|
`pack-msix.ps1` signing precedence: it uses the **`MSIX_CERT_PFX_B64` / `MSIX_CERT_PASSWORD`** secrets
|
|
when present (the stable cert above), else generates an *ephemeral* self-signed cert (forks / local
|
|
builds without the secrets). Either way it exports the signing cert's public `.cer` for the import.
|
|
**To move to a publicly-trusted (no-import) cert** — Azure Artifact Signing or a public OV cert —
|
|
replace the two secrets with the new `.pfx`; the cert's subject DN must equal the manifest
|
|
`Publisher`, so pass a matching `-Publisher` (it's stamped into the package `Identity`, and changing
|
|
it changes the package identity → a one-time reinstall).
|
|
|
|
## Building locally
|
|
|
|
On the Windows runner / dev VM (MSVC + Windows SDK present), after a release build:
|
|
|
|
```powershell
|
|
# x64
|
|
cargo build --release -p punktfunk-client-windows --target x86_64-pc-windows-msvc
|
|
pwsh -File clients/windows/packaging/pack-msix.ps1 `
|
|
-Version 0.2.0.0 -TargetDir C:\t\x86_64-pc-windows-msvc\release -OutDir C:\t\msix
|
|
|
|
# arm64 (cross-compiled; no extra environment — the client links no FFmpeg)
|
|
cargo build --release -p punktfunk-client-windows --target aarch64-pc-windows-msvc
|
|
pwsh -File clients/windows/packaging/pack-msix.ps1 `
|
|
-Version 0.2.0.0 -Arch arm64 -TargetDir C:\t\aarch64-pc-windows-msvc\release -OutDir C:\t\msix
|
|
```
|
|
|
|
Validated end-to-end on the build VM (pack → sign → `Add-AppxPackage` → framework-dependency
|
|
resolution). The only step that needs a real display is *launching* the WinUI window (same
|
|
on-glass constraint as the rest of the client).
|