February 2020 - Wine-bugs - list.winehq.org

[Bug 48630] New: Keepass 2.4.x crashes on Wine 5.2 using .net 4.5 was working on wine 5.1
by WineHQ Bugzilla 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48630 Bug ID: 48630 Summary: Keepass 2.4.x crashes on Wine 5.2 using .net 4.5 was working on wine 5.1 Product: Wine Version: 5.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: christianuceda(a)yahoo.com Distribution: --- Created attachment 66481 --> https://bugs.winehq.org/attachment.cgi?id=66481 Keepass 2 startup crash message under Wine 5.2 Keepass 2.4.x (.NET based app) used to work up to Wine 5.1, upon updating to Wine 5.2 it crashes with a message regardig memory corruption and showing red lines where the menu and toolbar used to be drawn. (Check attached screenshot) This is how I deployed Keepass: (Os Ubuntu 18.04.4) WINEPREFIX=/opt/winkeepass winetricks dotnet45 WINEPREFIX=/opt/winkeepass wine /home/user/Downloads/KeePass-2.42.1-Setup.exe Keepass 2 can be downloaded from: "https://keepass.info/download.html" Keepass 2 .NET allows for multiple users to work on the same database syncing changes instead of overwriting each other. -- 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.

1 6

[Bug 48660] New: osu! crashes when editing beatmaps
by WineHQ Bugzilla 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48660 Bug ID: 48660 Summary: osu! crashes when editing beatmaps Product: Wine Version: 5.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdiplus Assignee: wine-bugs(a)winehq.org Reporter: huupoke12(a)gmail.com Distribution: --- Created attachment 66517 --> https://bugs.winehq.org/attachment.cgi?id=66517 Terminal output osu! crashes when trying to edit any beatmap on wine 5.2. The bug does not happen in wine 5.1 so this is a regression. I saw the function GetNearestColor mentioned so I think it may be related to these commits: - https://source.winehq.org/git/wine.git/commit/5ca9da2c0197ac1260975c1b7b643… - https://source.winehq.org/git/wine.git/commit/a99cad4ae735143321628e1a2d8e1… -- 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.

1 5

