Repository: lutris/lutris

Issue:
Winetricks does not open
Winetricks does not open when you select it from the drop-down menu. But if you run lutris from the terminal using the lutris command, Winetricks opens when you select it from the dropdown menu.

Arch Linux
![image](https://user-images.githubusercontent.com/53097257/164336430-93c7eadb-1bdc-44c2-8fec-7a8182a0a9f2.png)



Discussion:
It seems to be related to the Lutris Runtime. I am experiencing this as well and disabling it [as stated on this older issue](https://github.com/lutris/lutris/issues/713), fixes the problem.

Being more specific, I am having this issue with zenity: 

```
 zenity: symbol lookup error: /usr/lib/libwebkit2gtk-4.0.so.37: undefined symbol: gst_codec_utils_caps_get_mime_codec
``
@italoghost you can run it winetricks as standalone and it works:
```bash
$ WINEPREFIX="path/to/wine/prefix" winetricks
```
Yes! As I said disabling Lutris Runtime fixes the issue. Using it through the terminal with standalone version works as well.

Probably there is another error in Lutris Runtime. Maybe something related to gtk-4.0?
> Yes! As I said disabling Lutris Runtime fixes the issue. Using it through the terminal with standalone version works as well.
>
> Probably there is another error in Lutris Runtime. Maybe something related to gtk-4.0?

Thank you, your answer helped! But I would like it to work all at once and not have to switch back and forth every time.
![image](https://user-images.githubusercontent.com/53097257/164550608-24e5015f-8e63-4d80-bfd4-9e0ff7a060e2.png)

> As I said disabling Lutris Runtime fixes the issue. 

No it does not. Having to disable the lutris runtime should never be treated as a solution. 
> No it does not. Having to disable the lutris runtime should never be treated as a solution.

Totally agree. The problem needs to be solved in lutris itself. By the way, it is strange that the Arch Linux repositories still have the old version 0.5.9.1.
> > As I said disabling Lutris Runtime fixes the issue.
> 
> No it does not. Having to disable the lutris runtime should never be treated as a solution.

Yes, I expressed it wrong. Sorry
> > > As I said disabling Lutris Runtime fixes the issue.
> > 
> > 
> > No it does not. Having to disable the lutris runtime should never be treated as a solution.
> 
> Yes, I expressed it wrong. Sorry

In any case, as a temporary solution it will do. It's much better than writing a command in the terminal every time.
> By the way, it is strange that the Arch Linux repositories still have the old version 0.5.9.1.

Thanks for giving me the hint I needed. I didn't even consider that the latest version isn't available there yet...

Since I updated Lutris manually to 0.5.10.1 I can play again without disabling Lutris Runtime. Nothing worked with it before, now everything seems to work **except for Winetricks**. But this time, no matter what I do, Lutris can't start it.

The `lutris.log` always say `[ERROR:2022-04-22 00:22:33,316:wine]: The game doesn't have an executable` when I try to start Winetricks.

Anyway, Winetricks doesn't seem to be up to date either. I get the following warning when I start it in the terminal `warning: You are running winetricks-20210206-next, latest upstream is winetricks-20220411!`. But I don't think that's the issue.
> > By the way, it is strange that the Arch Linux repositories still have the old version 0.5.9.1.
> 
> Thanks for giving me the hint I needed. I didn't even consider that the latest version isn't available there yet...
> 
> Since I updated Lutris manually to 0.5.10.1 I can play again without disabling Lutris Runtime. Nothing worked with it before, now everything seems to work **except for Winetricks**. But this time, no matter what I do, Lutris can't start it.
> 
> The `lutris.log` always say `[ERROR:2022-04-22 00:22:33,316:wine]: The game doesn't have an executable` when I try to start Winetricks.
> 
> Anyway, Winetricks doesn't seem to be up to date either. I get the following warning when I start it in the terminal `warning: You are running winetricks-20210206-next, latest upstream is winetricks-20220411!`. But I don't think that's the issue.

Apparently for this reason the new version has not yet appeared in the repository :)
Hi all,
In my case neither starting winetricks from the commandline nor disabling lutris runtime helps with the issue. Has anyone come up with some solution yet? 
I am also experiencing this issue (same error in the log) now that I have updated to Pop!_OS 22.04. Presumably they changed something about libwebkitgtk that winetricks cares about.

Disabling the Lutris runtime does nothing; neither does "Use system winetricks.". If I uncheck "Prefer system libraries" the error changes slightly:

```
zenity: symbol lookup error: /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_component_scroll_to
```

*But*, if I run my system's winetricks *from the command line*, that works.
if you want a shorter repro, export the LD_LIBRARY_PATH with the one used by Lutris and run `zenity`

![Screenshot from 2022-04-26 17-18-25](https://user-images.githubusercontent.com/280336/165413617-b1f84635-24ef-4611-97d1-55c55eb84205.png)


It's not the runtime, it's the Wine "lib" folders.
Those are the libraries causing issues with zenity (lib64 only)
![Screenshot from 2022-04-26 17-26-20](https://user-images.githubusercontent.com/280336/165414362-6f56d313-fe77-462b-afe4-0d6f5134142d.png)

So, I find that 'system winetricks' and 'disable runtime' do not work here because they don't completely disable the runtime and use the system libraries- LD_LIBRARY_PATH is still getting set. Here's a PR to fix that. With this PR either of those settings will make winetricks work on Pop!_OS 22.04.

However, the bug is not resolved really- the Lutris runtime should work too. Still working on that.
What is happening is that:
* The lutris runtime set `LD_LIBRARY_PATH` to some wine libs (including `libgst*.so`)
* winetricks calls `zenity`
* `zenity` is found in `PATH`, likely comes from the users's distro. This `zenity` is built with different (likely newer) versions of `libgst*.so`.
* This `zenity` cannot run with the wrong versions of `libgst*.so` that comes with wine, and therefore causes winetricks to crash.

To make things work without disabling lutris runtime, it's probably necessary to include a working version of `zenity` binary together with wine. After all, zenity is a dependency of winetricks so it makes sense to include.
Was having the issue with it not working because ->
`` zenity: symbol lookup error: /usr/lib/libwebkit2gtk-4.0.so.37: undefined symbol: gst_codec_utils_caps_get_mime_codec``
So I thought I'd search for a zenity fork and I found there is [zenity-light](https://aur.archlinux.org/packages/zenity-light) that doesn't use webkit, works just fine! Perhaps this could be bundled with lutris own winetricks?
That's an Arch package. How do we use that?
> Was having the issue with it not working because -> ` zenity: symbol lookup error: /usr/lib/libwebkit2gtk-4.0.so.37: undefined symbol: gst_codec_utils_caps_get_mime_codec` So I thought I'd search for a zenity fork and I found there is [zenity-light](https://aur.archlinux.org/packages/zenity-light) that doesn't use webkit, works just fine! Perhaps this could be bundled with lutris own winetricks?

Thanks a lot, that fixed the issue for me!
> Was having the issue with it not working because -> ` zenity: symbol lookup error: /usr/lib/libwebkit2gtk-4.0.so.37: undefined symbol: gst_codec_utils_caps_get_mime_codec` So I thought I'd search for a zenity fork and I found there is [zenity-light](https://aur.archlinux.org/packages/zenity-light) that doesn't use webkit, works just fine! Perhaps this could be bundled with lutris own winetricks?

Thanks, zenity-light fixes lutris winetricks problem and doesn't break steam-manjaro (as it depends on zenity)
> That's an Arch package. How do we use that?

If you have pacman you can clone the aur package (or use an aur helper), check for dependencies, then run  `makepkg -i`, otherwise go to the [upstream url](https://www.youtube.com/watch?v=ceK195PBXEo), clone it and it doesn't list meson or yelp-tools as dependencies but you will need them to build from source, once downloaded don't move into zenity directory and run `meson zenity build \                                                                                                                                                                      
    -D libnotify=true \
    -D webkitgtk=false
` then `meson compile -C build` and lastly `meson install -C build `
Has there been any progress in regards to this issue?
I have a clean install of Manjaro and I can confirm that Winetricks does not open if game has Lutris Runtime enabled. If I toggle the "Disable Lutris Runtime" option, then winetricks does start.
I fixed "Use System Winetricks" and "Disable Lutris Runtime" so they'd work for this case, but was not able to fix the runtime to work with zenity. I kinda lost steam somewhere around "build from source" there...
Jesus christ how can this not be fixed yet. This is a MAJOR issue that makes many programs not being able to run with wine/lutris. 
Feel free to fix it. I find it annoying and workarounds annoying also.
Can we experiment with shipping zenity-light in the runtime? By modifying $PATH, it should be possible to trick winetricks into using our bundled version as opposed to the system version.
We could. Though that 'upstream url' leads to youtube.

But one thing I never figured out: where's the runtime coming from? Is there a particular github repo that we'd update?
Runtime components are built from scripts stored here: https://github.com/lutris/buildbot
The actual "runtime" are 2 archives (1 for 32bit and 1 for 64bit) that contain libraries but other components are also considered part of the runtime (everything stored in .local/share/lutris/runtime)
The list of runtime components is maintained on the website: https://lutris.net/api/runtimes
Alternatively, would it be worth to consider making a new sub-menu or window that would be basically just a nice GUI for `winetricks -q` (makes winetricks run headless).
No zenity required that way. And such menu could contain a distilled set of all the options that winetricks provides, making it much more user friendly.
I don't think a new GUI would do; there are Lutris installer scripts that use winetricks, as I recall.
I'm not saying that GUI would replace whole winetrivks, just the user interface part.
The GUI would use winetricks exactly in the way that install scripts do.
When you run install script, it runs in a command-line mode, showing the output in the installer window.
Having a GUI that can execute the most common and relevant winetricks options would be better than having user troubleshoot zenity or use system terminal to manually use headless winetricks with some WINEPREFIX wizardry.
Yes, we did consider a solution like that where we collect all winetricks verbs used in Lutris scripts and group them in a list that we can display in a gui.
This would also probably be easier to understand for users since it would present them with a curated list of verbs. We can also consider adding a text input for free form entries.
We can also keep the same UI when we integrate with protontricks
Well, I've made a bit more progress. I managed a zenity build that works inside Lutris, but I need to place 'zenity' on the PATH (~/.local/bin worked for me) and zenity.ui at /usr/local/share/zenity/zenity.ui.

But I think I can work this. We can add a directory to the PATH before running wineexec, and it'll load zenity.ui from the current working directory ("for debugging")- so if winetricks can tolerate some random cwd, this can work! Testing this is promising.

There's a risk that in some weird way some installer will use winetricks and somehow depend on the cwd, but that seems marginal.

So, I'm thinking we can put zenitiy and zenity.ui into the winetricks directory, put that on the PATH and make it the cwd. Does that sound workable?

And if so, do we just commit to an amd64 architecture or is there some way to make 32-bit work?
Hmmm. There's also issue #4285, where the League of Legends installer sets up a pre-launch script that uses zenity.

Should we try to get it to use a Lutris specific zenity somehow?

I trust this sort of thing is not common.
We did something like that with the 'network-tools' runtime component where utilities like curl and wget are shipped in our runtime. 
bth, I'm not sure those are even used currently but it would be the same mechanism.
In this case, something like ~/.local/share/lutris/runtime/zenity/bin should be added to PATH.
Just when I thought I was figuring out buildbot! network-tools must be in there somewhere, I 'spose.

I'd like to not depend on the CWD, as it won't work for the little .pngs in zenity. It looks like you can build with a custom path for these data files, but that path is compiled into the program, and I don't think it resolves environment variables or anything. Not sure how to use that.
In order to benefit from Github hosting, we also have forks of multiple projects on our github account. 
The network-tools is nowhere to be seen so it might not even be a thing anymore. 
I did add this repo yesterday: https://github.com/lutris/dxvk-cache-tool which we now ship in the runtime.
I was not thinking I would maintain a fork of zenity.

It looks to me like the buildbot scripts grab a repository, builds it, and packages the output. That would be a lower maintenance way to get our own zenity, if all we needed was some build options to be set.
The fork is only to benefit of github hosting. You do not have to maintain anything whatsoever.
I'm looking at it, and I don't get it.

How does dxvk-cache-tool ever wind up on the client? As far as I can see it's not referred to anywhere. I expected buildbot to have a script to package it or something.

For reference, the zenity repo is [https://gitlab.gnome.org/GNOME/zenity](https://gitlab.gnome.org/GNOME/zenity)

For dxvk-cache-tool, I just built the project locally, put that in an archive and uploaded that to a github release.
It would be preferable to have a script for it in buildbot but that's not the case yet. Before that, we were serving a 2019 build as a download in the overwatch script.

One of the problems with the scripts in buildbot is that they don't integrate with github yet, only the Lutris website (slow) or Digital Ocean (expensive)

It looks to me like if we *don't* fork the thing and upgrade it, we'll get limited functionality. Winetricks will work, but zenity won't work from a pre-launch script (League of Legends does this). Lutris sets up a PATH and CWD and we provide zenity and zenity.ui in the runtime somewhere.

If we do upgrade zenity to understand environment variables in a few places, we'll be maintaining a fork, but we can make it work anywhere we can get an update PATH. No need to molest the CWD then. We would ship a bunch of .pngs with it also.

The problem is that zenity has a compiled in full-path that indicates where its data-files are. I can't see how to point this at our runtime directory since I don't know the user's home directory path at compile time. I see no dynamic way to control this.

I expect I can write a build.sh for this thing, too, but not test it realistically.
The more complicated this gets, the more I think we should just go with our own GUI. 

The LoL installer shouldn't use Zenity. This is a hack done because people don't want to ask for features to be implemented into Lutris. There are many hacks in the Lutris installers that now have to be cleaned up. 
I don't think it's a good idea to build a product around these hacks, I find it better to implement the feature properly and get rid of the hack (like I did for the shader cache and Overwatch)

OK, that's clear. I think I should try to do the zenity hack to get wintricks working for 0.5.12. I'll try to include it inside of winetricks, since it is only for that.

That seems to me to be the minimal thing to get over the hump here.

Resolving patch:
diff --git a/lutris/runners/commands/wine.py b/lutris/runners/commands/wine.py
--- a/lutris/runners/commands/wine.py
+++ b/lutris/runners/commands/wine.py
@@ -342,8 +342,21 @@ def winetricks(
     winetricks_path = os.path.join(settings.RUNTIME_DIR, "winetricks/winetricks")
     if system_winetricks or not system.path_exists(winetricks_path):
         winetricks_path = system.find_executable("winetricks")
+        working_dir = None
         if not winetricks_path:
             raise RuntimeError("No installation of winetricks found")
+    else:
+        # We will use our own zentiy if available, which is here and it
+        # also needs a data file in this directory. We have to set the
+        # working_dir so it will find the data file.
+        working_dir = os.path.join(settings.RUNTIME_DIR, "winetricks")
+
+        if not env:
+            env = {}
+
+        path = env.get("PATH", os.environ["PATH"])
+        env["PATH"] = "%s:%s" % (working_dir, path)
+
     if wine_path:
         winetricks_wine = wine_path
     else:
@@ -355,11 +368,13 @@ def winetricks(
     args = app
     if str(silent).lower() in ("yes", "on", "true"):
         args = "--unattended " + args
+
     return wineexec(
         None,
         prefix=prefix,
         winetricks_wine=winetricks_wine,
         wine_path=winetricks_path,
+        working_dir=working_dir,
         arch=arch,
         args=args,
         config=config,


Test patch: