proton-wine (AndreVto builds)

Unofficial builds of Valve’s Proton 11.0 Wine, packaged for Android game launchers. 34 stars, 3 forks as of 2026-08-09 — the smallest number in this corpus by two orders of magnitude, and a bad guide to how much use the artifact gets. Built from ValveSoftware/wine’s proton_11.0 branch, published by a GitHub Actions bot at a cadence that is often daily; latest release build-proton_11.0b5-20260520-sdk35, dated 2026-05-20.

Two package flavours, both as WCP (Wine Container Package) files:

• Proton type, for GameNative — proton-11.0-1-x86_64.wcp, proton-11.0-1-arm64ec.wcp
• Wine type, for Winlator (CMOD and Ludashi variants) — proton-wine-11.0-1-x86_64.wcp.xz, proton-wine-11.0-1-arm64ec.wcp.xz

The repository’s own warning is unusually direct: “Caution: This version is provided for testing purposes only. It may lead to game instability or crashes. Use at your own risk.”

What the arm64ec target actually means

The interesting artifact here is the arm64ec build. The chain it completes is four layers deep: a Windows game, running on Wine, patched by Valve into Proton for Linux, rebuilt for ARM64 Windows emulation, running inside an Android launcher, on a phone. Each layer exists because someone declined to accept that software only runs where its publisher intended.

That makes this the corpus’s purest foss-application case in one specific sense — it is not an alternative to anything. There is no proprietary product it replaces and no vendor whose service it declines. It is compatibility work: making software run on hardware its author never targeted, which is a category openalternative‘s substitution taxonomy has no slot for, and evidence for the gap that page describes.

Redistribution as infrastructure

Nothing here is original code. The value added is entirely packaging and cadence — taking an upstream branch that changes constantly and turning it into a file two specific launchers can consume, several times a week, automatically. Thirty-four stars for a build service that a compatibility ecosystem depends on is the clearest illustration in this spoke of what a star count fails to measure.

The dependency chain is also the risk. The builds track a moving upstream, the targets are two third-party launchers with their own package expectations, the instability warning is the author’s own, and there is no test evidence of any kind — no compatibility list, no per-title results, nothing but the warning. For a project whose entire output is binaries other people execute, the provenance question (“what exactly is in this .wcp, and who compiled it”) is answered only by trusting the Actions workflow.

What is not established

• Licence. Wine is LGPL and Proton is a Valve fork of it; what these redistributed packages state about their own terms is not recorded in what was fetched, and it matters for a redistribution project.
• Relationship to upstream. Unofficial and unaffiliated, as far as anything here shows. Neither Valve nor the launcher projects are cited as endorsing the builds.
• Whether anyone verifies the builds. No signing, checksum practice or reproducibility claim is held here.

Connections

The only source in the corpus that runs someone else’s proprietary software rather than replacing it, and the reason this spoke’s boundary with ../game-engines-wiki is drawn where it is: engines that create games are that spoke’s, a runtime that executes one is this spoke’s. Compare ever-gauzy at the other extreme of the star-versus-substance question.