wine-bugs February 2021

wine-bugs@winehq.org

1 participants
6924 discussions

[Bug 48671] New: Some patches may require forcing a wineprefix update
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48671 Bug ID: 48671 Summary: Some patches may require forcing a wineprefix update 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: --- The TestBot updates the wineprefixes when it updates its base Wine source from the daily Wine commits. The rest of the time it lets Wine deal with updating the wineprefix is necessary. Furthermore Wine only updates the wineprefix when wine.inf changes, which is the case for every Wine release. The problem is that the wineprefix should also be updated when a patchset adds a WINE_REGISTRY resource to an existing dll. Failing to do so may cause the patchset tests to fail because the wineprefix is out of date. See: https://www.winehq.org/pipermail/wine-devel/2019-December/156914.html WinePrefix updates are relatively slow compared to the execution time of most tests (about 30s vs. < 1s) so it would be good not to have to do that for every task. An alternative would be to force a wineprefix update when a task has failures and gets rerun as a result (pass an option to the relevant VM-side scripts). Note: Shared Gecko and Mono install issues should be discussed on bug 48354. -- 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 4

[Bug 48092] New: On cw-rx460 the win32 WineTest run gets interrupted before it completes
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48092 Bug ID: 48092 Summary: On cw-rx460 the win32 WineTest run gets interrupted before it completes 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: --- cw-rx460 runs wt-daily (*), just like cw-gtx560. But when running the plain 32 bit tests on cw-rx460 (cw-gtx560-t32), wt-daily ends up submitting the test results before WineTest.exe has completed, resulting in many rejections by test.winehq.org (https://test.winehq.org/data/errors.html). WineTest appears to be interrupted most often during kernel32:loader, but sometimes it's during kernel32:debugger or ieframe:ie. And once in a while the test completes, though that's pretty rare. Maybe a test crashes the X server, causing winetest.exe to exit prematurely. wt-daily is started by cron so it does not depend on the X server and would start a second winetest command to send the (incomplete) test results. Then it would start the wow32 and wow64 tests and by that time it's possible the X server would have restarted. Interestingly wow32 and wow64 don't seem to cause the X server to crash. cw-rx460 is not a TestBot VM so this does not impact the TestBot results. But it could impact the test.winehq.org results the few times where WineTest completes (though when it does it only gets ~10 failures which is half what the other Wine machines get). So I have disabled the 32 bit WineTest runs until this is resolved. (*) https://github.com/fgouget/wt-daily -- 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 4

[Bug 48090] New: Add support for .com programs
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48090 Bug ID: 48090 Summary: Add support for .com programs 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: --- The TestBot assumes that if a patch touches a directory in programs, then it must append .exe to the program's name. But Wine could also get .com programs, see for instance chcp.com: https://www.winehq.org/pipermail/wine-devel/2019-November/154371.html And in fact we already have other programs with non-standard extensions, for instance winhelp.exe16 and winoldap.mod16. So if the program's directory already has an extension the TestBot should not add one. Another option would be to use the MODULE setting in the directory's Makefile.in file. But the TestBot server does not have access to the Wine source. It would also make it harder to deal with patches adding test directories and it would be quite ugly to have to read them every time anyway. It would make it harder to deal with patches adding dlls/programs as it would require parsing the patch to retrieve the MODULE value. Another option may be to never add an extension, though then there's the risk of getting collisions between the dll and program names, and maybe it impacts other parts of the TestBot anyway. _CreateTestInfo() in testbot/lib/WineTestBot/PatchUtils.pm needs to be patched but there are impacts elsewhere. The WTBS (Wine TestBot test Suite) will also need to be updated. -- 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 48653] New: Automate checking the WTBS jobs
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48653 Bug ID: 48653 Summary: Automate checking the WTBS jobs 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: --- The Wine TestBot test Suite (WTBS) is a set of Wine patches that can be used to check how the TestBot handles test failures, timeouts, patch series, non-Wine patches, etc: https://github.com/fgouget/wine/commits/wtbsuite The patches can either be used in isolation to test a specific aspect, or all together using formail to do a broad check for TestBot regressions. However as the test suite has become more complete the number of patches has grown and now tops 90. So a full check for regressions means checking the results of about 90 TestBot jobs for missing test failures, incorrect report validation messages, etc. This makes it pretty time consuming. So the goal is to automate at least the most basic checks. To do so the plan is to add lines of the form 'WTBS.xxx=yyy' to the commit messages of the WTBS patches. Each will define a property that should be checked in the TestBot job and tasks. Then a TestBot script can be run to go through every job, ignore the queued and running ones and those have have no associated patch. For the others read the associated patch and look for the WTBS.xxx lines. Note that for patch series, only the last set of WTBS values should be taken into account (i.e. the ones after the "Last patchset part" line). Here is a sample of the possible properties to check: * WTB.Job.Remarks The job 'title' which is derived from the patch subject line. * WTBS.Job.Status Whether to expect badpatch, completed, etc. For tasks the property names would be prefixed with the VM type: build, win (for win32 and win64), wine. This allows specifying different results for each. * WTBS.build.Status, WTBS.win.Status, WTBS.wine.Status Same as Job.Status but at the task level. * WTBS.win.Failures, WTBS.wine.Failures The number of test failures expected from the result. Note that if the Wine Test Unit is buggy we may get more test failures than expected. This is particularly an issue with Wine VMs if their mission include test=module or test=all. So it may make sense to specify WTBS.win.Failures but leave out WTBS.wine.Failures. Or maybe have a MinFailures property. Or grep the failures whose message contains 'WTBS' and only compare those to this property. * WTBS.win.NewFailures, WTBS.wine.NewFailures The number of new test failures as reported by LoadLogErrors() for each of the task's report. * WTBS.win.ReportFailures, WTBS.wine.ReportFailures In a number of cases what we're interested in is the report validation errors produced by the TestBot. Just checking the number of such errors may not be that useful. What we may want is a way to check that it reported missing failures messages, or too much data being printed, etc. This requires being able to specify a set of errors that are expected to be present for which this basic property system is not very well suited. * WTBS.win.TestUnits For each VM, collect the Step's FileName and the Task's CmdLineArg values to determine the test unit being run, and verify that this is a superset of the TestUnits list. This can be used to ensure that the TestBot ran the right set of tests (and avoids failures when a new test is added to Wine). Note that doing the same thing for Wine VMs is harder because those can have test=module in their mission(s), which changes greatly the list of tests being run. It may make sense to provide default values for some properties to not have to type too much in the commit messages. For instance for the Status properties one may expect the status to be 'completed'. But given the WTBS tests error cases a lot that may not be all that useful. Similarly it may be useful to be able to specify something like 'WTBS.all.Status' to specify the expected Status for the build, win and wine VMs all at once. But again this may be overkill. Finally the general rule should be that unspecified properties are not checked. So if 'WTBS.wine.Failures' is not specified, then the failure count of Wine VMs should not be checked. -- 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 48654] New: Automate checking the WTBS patches
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48654 Bug ID: 48654 Summary: Automate checking the WTBS patches 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: --- See bug 48653 for a description of the WTBS and how to check the jobs created when running it on the TestBot. Some patches in the WTBS are not meant to create TestBot jobs but rather to verify that it ignores non-Wine patches, or patches that don't impact the tests or the Wine build, etc. Those still create entries in the 'wine-devel' page, that is in the TestBot's Patches table. Each entry gets the patch subject and a disposition property indicating what the TestBot did with the patch. Unfortunately non-Wine patches are not kept around so there is no way to get at the WTBS fields for those. So a TestWTBS.patches script would need to get the WTBS properties from another source. For instance it could be given the path to the WTBS mbox and get the properties from there. It would not need to understand all the intricacies of the mbox format (though with the appropriate Perl module it may be easy to parse). As a last resort, all we would care about is: * The 'From' lines to delimit emails. * The 'Subject:' lines to match the mbox emails with Patches entries. * The WTBS properties in the commit message following the Subject line. Checking the patch objects would require an extra property: * WTBS.Patch.Disposition This should be set to the expected patch disposition such as 'No patch found', 'Not a Wine patch', etc. A default disposition could be set if a 'WTBS.Job.*' or other task property is specified. -- 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 2

[Bug 48655] New: Automate checking the WTBS emails
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48655 Bug ID: 48655 Summary: Automate checking the WTBS emails 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: --- See bug 48653 for a description of the WTBS and how to check the jobs created when running it on the TestBot. When a 'wine-devel' job completes the TestBot sends one or two emails. * One of the emails simply sends the task reports to the patch author. * The other is only sent if a task generated new errors. The point of the TestWTBS.emails script would be to check that: 1. The TestBot sent the task report email for every Wine patch and not for any patch email. This would be based off of the WTBS.Patch.Disposition field. 2. The TestBot sent a 'found new errors' email only when new errors are expected. This would be based off of the 'WTBS.*.NewFailures' property or the expected errors list. However for both these checks the script would need access to the emails sent by the TestBot. The simplest option would be for the tester to set the WinePatchToOverride property and save the emails to a separate mbox and give the patch to that mbox to the script. As in the TestWTBS.patches case, the script would only care about a few lines: * The 'From' lines to delimit the emails. * The 'Subject' lines to match them to TestBot jobs and thus to the set of WTBS properties. Note that this would not rely on the 'TestBot job xxx results:' part since the new failures email are lacking it. Instead it would match the rest of the subject to the job's Remarks field. * The 'I think I found new failures' line to identify emails reporting new errors. The script could later be expanded to check the content of the email or attachments more in details if needed. -- 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 2

[Bug 32216] New: WienTestBot should skip some tests on some platforms
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=32216 Bug #: 32216 Summary: WienTestBot should skip some tests on some platforms Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fgouget(a)codeweavers.com Classification: Unclassified An example is the ieframe:webbrowser tests which it should skip on NT4 and Windows 2000 platforms. WineTest.exe is said to already have the necessary code somewhere, it's just missing from TestLauncher. See this wine-devel thread for more details: http://www.winehq.org/pipermail/wine-devel/2012-November/097819.html -- 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 11

[Bug 50719] New: The TestBot mishandles renames
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=50719 Bug ID: 50719 Summary: The TestBot mishandles renames Product: Wine-Testbot Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The TestBot analyses patches to determine whether they are Wine patches and which tests are impacted and must be rerun. But when a patch renames a test unit it still schedules a run for the renamed test unit. For instance if apphelp:apphelp is renamed to apphelp:renamed, the TestBot still schedules a run of apphelp:apphelp (in addition to the apphelp:renamed one). This means it does not keep track of Wine's current files list correctly, which also impacts identifying whether a patch is a Wine patch or not, particularly for patch series. This can be tested with the following wtbsuite tests: WTBS Check combined renaming and modifying a file (apphelp:apphelp). [2/2] WTBS S10.2 - ...before renaming it in the next part (amstream:amstream). [7/7] WTBS S5.7 - Check for rename+addition+removal conflicts (msi:suminfo). -- 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 2

