Miserable first experience: Grim Dawn install script fails to execute installer

[steve_v]

Long-time GNU/Linux and wine user, first-time Lutris user. (convert from PlayOnLinux)

Already pretty irritated at having to install pulseaudio due to #2651 (tried to link the issue for clarity, but: “Sorry, new users can only insert two links…” GRRR!), and with the painfully slow and GNOME-braindamage ugly UI. I can deal with these, but it’s not helping.
The real showstopper is as follows:

Clicked “install” on Grim Dawn (the only game I currently play in wine) imported from GOG account, selected “GOG /w DXVK”.
Got lengthy download progress.
Got a bunch of terminal output from winetricks etc.
Got “The executable at path /home/steve/Games/grim-dawn/drive_c/GOG Games/Grim Dawn/Grim Dawn.exe can’t be found, please check the destination folder.
Some parts of the installation process may have not completed successfully.”

It doesn’t look like lutris even attempted to execute the installer it spent over an hour downloading.
Nope, not even a mention of the game installer executable in the log. Nada. Nothing. Just a “Huh, I can’t find the thing I didn’t install, derp derp.”

Here I was thinking this would be a convenient alternative to PlayOnLinux…

“–report-issue” output.

Debug STDOUT output (auth data redacted).

Yes, I’m being snarky and impatient. Sorry. It happens this late at night.
The lutris website promotes it as an easy to use one-click installer and the Grim Dawn script is presented as the same, so that’s what I was expecting. Not something more difficult to deal with than a manual wine install. This forum is also infuriating to use, but that’s off topic.

Suggestions?

Ed. Installed game manually. Tried to launch. Got expected complaint about limits because I forgot that it enabled esync…
And the Lutris UI completely locks up with “Launching”, forever, including the close button on the window. Requires me to kill it’s process… The mind boggles.
Lutris has been around for a while, I’d have thought that really basement-level stuff like this would be working in a normal-application fashion by now. First impressions are getting better and better.

Ed. Some of my GOG games are apparently invisible in the library list as well. To pick one of many: X4: Foundations shows up in the import games list, trying to import it results in “1 game already in library”, and yet neither the mk.1 eyeball nor the search function reveal it in the library list. The saga continues…

Presumably this means that a) Games that Lutris can’t automatically download aren’t shown in the library (confusing) and b) Lutris claims to be able to download and install games when it can’t (broken).

Does anyone have any solutions for these problems or should I just go back to doing things by hand and having it work?

Ed. Tried Lutris from git master, seeing the GOG download issue apparently fixed…
Aaaaand the GOG login barfs with: “OSError: invalid Netscape format cookies file ‘/tmp/steve/.cache/lutris/.gog.auth’”
Yes, I cleared the auth cookies first.
Broken. Broken broken broken.

Guess I’ll go back to minigalaxy and PlayonLinux. They work. They don’t freeze, crash, or waste my time with grandiose promises and flashy websites.
Ping me when Lutris does these things too, please, it looks like it’d be pretty cool if it worked. I suggest putting a big fat “beta” warning on the site in the meantime.

steve@perdition ~ $ emerge --deselect --depclean lutris

[LeXofLeviafan]

Calm down, man. Bugs happen, you should be used to dealing with that if you’ve been using Gentoo for a long time (even if you only ever touched stable packages). The GOG download bug is a recent thing, you could’ve guessed it’s not the normal behaviour for Lutris if it’s been around for a while. (Also, the downloading itself works fine, it’s only the filenames that are messed up, and in case of GOG every file is accompanied by a metadata file containing the correct filename among other stuff.)

The primary use for Lutris is exactly what it claims to be: a place where all the games can be run from, i.e. it’s a convenience tool; installing automation is secondary (community-managed for the most part), and has a fallback of doing it manually. Yes, it’s unfortunate that you stumbled upon most bugs in the current version all at once, but it doesn’t reduce the usability of the app outside of these specific issues.

The lutris website promotes it as an easy to use one-click installer and the Grim Dawn script is presented as the same, so that’s what I was expecting. Not something more difficult to deal with than a manual wine install.

