February 2026 - Wine-Bugs - list.winehq.org

[Bug 59384] New: Legacy Family Tree random crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59384 Bug ID: 59384 Summary: Legacy Family Tree random crash Product: Wine Version: 11.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: mice(a)duck.com Distribution: --- Created attachment 80337 --> http://bugs.winehq.org/attachment.cgi?id=80337 Crash backtrace file This crash happens at random times when using the application. Unable to reproduce as many operations work normally for most of the time. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59372] Regression: wine completely broken in the presence of non-graphics gl devices since 11.1

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59372 --- Comment #15 from uvos <devnull(a)uvos.xyz> --- Unfortionatly breaking in gdb at the place where wine hangs is also not of much help: #0 0xf7ffb579 in ?? () #1 0x00000247 in ?? () #2 0xffffb7b0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59372] Regression: wine completely broken in the presence of non-graphics gl devices since 11.1

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59372 uvos <devnull(a)uvos.xyz> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|55f3f7f08b93165d35d703dfca2 |df47c580190f06804b38cf0073b |1dcdff51364ed |b0d57e7877a6b --- Comment #14 from uvos <devnull(a)uvos.xyz> --- > The blamed commit seems a bit weird, as it is supposed to only rename various things and move code around. The next commit is more likely to break something GL related, as it tries to enumerate GPU devices through EGL. You are right, i made a mistake, i just double checked and 55f3f7f08b93165d35d703dfca21dcdff51364ed is the last good commit the first bad commit is df47c580190f06804b38cf0073bb0d57e7877a6b -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59372] Regression: wine completely broken in the presence of non-graphics gl devices since 11.1

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59372 --- Comment #13 from uvos <devnull(a)uvos.xyz> --- Since wine hangs on initialization i can not run "wine reg add "HKCU\\Software\\Wine\\X11 Driver" /v UseEGL /d N /f" Wine hangs before the prefix is ever finishes initializing so there is no registry to change anyhow (unless i create one with wine 11.0) Eglinfo dosent show the mi100 devices at all - this is because it attempts to create a graphics context too and just skips the whole device when this fails. The main problem here is that wine seams to attempt to init all devices and hangs when context creation fails, if you make other egl clients try and use the mi100 for graphics (with DRI_PRIME and the like) the application in question (like eglgears) will simply exit with error: ``` $ DRI_PRIME=1 eglgears_wayland EGL_VERSION = 1.5 radeonsi: error: can't create a graphics context on a compute chip EGLUT: failed to create context ``` The main problem here is not that wine fails to identify the mi100 as a device to avoid, but that it hangs when context creation fails, which could happen for many other reasons than that the device happens to not support the requested configuration as is the case here. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59372] Regression: wine completely broken in the presence of non-graphics gl devices since 11.1

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59372 --- Comment #12 from uvos <devnull(a)uvos.xyz> --- Created attachment 80336 --> http://bugs.winehq.org/attachment.cgi?id=80336 eglinfo output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59360] [Question] How to import Root Certificates for dotnet

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59360 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- It's kind of surprising that MS still ships this root given the long list of issues: https://wiki.mozilla.org/CA/Symantec_Issues While we could technically include it in Wine I don't think we don't want to go against the decision made by browser makers and distributions to protect their users. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59383] New: Beyond Divinity (GOG, Steam) doesn't exit cleanly in Wayland when CSMT is enabled

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59383 Bug ID: 59383 Summary: Beyond Divinity (GOG, Steam) doesn't exit cleanly in Wayland when CSMT is enabled Product: Wine Version: 11.2 Hardware: x86-64 URL: https://store.steampowered.com/app/219760/Beyond_Divin ity/ OS: Linux Status: NEW Severity: minor Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Distribution: ArchLinux After exiting the game via the menu, the game executable (div.exe) remains in the process list and occupies one CPU core at 100%. I waited for 5 minutes, but the process still didn't exit. The problem happens only when using the native Wayland driver (DISPLAY= wine div.exe), but it is not reproducible under XWayland or when running the game under X11 (XFCE). This was reproduced with NVIDIA driver 580.126.09 and with NVK / Mesa 25.3.4. Running the game under Weston 14.02 also triggers this bug. Both the Steam and GOG.com versions are affected, but the original demo version is not. Disabling CSMT resolves the problem for me. FWIW, it was commit de0fc7fd (from Wine-10.11) that enabled the game to display properly in Wayland, and the issue was already present then. Prior to that commit, the game displayed only a black screen while running; however, navigating blindly to the 'Quit' button in the menu resulted in a clean shutdown. Plain terminal output doesn't reveal anything, let me know if any debug log would help. Arch Linux KDE Plasma 6.5.5 KWin (Wayland) Nvidia 580.126.09 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 57182] Clipboard integration is broken with winewayland

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=57182 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69(a)gmail.com --- Comment #1 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Is this still an issue in Wine-11.2? I tried this on KDE Plasma 6.5.5 and KWin, copy/paste between notepad.exe and the system clipboard works for me in a Wayland session. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 7, 2026

[Bug 59278] Adobe Express Photos installer crashes on unimplemented function KERNEL32.dll.PackageFullNameFromId

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59278 --- Comment #10 from Paul Gofman <pgofman(a)codeweavers.com> --- > Alternatively, if the PackageFullNameFromId implementation can't be > upstreamed, could it at least be included in Staging? The problem with > relying on Proton is that it doesn't include other fixes in current upstream > Wine needed for the Adobe suite to function properly. The same question is probably more important for Staging than upstream, does the installer really works with that implementation in isolation? FWIW I don't think that PackageFullNameFromId can't be upstreamed or stubbed upstream, just for me personally given I don't know if it is much useful without real underlying package info implementation, it falls into rather low priority category. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 6, 2026

[Bug 50590] SnelStart 12.102.25 doesn't work (using mono)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=50590 --- Comment #9 from Esme Povirk <madewokherd(a)gmail.com> --- Next thing I saw was a failure to load UIAutomationClient.dll, so I added that. Now it wants Microsoft.VisualBasic.Compatibility 8.0.0.0. We have that, but only version 10. We should probably forward it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Feb. 6, 2026