[Bug 48208] New: Detect missing entry point errors
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=48208 Bug ID: 48208 Summary: Detect missing entry point errors 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 a Windows test executable cannot run because of a missing test executable the TestBot remains stuck until the 2 minutes timeout. This is because Windows puts up an error dialog waiting for user input. In such a case the test report is almost empty and the issue is not obvious until one looks at the screenshot. The TestBot should detect such a situation and warn the user. One simple approach would be for the TestBot to detect that the test report only contains the TestLauncher's start and done lines and indicates a timeout. In such a case it could add a message to the .err file suggesting to check the screenshot. This would only be a heuristic though. A better approach would be for the TestLauncher to detect the error dialog. Ideally, instead of waiting for the child process for the full 2 minutes it would periodically check for the presence of this dialog, which would also speed up the task run. This approach could also be used by WineTest.exe, though presumably missing entry points would have been detected before making it into the Wine source. -- 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 50538] New: Wine child process exceptions are miscounted
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=50538 Bug ID: 50538 Summary: Wine child process exceptions are miscounted Product: Wine-Testbot Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The "WTBS Crash in a child process (kernel32:toolhelp)." test case shows an inconsistency in the test failures count between the Windows and Wine VMs. On Windows we get: 1bec:toolhelp: unhandled exception c0000005 at 0054273D toolhelp:471: unhandled exception c0000005 in child process 1bec 1750:toolhelp: 3 tests executed (0 marked as todo, 1 failure), 0 skipped. Here there is 1 exception, 1 failure reported by the parent process but 2 error lines, and the task's failure count ends up being 2. But in Wine we get: Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x00542c1d). toolhelp:471: unhandled exception c0000005 in child process 0104 00fc:toolhelp: 3 tests executed (0 marked as todo, 1 failure), 0 skipped. So there is still 1 exception, still 1 failure reported by the parent process, still 2 error lines, but the task's failure count ends up being just 1. The issue appears to be that ParseWineTestReport() (and probably dissect too) detects ": unhandled exception...at" lines but not Wine's "Unhandled exception:" ones. This means the TestBot may fail to detect exceptions on Wine. Meanwhile GetReportLineCategory() and _GetLineKey() detect both. -- 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 50491] New: Detecting whether garbled lines are new
by WineHQ Bugzilla 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=50491 Bug ID: 50491 Summary: Detecting whether garbled lines are new Product: Wine-Testbot Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Sometimes a failure line is garbled because of race conditions or a missing '\n'. This typically looks something like this: advpack.c:689: WTBS Garble 2advpack.c:691: WTBS Garble 3advpack.c:692: Test failed: WTBS A test failure The TestBot still detects these failures because it knows which test unit is running at that point in the report and thus looks for something like 'advpack.c:\d+: Test failed: ...'. But when it tries to detect whether this is a new error line it cannot compare the whole line with past instances as the garbage part may change or not be present in WineTest runs (particularly if it contains line numbers). That suggests it should extract just the current failure string, that is: advpack.c:692: Test failed: WTBS A test failure This should maybe also be the string stored in the .errors file. -- 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 27453] New: Lag when loading new sound in source games
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=27453 Summary: Lag when loading new sound in source games Product: Wine Version: 1.3.21 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: congelli501(a)gmail.com When you start a level in a game powered by valve's source engine, sounds that are played for the first time since the game was launched will cause the game to lag. Ex: open a new portal for the first time in a Portal2 level. Affects: - Portal 2 - Left 4 Dead 2 - Probably more... -- 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 39

[Bug 10219] New: Windows Media Player 11 setup fails
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=10219 Summary: Windows Media Player 11 setup fails Product: Wine Version: 0.9.48. Platform: PC URL: http://www.microsoft.com/windows/windowsmedia/download/A llDownloads.aspx?displang=en&qstechnology= OS/Version: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: alex(a)thehandofagony.com The setup program for Windows Media Player 11 tries to validate Windows if the version is set to XP, and this fails. There was talk some time ago about an ntlm_auth patch that would allow the validation, but it fails for me even though I have the correct version of Samba installed. However, the installer does not run the Genuine check if the Windows version is set to Vista. When run thus it does work, however; it tries to create an instance of a wuapi.dll class, which is not registered in Wine. When I use a native dll from XP and register it the console output changes saying no instance could be created. The installer then says no updates could be found. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 19

[Bug 14547] New: Problem with loading of windows from Java applications
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=14547 Summary: Problem with loading of windows from Java applications Product: Wine Version: 1.1.1 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: yolande(a)haneder.biz Created an attachment (id=14894) --> (http://bugs.winehq.org/attachment.cgi?id=14894) Files for the test case We made a test case to show that child windows for Java applications (written in a class are not appearing) are problematic. To start the test, you have to install Java on Wine (I tested with java1.5-10) and start file in the /bin directory of the java installation directory. What is expected (showing during tests on Windows XP): There is a mainframe called "Using a JDesktopPane" Then a row in the main body of the main frame called "Add" Then a child window called "Internal frame" Result in Wine: Totally black screen with only the part with the word "Add" to be visible. Through hovering the mouse over the black part, you can restore most parts of your desktop to access other windows. If you need the source code of any of the file, you just need to ask. -- 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 19

[Bug 21764] New: Sun JRE (jre-6u16-windows-i586-s) installation failure
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=21764 Summary: Sun JRE (jre-6u16-windows-i586-s) installation failure Product: Wine Version: unspecified Platform: x86 URL: http://java.sun.com/products/archive/j2se/6u16/index.h tml OS/Version: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: bunglehead(a)gmail.com Sun JRE 6update16 fails to install with 1.1.39. It's a regression and a commit to blame is 1ff992314887d03abeb4098789701ff3bfd5d2d8: msi: Add summary information stream to the streams table. Reverting helps. -- 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 15

[Bug 22024] New: sun jre installation (jre-6u18-windows-i586.exe)
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=22024 Summary: sun jre installation (jre-6u18-windows-i586.exe) Product: Wine Version: 1.1.40 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: ntoskrnl AssignedTo: wine-bugs(a)winehq.org ReportedBy: samuele_catuzzi(a)yahoo.it Created an attachment (id=26779) --> (http://bugs.winehq.org/attachment.cgi?id=26779) wine jre-6u18-windows-i586 install crash Several crash and register dump during install Ubunutu 9.10 x86_64 -- 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 8

[Bug 38624] New: jre-8u45-windows-i586.exe exits silently
by wine-bugs＠winehq.org 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=38624 Bug ID: 38624 Summary: jre-8u45-windows-i586.exe exits silently Product: Wine Version: 1.7.43 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dimesio(a)earthlink.net Distribution: --- I only tested the 32 bit offline installer, but AppDB test reports indicate the online installer fails similarly. The only thing printed in the terminal is: fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} This version of JRE requires Vista SP2 or newer; I tested with winecfg set to Vista, 7, and 8, with the same results. -- 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 38811] New: jre-8u45-windows-i586.exe installer crashes (GetThreadPreferredUILanguages is a stub)
by wine-bugs＠winehq.org 03 May '21