[Bug 46916] New: Can' t restore focus to certain minimized fullscreen applications
by wine-bugs＠winehq.org 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=46916 Bug ID: 46916 Summary: Can't restore focus to certain minimized fullscreen applications Product: Wine Version: 4.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: chrylis(a)gmail.com Distribution: --- Created attachment 64004 --> https://bugs.winehq.org/attachment.cgi?id=64004 stderr logs This is a counterpart to the many (mostly resolved?) bugs regarding switching *out* of fullscreen applications. On some applications, I can switch out of the window without any problem. If the application has changed the desktop resolution, it is restored to the previous setting (e.g., 1920x1080->3840x2160). However, I cannot restore focus to the application once it loses focus. The application will unminimize (from the taskbar or the window switcher), and the mouse cursor changes to the appropriate graphics, but the application seems never to be unblurred; it's not redrawn (I believe this is its own choice when it thinks it doesn't have focus), and the "bookmarked" resolution isn't applied. The application does not respond to input, and I have to kill Wine from the CLI. The applications I have available where I'm able to reproduce the behavior are based on the Civ4 engine (Civ4 itself, Railroads!). The behavior is identical regardless of whether the application changes the screen resolution (if it hasn't, then it'll switch back to full screen and show the last render but is still frozen). Fallout 2, with or without Restoration, does *not* reproduce the behavior. It may be linked to D3D. I'm running KWin 5.14.5 on Intel graphics. -- 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.

2 7

[Bug 40187] New: Dream Acquarium can't run
by wine-bugs＠winehq.org 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=40187 Bug ID: 40187 Summary: Dream Acquarium can't run Product: Wine Version: 1.8 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sdunnagan(a)yahoo.com Distribution: --- Something changed in the Dream Acquarium application, and now it doesn't run after it automatically installs updates. -- 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.

2 6

[Bug 45216] New: Alien: Isolation crashes on startup
by wine-bugs＠winehq.org 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=45216 Bug ID: 45216 Summary: Alien: Isolation crashes on startup Product: Wine Version: 3.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: moihack.inside(a)gmail.com Distribution: ArchLinux Created attachment 61439 --> https://bugs.winehq.org/attachment.cgi?id=61439 Alien:Isolation terminal output Alien: Isolation (Steam version) crashes on startup. There is an attempt for the game to load as a process named AI.exe is created and a window pops up on a black screen but with the mouse cursor changing to the in-game one. So the game at least attempts to boot up. Specifically for Arch Linux which I use, there is a "trick" to get this game running. If you install the package "wine-staging-nine" from the official repositories here : https://www.archlinux.org/packages/multilib/x86_64/wine-staging-nine/ the game boots correctly. It does not boot up with plain wine-staging or vanilla wine + gallium nine patches. So it probably needs a mix of patches from both projects. I'm attaching a terminal output below. GPU used: Radeon HD 6870 -- 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.

2 5

[Bug 48629] New: valgrind shows dependency on uninitialized memory in gdi32/dib.c
by WineHQ Bugzilla 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48629 Bug ID: 48629 Summary: valgrind shows dependency on uninitialized memory in gdi32/dib.c Product: Wine Version: 5.0-rc6 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 66480 --> https://bugs.winehq.org/attachment.cgi?id=66480 valgrind log See attachment. -- 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.

1 3

[Bug 48241] New: PACE license manager installer dies with Error: -1627 Function failed
by WineHQ Bugzilla 25 Feb '20

25 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48241 Bug ID: 48241 Summary: PACE license manager installer dies with Error: -1627 Function failed Product: Wine Version: 4.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs(a)winehq.org Reporter: emiel(a)kollof.nl Distribution: --- Installation seems to die here: 01de:err:msi:ITERATE_StartService Failed to start service L"PaceLicenseDServices" (6) 01de:err:msi:execute_script Execution of script 0 halted; action L"StartServices" returned 1627 01de:err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1627 00c9:err:ole:ClientRpcChannelBuffer_SendReceive called from wrong apartment, should have been 0xca000001de -- 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.

1 8

[Bug 17101] New: Cancelling text with Scientific Workplace leaves last character
by wine-bugs＠winehq.org 24 Feb '20

24 Feb '20

http://bugs.winehq.org/show_bug.cgi?id=17101 Summary: Cancelling text with Scientific Workplace leaves last character Product: Wine Version: 1.1.13 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: loic.grenie(a)gmail.com Created an attachment (id=18937) --> (http://bugs.winehq.org/attachment.cgi?id=18937) Screenshots When I delete text under Scientific Workplace, the end of the line is not treated correctly. Was is most evident is that the last character(s) is(are) not canceled. I attach a vertical concatenation of 3 screenshots: the first is the state before hitting backspace: I typed "abcdefghijkl" and added an inline image, the second is after hitting backspace (I cancel the "g"); notice how the last "kl" are not correctly canceled and the image is not moved to the left and the third is how it should have looked. No error message is displayed while hitting backspace (it complains about IME all the time but I think it's no big deal). I have seen this problem at least in versions 1.0.1 (under Debian testing, Ubuntu hardy and intrepid, both 32 and 64 bits) and 1.0.13 (Debian testing 64 bits). The situation is even worse under Ubuntu intrepid (32 bits OS, Wine v1.0.1) as text disappears as soon as it is typed (Esc redisplays it briefly). I can live with the image (visible at the end of the line) not correctly positioned after backspace (it seldom occurs), but the last character not canceled is a real (visual) pain. I can test anything you wish and I understand programming/debugging. Thank you for any help. SurJector -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

2 9

[Bug 48659] New: Job details page: Add links to the first error in a report
by WineHQ Bugzilla 24 Feb '20

24 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48659 Bug ID: 48659 Summary: Job details page: Add links to the first error in a report Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- When looking at a full WineTest report on the TestBot website finding the errors can require a lot of scrolling and there is a risk of skipping over them. The cache .errors files contain the line of each error and error group. This makes it possible to add links to the errors: * The first report line would contain a link pointing to the first report error (for instance in the form of a down arrow at the start of the line). * Errors would contain links to the previous/next errors, or to the first/last report line. * The last report line would link to the last report error. Once the first draft is ready the link chain may be tweaked: * The first line of test units containing errors, could be added to it. * A second chain link to be set up with only the new failures. -- 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.

1 1

[Bug 48658] New: Fix error handling in the WineRun* scripts
by WineHQ Bugzilla 23 Feb '20

23 Feb '20

https://bugs.winehq.org/show_bug.cgi?id=48658 Bug ID: 48658 Summary: Fix error handling in the WineRun* scripts Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Over time error handling in the WineRun* scripts has become complex and inconsistent. It's in need of a serious cleanup, particular so that errors can be reliably identified in the testbot.log file and shown on the JobDetails page. There are three places where the WineRun* scripts can send errors: * To the global 'var/log' log file. Sending errors to the global file makes sense for errors which could be relevant to other operations on that VM such as the preceding or following revert. * To the per-task 'testbot.log' file. This is where most errors should go for long term storage. * To stderr which is redirected to 'testbot.log' nowadays. Then there are a number of functions that report errors: * LogMsg() This adds a message to the global log (errors and others alike). It is used to log the startup and exit of the WineRun* scripts in the global log, but also to save some errors there. * Error() Prints the error on stderr if --log-only is not specified, and sends them to the global log (via LogMsg()). In particular things like usage errors thus end up in the global log which probably does not make sense. * LogTaskError() Explicitly opens testbot.log and appends to it. It should really print to stderr instead. But some calls to LogTaskErrors * FatalError() The main point of FatalError() is that it invokes WrapUpAndExit() with appropriate parameters. But it also sends the error message to both the global log and testbot.log (via LogTaskError()). That's probably not appropriate. * FatalTAError() This is a specialized form of FatalError() which also notifies the administrator of network issues. That's ok except that depending on the codepath it may end up calling any of Error(), LogMsg(), LogTaskError() or FatalError(). -- 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.

1 0