September 2018 - Wine-Bugs - list.winehq.org

[Bug 41723] New: Install ucrtbase.dll on at least one of the machines
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=41723 Bug ID: 41723 Summary: Install ucrtbase.dll on at least one of the machines Product: Wine-Testbot Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: unknown Assignee: wine-bugs(a)winehq.org Reporter: piotr.caban(a)gmail.com Distribution: --- We have tests for ucrtbase.dll in wine but currently they are never run on testbot. It would be nice to install the dll on at least one of the machines. -- 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 39487] New: Make step dependencies more flexible
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39487 Bug ID: 39487 Summary: Make step dependencies more flexible 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 jobs are split into steps and tasks. * The steps are numbered and must be executed in order. Each step has an associated file. * Each step has one or more tasks which can all be run in parallel. Typically the first step is the build step associated to the patch. It produces the 32 and 64 bit executables for the following steps hence why it has to be executed first. When it fails the other steps are skipped which is not the case for the other steps. So the general structure is: Step 1 - patch.diff - Build Step 2 - test_32.exe - One task per VM Step 3 - test_64.exe - One task per VM So one source of inefficiency is that the 64 bit tests cannot start until all the 32 bit tests have completed. It does not necessarily make the overall job execution longer but it can leave a VM host idle while it waits for the remaining 32 bit tests to complete. And if a developer is watching the job's page he will not know of 64 bit failures until then. So while the build step has to come before all others, that condition should be relaxed for the other steps. The database schema presented in bug 39412 adds a DependencyNo field to the Step table so that step dependencies can be made explicit. This would allow making both test steps depend on build one. Note that with this scheme a given step could not directly depend on multiple other steps but that does not seem needed. It would also make more explicit the fact that test steps cannot be run if the build one fails instead of hard-coding that behavior in Jobs::UpdateStatus(). -- 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 45025] New: Multi-dll patches vs patches website
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=45025 Bug ID: 45025 Summary: Multi-dll patches vs patches website 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 integrates with Wine's patch tracking website by providing it with the job id of the job corresponding to patches that impact the tests. This makes it possible to automatically flag patches that cause new test failures on Windows. https://source.winehq.org/patches/ However when a patch modifies the tests of multiple dlls (for instance d3d8.dll and d3d9.dll) the TestBot creates one job per dll. This cannot work with the patches website which can only deal with one job per patch. In theory putting all the relavant tasks would be doable since there should be no collision between the test executables. The reasons for the current situation are: * The build step only knows how to build one 3é bit and one matching 64 bit test executable. So in the d3d8 and d3d9 case it would be unable to create both d3d8_test.exe and d3d9_test.exe. * Each step in a job implicitly dependended on the previous step. So a failure to build d3d8_test.exe would have caused the d3d9 tests to be skipped too. However this special behavior was specific to the first step so without modification a failure to build the d3d9 test executable in step 2 would likely not have prevented the TestBot from trying to run the d3d9 tests. However now the TestBot supports proper dependencies between steps. So it's possible to have the d3d8 tests depend on the d3d8 build and the d3d9 tests depend on the d3d9 build, and have both be completely independent. There is also progress towards simplifying the build task which would likely make it simpler to deal with building all the test executables in one task. However this would cause all the builds to succeed or fail together because all the other steps would depend on that one build step. So for instance if the d3d9_test.exe build fails, no test would be run even if d3d8test.exe was successfully built. That may be acceptable though since the patch would need to be resubmitted anyway. -- 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 39425] New: Improve resilience to VM host outages
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=39425 Bug ID: 39425 Summary: Improve resilience to VM host outages 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: --- Currently the WineTestBot gets stuck when the connection to the libvirt server on the VM hosts is broken. This includes cases where the libvirt server is restarted, the VM hosts is rebooted or cases where there's a network outage. The reason is that the Engine queries the status of the VMs itself in some circumstances. This creates a TCP connection which is never recreated in case it breaks. The proper fix is to banish all such queries from the Engine: not just to fix this issue but also because some of these operation can be long (a few seconds) and block the main loop of the single-threaded Engine, which can in turn cause the website to lag. -- 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 45682] New: Vulcan support not enabled in build
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=45682 Bug ID: 45682 Summary: Vulcan support not enabled in build Product: Wine Version: 3.14 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: zambien1977(a)yahoo.com In Wine 3.14 which has Vulkan support: https://source.winehq.org/git/wine.git/commit/10035f1b974235e09db8c81d24855… Vulkan games cannot run because it was not enabled in the build: WINEPREFIX=~/.wine-btt/ wine TheBardsTaleTrilogy.exe  ✓  6234  18:36:03 0032:fixme:ntdll:EtwEventRegister ({5eec90ab-c022-44b2-a5dd-fd716a222a15}, 0x1800f9cfc, 0x181438070, 0x181438090) stub. 0032:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x1812bbb48, 43) stub 0032:fixme:ntdll:EtwEventRegister ({5eec90ab-c022-44b2-a5dd-fd716a222a15}, 0x14000107c, 0x140014030, 0x140014050) stub. 0032:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x140012360, 43) stub Mono path[0] = 'C:/GOG Games/The Bard's Tale Trilogy/TheBardsTaleTrilogy_Data/Managed' Mono config path = 'C:/GOG Games/The Bard's Tale Trilogy/TheBardsTaleTrilogy_Data/Mono/etc' 0032:fixme:winsock:set_dont_fragment IP_DONTFRAGMENT for IPv6 not supported in this platform 0032:fixme:win:EnumDisplayDevicesW ((null),0,0x22f218,0x00000000), stub! 0032:fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x22f218,0x00000000), stub! 0032:fixme:win:EnumDisplayDevicesW ((null),1,0x22f218,0x00000000), stub! 0032:fixme:imm:ImmReleaseContext (0x2003a, 0xd05c0): stub 0032:err:vulkan:get_vulkan_driver Wine was built without Vulkan support. 0032:err:vulkan:wine_vk_init Failed to load Wine graphics driver supporting Vulkan. 0032:err:module:find_forwarded_export module not found for forward 'winevulkan.wine_vkGetInstanceProcAddr' used by L"C:\\windows\\system32\\vulkan-1.dll" 0032:err:vulkan:get_vulkan_driver Wine was built without Vulkan support. 0032:err:vulkan:wine_vk_init Failed to load Wine graphics driver supporting Vulkan. 0032:err:module:find_forwarded_export module not found for forward 'winevulkan.wine_vkGetInstanceProcAddr' used by L"C:\\windows\\system32\\vulkan-1.dll" wine: Call from 0x7bc4c138 to unimplemented function vulkan-1.dll.vkGetInstanceProcAddr, aborting 0032:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0032:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0032:err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 0032:err:seh:setup_exception stack overflow 2080 bytes in thread 0032 eip 000000007bc76e41 esp 0000000000130df0 stack 0x130000-0x131000-0x230000 -- 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 44688] New: Detect stuck processes
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=44688 Bug ID: 44688 Summary: Detect stuck processes 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: --- Sometimes a TestBot worker process can get stuck. This can happen to LibvirtTool.pl, particularly when dealing with offline VMs. But it can also happen to regular scripts like WineRunTask.pl when using TestAgent to send or retrieve a file. In both cases the TestBot Engine should have a way to detect stuck processes and simply kill them. To detect stuck processes add two fields to the VM table. ChildStarted - The current child process start timestamp. ChildTimeout - How long the current child process is allowed to run. Most of our tasks already have timeouts so it's just a matter of reusing this timeout and adding some leeway. For the revert and offline tasks we could use 5 and 60 minutes respectively. Then the Jobs::_CheckAndClassifyVMs() method can check those fields and kill the stuck processes. This works because the Engine's SafetyNet() method schedules jobs every 10 minutes as a fallback. The reason for using two fields instead of a single ChildDeadline one is that the ChildStarted field could be useful to know which period to analyze when collecting the Munin statistics (currently we analyze an arbitrary period of time that's supposed to cover the worst case). -- 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 44554] New: The extension xz is not allowed
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=44554 Bug ID: 44554 Summary: The extension xz is not allowed Product: WineHQ Bugzilla Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: bugzilla-unknown Assignee: wine-bugs(a)winehq.org Reporter: bricou.colin(a)wanadoo.fr CC: austinenglish(a)gmail.com Distribution: --- I would like to attach a log file to a WineHQ post. The extension of the file is ".xz" because I had to compress it to reduce his size : 91 Mo ------> 1.3 Mo. But when I try to attach the file, a message apears "The extension xz is not allowed" on the top, just below of the title "Post a reply". So I can't send my log file to solve my problem with the help of others users. You can see the discussion here : https://forum.winehq.org/viewtopic.php?f=8&t=30214&e=0 Thank you, Briceco PS : Sorry, I can't speak or write english very well. -- 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 44187] New: Option to associate screenshots to more than one version
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=44187 Bug ID: 44187 Summary: Option to associate screenshots to more than one version Product: WineHQ Apps Database Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- Wish: I would like an option to associate screenshots from a previous version to a new version This could be done like the "How-to / Note / Warning" checkboxes below the "Descriptions" text area in "Edit Application Note" where a maintainer can choose the versions to display this how-to/note/warning. -- 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 44708] New: Keep past logs if a test is rerun
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=44708 Bug ID: 44708 Summary: Keep past logs if a test is rerun 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: --- In some cases the TestBot reruns a test (currently mostly in case of TestBot error but this could be expanded). When this happens the previous logs are simply discarded when the tqsk is restqrted. It would be better to bundle up the old logs in a single file and make them accessible through a 'Show old logs' link. This would let the developer or TestBot administrator see what the error was and better diagnose issues. -- 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 42179] New: Better detect which tests need to be rerun
by wine-bugs＠winehq.org Nov. 4, 2018

Nov. 4, 2018

https://bugs.winehq.org/show_bug.cgi?id=42179 Bug ID: 42179 Summary: Better detect which tests need to be rerun 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 sometimes does not always know which tests need to be rerun and thus tries to run the test executable with no argument. This typically happens in the following circumstances: * When a non-C file is patched, such as a resource or JavaScript file. * When a test file is removed. This case is actually similar to the previous case where the non-C file is the Makefile.in file. Note however that if there is only one test file this works anyway because in that case the test executable just runs that one test by default. I added some test cases for this in the TestBot test suite: https://github.com/fgouget/wine/tree/wtbsuite -- 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