03 May '21

https://bugs.winehq.org/show_bug.cgi?id=38811 Bug ID: 38811 Summary: jre-8u45-windows-i586.exe installer crashes (GetThreadPreferredUILanguages is a stub) Product: Wine Version: 1.7.45 Hardware: x86 URL: http://javadl.sun.com/webapps/download/AutoDL?BundleId =106246 OS: Linux Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: dimesio(a)earthlink.net Depends on: 38624 Distribution: SUSE Filing per https://bugs.winehq.org/show_bug.cgi?id=38624#c1. Tested in wine-1.7.45-213-g4f3acf3. -- 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 17

[Bug 14750] New: comctl32: Fixed rebar behaviour when there's capture and no drag
by wine-bugs＠winehq.org 03 May '21

03 May '21

http://bugs.winehq.org/show_bug.cgi?id=14750 Summary: comctl32: Fixed rebar behaviour when there's capture and no drag Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: UNCONFIRMED Severity: minor Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: bugzilla(a)tut.by Created an attachment (id=15249) --> (http://bugs.winehq.org/attachment.cgi?id=15249) comctl32: Fixed rebar behaviour when there's capture and no drag ERR() here causes some applications (i.e. ISIS/Proteus) to crash when mouse moves over rebar. This patch fixes this behaviour. -- 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 17

[Bug 34122] New: Civilization V breaks both expansion packs are installed
by wine-bugs＠winehq.org 30 Apr '21