Ideally, Lutris is a one-click installer that works perfectly. In practice, name any piece of software more complex than “Hello World”, and there’s guaranteed to be some bugs in it. You’ve literally only tried one game, ended up encountering a bug, and decided that this is all there is to Lutris. Ever heard how open-source projects work? More likely than not, it’s a few programmers who maintain it in their spare time, because they think this kind of thing should exist and someone has to do it, or because they just want to work on it; they won’t be able to deal with issues the moment they pop up (unless they happen to have the time and dedication to work on it at the moment), and then there’s the testing and ensuring nothing gets broken, only part of which can be automated, and the rest is mostly up to the community to find out and report (and usually suggestions and fixes by users are welcome, too).

Presumably this means that a) Games that Lutris can’t automatically download aren’t shown in the library (confusing) and b) Lutris claims to be able to download and install games when it can’t (broken).

It means that a) there’s a bug regarding either importing specific titles into the library, or auto-importing preexisting installs into installed games list, and b) there’s a bug with a specific downloads source that likely doesn’t affect any other.

Tried Lutris from git master […]
Broken. Broken broken broken.

So, the nightly build has a bug in it? Well, that clearly only ever happens with Lutris, all other software is perfectly stable regardless of which commit you take, apparently…

Ping me when Lutris does these things too, please, it looks like it’d be pretty cool if it worked. I suggest putting a big fat “beta” warning on the site in the meantime.

I believe it does work for most users, in fact. Otherwise the project would be mostly dead with no one really using it. And if by “beta” you mean that some functionality doesn’t work – reality is, if everything works at one moment (which had been likely the case some time ago, BTW), that won’t be the case at another, and you won’t ever see the shiny “Bugless Forever” plaque on any program ever (unless it’s a big fat lie). Or would you consider it “out of beta” when any game ever can be installed perfectly from the first attempt, and there’s an army of support staff to fix all issues momentarily?… Cuz that ain’t gonna happen, either. Open-source project, remember?

Or maybe you can wait until the version number reaches actual v1.0. Just in case you didn’t notice, the most recent release was v0.5.4, which doesn’t sound anything like “a finished product” to me, TBH.

[steve_v]

Bugs happen, you should be used to dealing with that if you’ve been using Gentoo for a long time (even if you only ever touched stable packages).

Yes, they do. And they get listed on the Gentoo bugtracker or presented via portage news.
A quick look at my gentoo forums post history will reveal that I have extremely rarely (once IIRC on some properly obscure corner-case) needed to resort to it for explanation of bugs. Because they’re on the bugtracker.

you stumbled upon most bugs in the current version all at once

Pretty much this. I looked through the open issues on github, saw that there was nothing that looked like it would impact me, then discovered that a large swathe of functionality (and the only functionality I wanted that playonlinux doesn’t have) was broken. Thus I wasted many hours on something that wasn’t ever going to work.

You’ve literally only tried one game, ended up encountering a bug, and decided that this is all there is to Lutris.

That was the first game I tried to install and the only one I could post logs for due to the infantile 2 link limit.
All the games I own are on GOG, so for me every game download is broken. But I can’t post the required info for any other test cases, because forum.

there’s a bug with a specific downloads source that likely doesn’t affect any other.

Indeed. It also happens to be the only source that guarantees the games installed are not defective by design, and so the only one I have any interest in whatsoever.

So, the nightly build has a bug in it?

Git master, locally compiled. Not “nightly build”. Perhaps it would be wise to actually have one available somewhere… One fresher than 4 months that has been smoke-tested.

The problem isn’t that git master is broken, it’s that one has to resort to building git master to get basic functionality working because the releases are horribly stale. IMO, this bug is serious enough to be cause for pushing a release, even an interim one with just the applicable commit backported to 0.5.x.

I believe it does work for most users, in fact.

By which I assume you mean “most users use steam”?

Look, had the application produced a useful error message rather than failing silently, I might have cottoned on to what was happening. Likewise if the problem was a pinned issue on github, any issue on github, mentioned on the main site, or even a pinned topic here.
I’ve been searching through issues on github for some time now and I can’t see any mention of this problem, it’s only by reading other people’s support requests that I found it, and that only when I gathered the patience to deal with this horrid forum software.

As it stands GOG support is still broken in the release build, there’s no warning that this is the case on the download page or on github, and the error message offers no clues whatsoever as to what really went wrong.

A note on the download page of the main site would have avoided all this, but instead what we have is a prominent listing of GOG under supported sources despite it not actually working.

[LeXofLeviafan]

Yes, they do. And they get listed on the Gentoo bugtracker or presented via portage news.

…Have you really only ever used software developed or maintained by Gentoo team? 0_o
Also, you don’t post bugs on forums, period. If you have a bug, you post your bug information on bugtracker (Github issues in case of Lutris). Forums are for discussion, not for bug tracking.

I looked through the open issues on github, saw that there was nothing that looked like it would impact me

Right now, there’s 207 open issues on their Github, not counting those closed recently (and thus still affecting the most recent version). I bet you haven’t even thought of the possibility.

then discovered that a large swathe of functionality (and the only functionality I wanted that playonlinux doesn’t have)

One. That’s one bug you’ve encountered and started fussing over it (the rest are mostly side issues).
Normal behaviour in this situation would be like this:

1. Check if it’s a problem that affects one game, or all GOG games.
2. Go search in all issues on Github for some that may have to do with your problem.
3. If you couldn’t find one, create a bug report of your own (yes, that means on Github, not on the forum).
4. While waiting for the devs to deal with the issue, man up and use that download button on GOG website to install the game manually (or if you really are incapable of dealing with that stuff yourself, go play something else).

Also, if you had the game installed already (which you would if you played it in PlayOnLinux before), the quickest way to add it in Lutris would be to just create a new link in Lutris and copy the game settings there (like path to Wine binary and Wineprefix).

That was the first game I tried to install and the only one I could post logs for due to the infantile 2 link limit.

Again, who posts bugreports on forums? There’s a place dedicated for that specifically.

It also happens to be the only source that guarantees the games installed are not defective by design, and so the only one I have any interest in whatsoever.

Well… You do you, of course, but that’s kind of a paranoid take on it. Either way, it’s your own problem really.

Git master, locally compiled. Not “nightly build”.

Well where do you think nightly builds come from? Heaven? Git master contains current status of development, so downloading it is not much better than taking any random commit and hoping it’ll work with no issues.

(Also, it’s a Python project, what compilation are you even talking about…)

IMO, this bug is serious enough to be cause for pushing a release, even an interim one with just the applicable commit backported to 0.5.x.

If you push a hasty release, what you get is a hastly release (likely broken). Considering that the issue is present for everyone, and only you’re reacting like it’s the end of the world, I’d say it makes sense for them to just follow the existing release schedule (the next release is supposed to be very soon, anyway), and push something actually properly tested and ready for use.

By which I assume you mean “most users use steam”?

I mean “most users have games from multiple sources”. (Open the runners list and check how many there are. I counted three dozen. GOG uses like, what, two of them?) Also that they don’t throw in the towel after the first game they failed to install (if that’s your attitude, you clearly haven’t been dealing with Wine games much). And considering that the issue was only found very recently, it means it only appeared very recently (most likely due to GOG changing their downloads hosting), especially since there’s clearly mentions of GOG downloads working for most games dated this year – meaning, in current version (in an issue regarding games with multiple editions).

Look, had the application produced a useful error message rather than failing silently, I might have cottoned on to what was happening

So this happened for the first time and the devs hadn’t anticipated anything like this. What else is new?

Likewise if the problem was a pinned issue on github, any issue on github, mentioned on the main site, or even a pinned topic here.

I fail to see how this particular issue is worse than pretty much any other. It happened recently, it broke a very small part of overall functionality, and there’s a simple workaround for those who can’t wait for the next version.

I’ve been searching through issues on github for some time now and I can’t see any mention of this problem, it’s only by reading other people’s support requests that I found it

It took me like five minutes to find it using search on Github. Are you sure you know how to search correctly?

I gathered the patience

You’re not showing a whole lot of patience, to be honest. You want everything to work perfectly, you want it now, and you refuse to wait for it to be fixed or use an easily available workaround because you’re not used to dealing with bugs at all, apparently.

