wine-tkg-git: build your own patched Wine and Proton

A build system, not a fork

wine-tkg-git is a build system for creating custom Wine builds and custom Proton builds, and the distinction matters for how you use it. The repository does not carry a modified copy of Wine. It carries the machinery that fetches the sources, applies a patch selection, and produces a build.

The project's own description of the goal is the plain wine plus pba plus steam fix build that you can now easily get, and it makes custom Proton builds with a wrapping script in the proton-tkg directory.

By default it pulls the current wine and wine-staging git versions, so the build tracks upstream rather than tracking a released tarball. The alternative is stated plainly: you can target a specific release or commit in the .cfg if needed. That is the main reason to use a build system at all here, because pinning a commit and then rebuilding it six months later is not something a distribution package gives you.

The repository is a shell project, with a wine-tkg-git/ directory holding the build system itself and a proton-tkg/ directory holding the Proton wrapper, and a .github/ directory carrying the CI workflows that produce the nightly builds. There is no homepage listed, the licence is not stated in the repository metadata, and the last push was on 2026-09-30.

The vocabulary in the name is worth decoding once. The tkg suffix is the project's own naming, and the git suffix distinguishes this from the generated sources it consumes.

The config file is the user interface

Everything you choose lives in a.cfg file, and the documentation points at a sample external config that lists the full set of options with details.

A comfortable selection of patches is available, with some of them enabled by default for convenience, and the sample config file is the reference for the complete list. So the workflow is to copy the sample, edit it, and run the build, and the defaults are chosen so that a first run produces something useful rather than a bare upstream build.

The patches come from three places. The first is the set built into the build system, which covers the common fixes including the Steam-related ones. The second is the community-patches repository, described as an ever evolving selection of staging, experimental and hacky patches, which is where the interesting and unstable work lives. The third is your own, since the project documents how to build with your own patches in the README in the wine-tkg-git/wine-tkg-userpatches directory.

The split between the built-in set and the community set is a useful one to understand before you start. The built-in patches are what the maintainers are confident in, and the community ones are the experimental surface where you read the patch before you enable it. A third category, the hacky ones, is explicitly labelled as such.

The fact that the config is a separate file rather than command line flags is what makes the build repeatable. A.cfg can be committed next to your project, and everyone who builds gets the same result, which is the only sensible way to run a build that applies many patches to a moving upstream.

The upstream sources it assembles

The README lists the generated sources and the upstreams they come from, and the list is effectively a map of the Wine ecosystem's forks.

The generated Wine-tkg sources are the Tk-Glitch wine-tkg and wine-proton-tkg projects, which are the generated outputs of this build system. The upstreams are wine-mirror/wine for the main tree, wine-staging/wine-staging for the staging branch, the zfigura esync and fsync branches of Wine for the synchronisation primitives, and ValveSoftware/Proton for the Proton tree itself.

Wine-pba is included but with a significant caveat attached: it is only working correctly up to 3.18 and is force disabled on newer Wine bases due to regressions. The project also credits the rebase work by Firerat and bobwya, pointing at a GitLab fork of wine-pba and a Gentoo version of it, which is the kind of credit that tells you how much patching effort sits behind that one component.

The Gallium 9 note is a good example of a project documenting when to stop. For Gallium 9 support, use wine-nine-standalone, which is available from winetricks and the AUR, and the legacy nine support can still be turned on if you are building a 4.1 base or older.

So the picture is a toolchain that composes upstream Wine, a staging patchset, alternative synchronisation branches, an optional preloading patch and a set of community modifications, with the guidance to drop the parts that no longer apply as the base moves.

Nightly builds across four CI matrices

The project runs GitHub Actions workflows that produce nightly builds, and the README lists them per distribution, which is the practical entry point for most people.

For Wine there are three: Arch Linux, Fedora and Ubuntu. The Wine nightly builds have the wine-staging patchset applied and ntsync support added as needed. Then there is Valve Wine, with two variants, the Exp Bleeding Edge build for Arch Linux via a pacman workflow and the Exp Bleeding Edge build for other distributions. The documentation notes that the other-distro versions are built on Ubuntu latest, which should work fine on most distros not using years old packages.