30 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=34122 Bug #: 34122 Summary: Civilization V breaks both expansion packs are installed Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: mcasadevall(a)ubuntu.com Classification: Unclassified Created attachment 45374 --> http://bugs.winehq.org/attachment.cgi?id=45374 Test program that tries to reproduce Civilization V's behavior as seen from the +files log With the release of Brave New World for Civiliziation V, the game itself fails to properly load either expansion if both are loaded. The issue appears to boil down to the fact that Civ tries to load its datafiles in the order returned by Find{First,Next}File, and inadvertently loads its expansions in the wrong order (G&K must be loaded before Brave New World). This issue can be semi-worked around by renaming files so that their return order is changed (generally renaming Expansion to Expansion3 seems to do the trick, but its not foolproof). On Windows, FindFirstFile returns its files in alphabetical order (likely due to Steam installing them in that order), and as such, Civ can load things correctly. I was able to reproduce this bug on Windows by moving everything to a network drive (which returns a different order), and getting similar results. To show the problem, I wrote a test program which calls FindFirstFile in a matter similiar to Civ5 does; said program is attached along with a trace from +file. Results from the test program: Wine git (game does NOT work): mcasadevall@perdition:~/wine-dev/steam/drive_c/Program Files/Steam/SteamApps/common/Sid Meier's Civilization V$ $WINE ./a.exe .\Assets\DLC\DLC_02\SpainInca.Civ5Pkg .\Assets\DLC\Shared\Upgrade1.Civ5Pkg .\Assets\DLC\DLC_05\Korea.Civ5Pkg .\Assets\DLC\Tablet\Tablet.Civ5Pkg .\Assets\DLC\Expansion2\Expansion2.Civ5Pkg .\Assets\DLC\DLC_06\AncientWonders.Civ5Pkg .\Assets\DLC\DLC_04\Denmark.Civ5Pkg .\Assets\DLC\DLC_01\Mongol.Civ5Pkg .\Assets\DLC\DLC_03\Polynesia.Civ5Pkg .\Assets\DLC\Expansion\Expansion1.Civ5Pkg .\Assets\DLC\DLC_Deluxe\Babylon.Civ5Pkg Windows XP - NTFS filesystem (game works) C:\Program Files\Steam\steamapps\common1\Sid Meier's Civilization V>a .\Assets\DLC\DLC_01\Mongol.Civ5Pkg .\Assets\DLC\DLC_02\SpainInca.Civ5Pkg .\Assets\DLC\DLC_03\Polynesia.Civ5Pkg .\Assets\DLC\DLC_04\Denmark.Civ5Pkg .\Assets\DLC\DLC_05\Korea.Civ5Pkg .\Assets\DLC\DLC_06\AncientWonders.Civ5Pkg .\Assets\DLC\DLC_Deluxe\Babylon.Civ5Pkg .\Assets\DLC\Expansion\Expansion1.Civ5Pkg .\Assets\DLC\Expansion2\Expansion2.Civ5Pkg .\Assets\DLC\Shared\Upgrade1.Civ5Pkg .\Assets\DLC\Tablet\Tablet.Civ5Pkg Windows XP - network filesystem (game does NOT work) X:\wine-dev\steam\drive_c\Program Files\Steam\SteamApps\common\Sid Meier's Civil ization V>a .\Assets\DLC\Tablet\Tablet.Civ5Pkg .\Assets\DLC\DLC_02\SpainInca.Civ5Pkg .\Assets\DLC\Shared\Upgrade1.Civ5Pkg .\Assets\DLC\DLC_05\Korea.Civ5Pkg .\Assets\DLC\Expansion2\Expansion2.Civ5Pkg .\Assets\DLC\DLC_06\AncientWonders.Civ5Pkg .\Assets\DLC\DLC_04\Denmark.Civ5Pkg .\Assets\DLC\DLC_01\Mongol.Civ5Pkg .\Assets\DLC\DLC_03\Polynesia.Civ5Pkg .\Assets\DLC\Expansion\Expansion1.Civ5Pkg .\Assets\DLC\DLC_Deluxe\Babylon.Civ5Pkg I believe the underlying cause of this bug may also be the root of bug #31113, but until I know for sure, they should be considered seperate issues. -- 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 54

[Bug 18166] New: dlls/ntdll/directory.c: implicit declaration of function 'getdirentries'
by wine-bugs＠winehq.org 30 Apr '21