[steve_v]

Have you really only ever used software developed or maintained by Gentoo team?

In general, yes. Official builds + my own ebuild repo, which I manage (and manage bugs for) myself.

you don’t post bugs on forums, period.

What I posted here isn’t a bug report. It’s a whinge that there is no highly visible bug report, no working official package, no way besides manually bisecting git commits to get a working copy of the software, and no readily available mention of the problem.
Had I found the github issue, I would have posted there. That there are several similar reports on this forum indicates to me that I am not alone in not finding it - ergo, it’s not as easy to find as you claim.

…those closed recently (and thus still affecting the most recent version). I bet you haven’t even thought of the possibility.

A search of all issues using the most generic keyword (“gog”) I can envisage didn’t reveal one mentioning that downloads don’t work, so…

That’s one bug

One which breaks all downloads from GOG, and would require me to download and modify pretty much every gog install script to use a local file.
From the point of view of me using lutris to install my games, that’s 134 bugs for me to go through and fix one at a time.
If the workaround is instead to manually add each game without the benefit of install scripts, then lutris is of no benefit to me whatsoever.

On that topic, it would be a whole lot easier to deal with situations like this if the gog function those install scripts all use provided an option to use a local file.
From what I can see this has been asked for before, and ended with something along the lines of “well, I don’t use local files, so no. Closing”

While waiting for the devs to deal with the issue, man up and use that download button on GOG website to install the game manually

Or use playonlinux, which doesn’t make it needlessly annoying to use an install script with a local file.
Or use gamehub, which has working gog downloads in an official release.
Or just install the game by hand, using winehq, trial-and-error, or the emulators I already have installed outside lutris to get non-native stuff working…
Which makes lutris completely redundant as anything but a simple launcher.

if you had the game installed already (which you would if you played it in PlayOnLinux before), the quickest way to add it in Lutris would be to just create a new link in Lutris and copy the game settings there

It works fine in playonlinux, so why use lutris at all?
If I wanted nothing more than a glorified shortcut, I’d make a shortcut.

you clearly haven’t been dealing with Wine games much

Wine has nothing to do with anything. It’s downloads of games that are broken, regardless of compatibility layer.

I wanted to try lutris because those install scripts looked convenient, both for wine and native games. Yet because almost every gog install script references the same functions with gogslug=foo, almost every gog install script is broken.
If that function failed gracefully and prompted for a local file when the download verification (uhh, what verification?) failed, we wouldn’t be having this argument.
Starting a download and then just assuming it worked and the file is named as anticipated is incredibly fragile. Everyone with a shred of sense is checksuming automated downloads, or at the very least checking that it exists on disk before trying to operate on it. Why isn’t lutris?

It took me like five minutes to find it using search on Github.

Please divulge your magic search term then. I spent far more time looking for it than it took for me to to write an ebuild for, compile, install, and and test gamehub.

You want everything to work perfectly, you want it now , and you refuse to wait

I want sane error-handling, a reasonably well organised bugtracker, and a prompt for a local file when things break.
If there’s neither visible ongoing work on nor readily accessible (i.e. not discord) discussion of elementary stuff like this, I’m going to use something else, waiting be damned.

you’re not used to dealing with bugs at all, apparently.

I’m not used to dealing with bugs that impact hundreds of install scripts, and which I can’t find clear mention of on the official bugtracker.

If, for example, gentoos git-r3 eclass broke due to a change on github… Do you think there’d be a pinned bug report? A news item? Do you think it’d be cause for rushing an update?
After all, it’s only a small percentage of available fetch backends…

I’m out of here now, and I’m probably not going to be using lutris in future whether this bug is fixed soon or not.
It generally doesn’t seem to do anything I can’t do manually, it’s convenient automation is currently broken for all use-cases that apply to me, and in my short usage of it I’ve discovered several other irritants:

*I don’t like the UI and it’s dependency on gnome components (systemd and pulseaudio coming soon?).
*There is no convenient way to create or populate a local installscript repo, and I dislike the design decision to drive everything to the lutris website whenever possible.
*I really dislike that installscripts are json, as I fully expect to comfortably edit such things in vi, locally.
*Runners are hidden from public view and I have to extract the URIs from the project files to download them, this looks very much like a case of being obnoxiously possessive for the sake of it.
*There’s a pervasive dismissive “don’t use, don’t care” attitude evidenced by certain developers, one I saw repeatedly while looking through issues on github. I’ll not bother with examples since it took me 5 minutes to find, and the more I look around the project the more of this attitude I see.

[LeXofLeviafan]

If I wanted nothing more than a glorified shortcut, I’d make a shortcut.

Well, that’s what this is, to begin with. The “automatic download” stuff is in the “useful add-on features” pack here.

If that function failed gracefully and prompted for a local file when the download verification (uhh, what verification?) failed, we wouldn’t be having this argument.
Starting a download and then just assuming it worked and the file is named as anticipated is incredibly fragile. Everyone with a shred of sense is checksuming automated downloads, or at the very least checking that it exists on disk before trying to operate on it. Why isn’t lutris?

It fails and prints an error message, it’s just that devs haven’t anticipated that particular step to fail (as in, everything is downloaded perfectly well, but the filenames are unexpected). What part of “so this happened for the first time, what else is new” was hard to read?

Also, the lack of choice for a local file is a separate issue, it should be offered before download either way.

Please divulge your magic search term then.

is:issue gog download not found. 8 results, 2nd is the one with this bug. I spent more time confirming that it’s indeed the bug I was looking for, than looking for it.

Obviously I had to remove is:open because they get closed when the fix is committed, not when it’s in the stable release version. GOG is obviously where it happens, ‘download’ is the source of the problem, ‘not found’ is part of the error message (which is printed if you actually pay attention). Yes, the search line doesn’t form a phrase that describes the problem correctly (for a human reader), but keyword search has been around for decades now; you can’t possibly have not used it. And yes, you don’t have to get it right on the first attempt, but trying more than once (with changed search terms obviously) should be a given.

I want sane error-handling

The error handling is generally sane for Lutris really, it’s only this case where they goofed it

a reasonably well organised bugtracker

Take it up with Github (somehow it works for other people though…)

and a prompt for a local file when things break.

…No, actually, “when things break”, you shouldn’t get a prompt for a local file, you should get an error log and a close button. What you’re proposing here isn’t “sane error-handling”, it’s closer to “schizophrenic error-handling”.

If, for example, gentoos git-r3 eclass broke due to a change on github… Do you think there’d be a pinned bug report? A news item? Do you think it’d be cause for rushing an update?

You don’t seem to be able to tell a difference between a breaking bug in an operating system package manager, and a download bug in an optional convenience feature of a game runner manager…

*I don’t like the UI and it’s dependency on gnome components (systemd and pulseaudio coming soon?).

Strangely enough, I don’t have Gnome installed (nor do I have much more beyond GTK and the core lib), yet I don’t seem to have problems using it. And last time I checked, apulse worked as a replacement for pulseaudio for most software I tried it with.

*There is no convenient way to create or populate a local installscript repo, and I dislike the design decision to drive everything to the lutris website whenever possible.
*I really dislike that installscripts are json, as I fully expect to comfortably edit such things in vi, locally.

Scripts have two supported formats, one of them (the one intended for be read/written by users) being YAML; the JSON thing is for APIs (though I do agree there’s not much point in using it), but you can perfectly well install games using YAML script written/edited locally (that is, from fs).

*Runners are hidden from public view and I have to extract the URIs from the project files to download them, this looks very much like a case of being obnoxiously possessive for the sake of it.

Remember that thing about “convenience”? Well it’s normally based around “intended usecases”, and the only usecase these prepackaged runners are intended for is internal download; if you want to download them by hand for some inexplicable reason (which can’t be “to use with Lutris”, as that’s the default), there’s no reason for them to provide those for you, as those are simply repackaged open-source stuff that can be found in the package manager (possibly in an overlay but still). And if you really need it regardless of their intentions… Well, it’s open-source anyway; but don’t say they didn’t help you do what you wanted to do outside of what they intended to provide.