Description of problem: Sorry I usually open upstream bugs but I'm going to need help qualifying this one... First thing first: - I have snapshots every upgrade, using mount --bind of /usr/bin/wine* /usr/lib/wine /usr/lib64/wine /usr/lib/libwine.so.1.0 /usr/lib64/libwine.so.1.0, I get 5.20-1.fc33 to work and 5.21-1.fc33 to fail so it's really wine itself. - Normally when that happens I recompile wine to bisect, but for some reason this time recompiled wine 5.20 (with staging patches all applied) exhibit the same behaviour as package's 5.21 -- so it's a build time behavioral difference perhaps? - the second "bad" thing is I have no idea why the game doesn't start. I get these extra lines with failing wine: 00d8:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. 0024:err:seh:NtRaiseException Unhandled exception code c0000005 flags 0 addr (nil) and ntlm_auth segfaults during openssl init: #0 0x0000000000000000 n/a (n/a + 0x0) #1 0x00007f157b1e00b7 OPENSSL_init_library (libcrypto.so.1.1 + 0x7c0b7) #2 0x00007f157cf0f8ee call_init.part.0 (ld-linux-x86-64.so.2 + 0x108ee) #3 0x00007f157cf0f9d8 _dl_init (ld-linux-x86-64.so.2 + 0x109d8) #4 0x00007f157cf000ca _dl_start_user (ld-linux-x86-64.so.2 + 0x10ca) but it doesn't look like ntlm_auth is started at all with working wine. I tried running with WINEDEBUG=+all but that generates way too much log and even comparing working/not working I can't find what fails in the ~400MB of logs; so I'd need help trying to figure this out. I'm especially perplexed by the fact that recompiling 5.20 doesn't work :/ I'll try rebuilding the rpm next... if I can't build something that works I can't trim this down. How reproducible: always Steps to Reproduce: installing and running everquest isn't really something I can recommend as reproducer step :/ Running things like regedit works so wine itself works. Thanks for any help, and sorry again for the crappy bug report!
Did you just upgrade to Fedora 33? https://fedoraproject.org/wiki/Changes/DXVKwined3d Try removing wine-dxvk.
I've been using fedora 33 since beta opened (also got updates-testing enabled) But... wow! That was a great hunch. I just downgraded wine-dxvk wine-dxvk-d3d9 and wine-dxvk-dxgi from 1.7.2-2.fc33 to 1.7.1-1.fc33 and we're back in order. The files are in the lib/wine directory so also got pulled back to older version with my bind mount as they were upgraded at the same time. I'm still surprised that would impact a fresh build in a different directory but it's good to pinpoint it! That should be easier to diagnostic now, I'll dig a bit more tomorrow (won't have time tonight) -- thanks!
Thanks for confirming. Reassigning for more visibility.
Hm. I don't get it. I just rebuilt `wine-dxvk-d3d9-1.7.2-2.fc33.i686.rpm` using the sources from fedpkg and it works :| Yet going back to the distribution's still fails. Something fudged in the build process? I checked https://kojipkgs.fedoraproject.org//packages/wine-dxvk/1.7.2/2.fc33/data/logs/i686/build.log and the meson output is strictly identical (same compilers versions etc). I don't see what's different... Otoh it should be noted the binaries hash (even d3d10.dll etc) are diffetent, I assume this isn't reproductible builds or is there really some taint somewhere? (Also please note the user experience is horrible -- I've spent hours on this and there isn't as much as an error in <binary>_d3d9.log...) ugh. Well... can wait until the next rebuild and see if the problem continues, or do you have a better idea?
FEDORA-2020-e939f7b8be has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e939f7b8be
Hm, I don't think this is the same as the other two bugs -- d3d9 dxvk works well if I just rebuild the exact same as what's present in sources, and it's always been working in fedora33 until the last update. Well, I guess that will "fix" things nevertheless but I'd still like to understand what could cause koji build to fail when a fedpkg local build works :/ I guess I'll keep my local build for now, I think it does help performance a bit although with a game like EQ it's hard to tell.
FEDORA-2020-e939f7b8be has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e939f7b8be` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e939f7b8be See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Dominique Martinet from comment #6) > Hm, I don't think this is the same as the other two bugs -- d3d9 dxvk works > well if I just rebuild the exact same as what's present in sources, and it's > always been working in fedora33 until the last update. > > Well, I guess that will "fix" things nevertheless but I'd still like to > understand what could cause koji build to fail when a fedpkg local build > works :/ I guess I'll keep my local build for now, I think it does help > performance a bit although with a game like EQ it's hard to tell. Yeah, it's quite unfortunate, however having dxvk to handle also d3d9 uncovered some nasty bugs in wine itself ( https://bugs.winehq.org/show_bug.cgi?id=45277 ) and we can't enable it distribution-wide for just for some applications. I am planning to keep an eye on this and retest/re-enable dxvk even for d3d9 if the situation improves. Sorry for causing troubles, but I didn't see any other possible solution that would satisfy everybody, other than disabling dxvk-d3d9 for now.
Thanks for the details -- just subscribed to the bug you linked to as I had noticed some blank screens too (the everquest patcher for example does it, even if the game itself works fine so it hasn't bothered me). It's a shame it can't be configured per application (winecfg library override perhaps?), I understand disabling is probably for the best right now. Let's see how this evolves, I'll try to keep it enabled when possible & report upstream if required.
FEDORA-2020-e939f7b8be has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.