The Proton side has two: Valve Exp Bleeding Edge, built against the sniper container, and Wine Master in what the README calls the hit or miss edition, built against Arch current, which makes glibc 2.42 or newer a requirement.

That glibc requirement is the line to read carefully if you are on an older distribution. A Proton build linked against a very new glibc will not run on a system with an older one, so the Wine Master Proton build is effectively a rolling distribution experiment rather than something to install everywhere. The Arch, Fedora and Ubuntu Wine nightlies are the more broadly usable artefacts.

There is one access condition that catches people out, and it is the first line of the README. You must be logged in to GitHub in order to download Wine or Proton nightly builds.

Where a Proton build goes, and where to file bugs

Installing a downloaded Proton build is a matter of putting it in the right directory. The extracted folder goes in $HOME/.steam/root/compatibilitytools.d/, or, for Ubuntu and Debian based systems, in $HOME/.steam/compatibilitytools.d/. Steam then treats it as a compatibility tool that can be selected like any other Proton version.

The other operational instruction in the README is all capitals, and it exists because a very large number of people do not read it. Please do not report bugs encountered with this at WineHQ or Valve Software, report them here instead.

That is worth pausing on, because it identifies a boundary. A custom build is not the distribution's build, and a bug report filed upstream describes a configuration that upstream does not ship, so it generates noise for maintainers who cannot reproduce it. The same applies to Valve Software for the Proton variants, since a patched build is not the one they ship.

The same reasoning applies to a bug in the patched build itself: if the patch introduces a regression, that is a bug in this project or in the upstream it tracks, not in Wine, and the correct destination is the issue tracker here. A project that maintains a large patch set needs its users to route problems to the right place, because the alternative is a stream of upstream reports that cannot be actioned.

The build system and the CI artifacts are the two halves of the project's offering, and the two halves have different audiences. The CI builds are for users who want a patched binary now, and the build system is for users who need a configuration that the CI matrix does not produce.

Releases mostly replaced by CI

The release history is unusual and the newest tag explains why.

The tag 7.x+ from 2022-07-13 is titled, in full, Prebuilt releases mostly replaced by CI. That single line is the project's statement of how it now distributes binaries, and it is the reason the two older tags look the way they do. Before that, releases were named with the Wine version and the git describe output, so 7.6.r12.g51472395 from 2022-04-19 covers both wine-tkg and proton-tkg at that state, and 6.17.r0.g5f19a815 from 2021-09-11 is the same for the 6.17 series.

The practical consequence is that the tags are a historical record rather than an index of what you can download today. The nightly artifacts live in the CI workflow runs, not in the release list, which is why the README links to the workflow pages for each distribution rather than to a releases page.

The last push was on 2026-09-30, which is recent enough to say the project is still being worked on, even though the tag list stops in 2022. The repository is not archived, and the directory layout has stayed simple, with the build system in wine-tkg-git/ and the Proton wrapper in proton-tkg/, plus a .dir-locals.el for Emacs users.

The licence is the one gap in the documentation. The repository metadata does not state a licence, and the README does not have a licence section, so if you intend to redistribute a build produced with the tool, or to contribute patches back, confirm the terms with the maintainers first.

Editorial conclusion

Adopt wine-tkg-git if you need a Wine or Proton build with a specific patch set, a specific upstream commit, or a base that no distribution ships, and you are prepared to maintain a toolchain yourself. Do not adopt it if you simply want Proton to work, since the official builds already cover the common case, and do not expect the prebuilt releases to be the main distribution channel, because the project's own tag says prebuilt releases are mostly replaced by CI. Before you start, read the sample external config to see which patches are on by default, and remember that the Wine-pba patch is force-disabled on newer bases because of regressions, and that a Proton master build against Arch current needs glibc 2.42 or newer.

Frequently asked questions

Official sources

1. Frogging-Family/wine-tkg-git on GitHub
2. Issues
3. README
4. Releases