30 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=18166 Summary: dlls/ntdll/directory.c: implicit declaration of function 'getdirentries' Product: Wine Version: 1.1.19 Platform: PC OS/Version: NetBSD Status: NEW Keywords: patch, source Severity: major Priority: P2 Component: build-env AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Created an attachment (id=20631) --> (http://bugs.winehq.org/attachment.cgi?id=20631) wrap getdirentries around getdents gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -o directory.o directory.c directory.c: In function 'wine_getdirentries': directory.c:1289: warning: implicit declaration of function 'getdirentries' Apparently getdirentries is broken on NetBSD. Attached patch (based on one from their port) fixes it. -- 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 14

[Bug 31113] New: Civilization V crashes after specific amount of game turns
by wine-bugs＠winehq.org 30 Apr '21

30 Apr '21

http://bugs.winehq.org/show_bug.cgi?id=31113 Bug #: 31113 Summary: Civilization V crashes after specific amount of game turns Product: Wine Version: 1.5.5 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: megatog615(a)gmail.com Classification: Unclassified Created attachment 40841 --> http://bugs.winehq.org/attachment.cgi?id=40841 Page fault log After a specific amount of game turns(depending on how the game has played out), Civilization V will crash with a page fault. If you save the game just before you can do nothing else and must click "NEXT TURN," you can reproduce the bug every time. I am going to attach a save file at just this point. All you have to do is click NEXT TURN. -- 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 177

[Bug 45906] New: Soldat instal, start but black / garbage and halt after game starts
by wine-bugs＠winehq.org 30 Apr '21

30 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=45906 Bug ID: 45906 Summary: Soldat instal, start but black / garbage and halt after game starts Product: Wine Version: 3.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mrluzeiro(a)ua.pt Distribution: --- In the Soldat game, I can install it, configure and start the program. After start the program when actually start the game, the screen flickers and become blank / transparent / garbage..etc. I managed to run this game on a different hardware so I think the issue may with this machine hardware. Linux x86-64 NVidia GT 530 drivers 384.130 I didnt found anything useful or errors from the logs. -- 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 4

[Bug 50062] New: Fallout 76 invisible ground textures
by WineHQ Bugzilla 29 Apr '21

29 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=50062 Bug ID: 50062 Summary: Fallout 76 invisible ground textures Product: Wine Version: 5.20 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: o.dierick(a)piezo-forte.be Distribution: --- Created attachment 68518 --> https://bugs.winehq.org/attachment.cgi?id=68518 Screenshot of missing ground textures; wine 5.20 Hello, Fallout 76 has invisible ground textures. See attached screenshot. My setup is: - Debian 8 amd64 16Gb RAM i7-4930 @ 3.4Ghz; - NVidia RTX 2070 8GB VRAM + proprietary driver 450.66; - wine 5.20; - winetricks corefonts xact_x64; - virtual desktop + no WM management/decoration + grab fullscreen; To replicate, install the game (Bethesda.net or Steam windows version), then you have to use an existing character or create a character and get out of the first building. That building has no natural floor and the issue only affects the ground texture, so it's not enough to just start a new game. Note that the game is affected by a bug that makes the game crash when loading a save immediately after launching the program. You have to start a new character first. When character creation is complete, you may return to the main menu and load the save. This is an application bug [1]. Some graphics settings must be disabled in the INI file to avoid major mouse and rendering issues. The details can be found on the lutris website [2]. [1] https://www.reddit.com/r/fo76/comments/a3446i/game_crashes_after_trying_to_… [2] https://lutris.net/games/fallout-76/ The ground is transparent. The game renders the objects behind mountains and the performance is directly affected by the rendering distance set in the option. - Using Ultra or lowest graphic settings makes no difference; - I tried changing some values in the INI file without luck; - The issue occurs with wine-staging 5.20 too. Regards. -- 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 2

[Bug 45864] New: wine mono cannot load 64-bit DLLs
by wine-bugs＠winehq.org 29 Apr '21

29 Apr '21

https://bugs.winehq.org/show_bug.cgi?id=45864 Bug ID: 45864 Summary: wine mono cannot load 64-bit DLLs Product: Wine Version: 3.0.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: paleozogt(a)gmail.com Distribution: --- Created attachment 62358 --> https://bugs.winehq.org/attachment.cgi?id=62358 wine mono project and binaries Attached is an example project that makes a PInvoke call to a custom native function. It produces HelloWorld.exe (from HelloWorld.cs) and HelloWorld.dll (from HelloworldNative.cpp). If I build a 32-bit HelloWorld.dll, I am able to run HelloWorld.exe in Wine with a WINEPREFIX generated from both WINEARCH=wine32 and WINEARCH=wine64. However, if I build a 64-bit HelloWorld.dll, I am unable to run HelloWorld.exe in Wine with a WINEPREFIX generated from either WINEARCH=wine32 or WINEARCH=wine64. I wouldn't expect WINEARCH=wine32 to work for a 64-bit DLL, but its surprising that WINEARCH=wine64 doesn't work. (With WINEARCH=wine64 I'm otherwise able to run 64-bit native executables without a problem.) The failure looks like this: > >HelloWorld.exe > 002f:err:mscoree:LoadLibraryShim error reading registry key for installroot > > Unhandled Exception: > System.DllNotFoundException: HelloWorld > at (wrapper managed-to-native) HelloWorld.Hello:helloWorld () > at HelloWorld.Hello.Main () [0x00001] in <93c08d3d3d384696aa77bc80f6a731c1>:0 > [ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: HelloWorld > at (wrapper managed-to-native) HelloWorld.Hello:helloWorld () > at HelloWorld.Hello.Main () [0x00001] in <93c08d3d3d384696aa77bc80f6a731c1>:0 It seems like Wine Mono is either running as a 32-bit process or something is wrong with how Wine Mono's PInvoke DllImport searches for compatible DLLs. -- 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 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs February 2021