I have decided to stop providing sources to lutris. This changelog will stay for reference.
Your only option to build wine-tkg is now to manually use the PKGBUILDs. Have to say, this will hurt Lutris a lot, now lagging behind Wine Staging by quite a bit.
GloriousEggroll is making Faudio enabled Protonified Wine builds for Lutris though, but that means you’re forced to use Faudio with zero support, unlike base Proton which has Faudio tweaks to support it on more distros.
This is ge-faudio-protonified-4.9 if you’re curious:
They’re not lagging behind much and the reason TkG stepped in originally was because GE dropped out for a while. GE is using pretty much the same patches and continues to work on them.
Not sure what you mean with zero support regarding faudio tho?
Hmm, so GloriousEggroll is supposed to provide now that the TKG sources are no longer there? TKG builds had some excellent tweaks. I want those tweaks to carry forward to GloriousEggroll builds, not to start from scratch.
Proton is plug and play for Faudio. Lutris still has trouble with Faudio, and it’s easier to do winetricks xact and DLL overrides compared to dealing with Faudio dependencies.
GE and TkG always had similar patches in as I understand it, and the upcoming GE builds will also have faudio built in from what I can gather. They had some issues setting up the buildbot to work with faudio apparently. Though it seems they will have builds with and without faudio? Not sure about that.
That’s the problem, we’re in an uncertain time because what builds will they focus on? will they make specialized builds or make everything protonified? And keeping in mind EA anti-cheat (not EAC) has banned people without appeal while using protonified builds of Wine.
Also, ge-faudio-protonified has DXVK Async enabled, the thing that got many Overwatch players banned for a while.
As it says that patch is only enabled for Warframe. From discord:
Tarulia
@GloriousEggroll on your github repo it says “-DXVK Async patch applied and enabled specifically for warframe -Mech Warrior online patch”, does that mean it’s inactive for all other games? i.e. it checks for the warframe process?
GloriousEggroll
correct.
although i probably wont even use the patch in my new build
Generally, from what I can tell they try to not do specialised builds as far as possible (since it’s also hosting and bandwith costs for them), and instead cover what’s possible via settings in the installer script.
@GloriousEggroll The important builds that need to carry forward all have to do with Pulseaudio. A nopulse build or a osu build would be just enough to maintain. Pulseaudio over longer periods of play (longplays) seem to always have issues if there’s no “nopulse” build.
hi, it’s been a while since i logged in, but I took over builds after tkg stopped providing. I’m friends with him and we share patches frequently. Since then I’ve also implemented faudio into the lutris buildbot and we are regularly creating new builds with both faudio and custom patches used in both mine and tkgs external builds.
Cool! We’d lowe to see a thread about that! I’m sure many users may be worried about that change over, or may not be aware of it, and thinkxbad things may happen to lutris or some ridiculousness like that
No it isn’t on the Lutris builds. It’s compiled already for the PROTON GE builds, but not the GE builds for Lutris. It requires external dependencies on system libraries to work. Lutris’ buildbot assumes the USER has the shared library installed on the system. It doesn’t build Faudio for you.
Oh! I see… So Lutris sets environment variables properly for running their builds and simply replacing wine-staging in /opt doesn’t. That’s why I kept thinking this was required. So using a Lutris build of Wine in place of wine-staging will cause these issues. Lutris itself is unaffected.
What needs to happen is it has to be fully self contained where the references in the core of Wine can look to the lib directory within Wine rather than to the system lib directory, and does not require environment variable intervention from Lutris. (and can work regardless of the name of the Wine folder) That’s how Proton is setup. It looks to system libraries within itself rather than on in the system directories.
Yes, Lutris comes bundled with its own runtime (AFAIK derived from Ubuntu where they compile) to avoid weird issues related to different Lib versions, so it should “just work” for most systems/users.
You can turn those off if you know what you’re doing, but Lutris is meant for “the average joe”.
Yes that is certainly possible, but I assume this was done on purpose. There is one Lutris runtime installed alongside Lutris itself, that every Lutris-WINE build can then use, instead of having the libs for each version.
Proton is a little different because there’s only a handful versions, but Lutris has a ton of them at this point. I would imagine Valve switching to a similar model at some point, provided they don’t drop old Proton versions alltogether.
^at least this is all from what I gathered in the Discord over time.
Bumping to inform everyone that neither TKG nor GloriousEggroll are maintaining Lutris Wine builds anymore.
Instead, the new maintainer is Tannis Root, and it’s unsure how to directly get a hold of him for bug reports. You just have to pray he looks at the Lutris Discord.
Quote from GE:
I don’t give a fuck about Lutris Wine anymore. Ask Tannis Root. (He’s the reason I stopped caring about Lutris Wine)
Too bad, so sad. Means Lutris will miss out being first dibs on both Media Foundation fixes and EAC work.
You can download releases of these projects off their usual sources and drop them into the lutris / container folder that which I forgot the exact path to It’s in your ~user folder.
It’s in your ~user folder.