Hi,
This last week-end I updated 5 of the test machines, impacting 29 test configurations.
Here's the rundown:
* w1064* w1064 is now called w1064v2009. And w1064 and all the derived snapshots are now running on Windows 10 21H2 (upgraded through Windows Update).
* w10pro64v2004 This snapshot used to have some specific failures most likely because Windows Update was still installing already downloaded updates when I initially took the snapshot (see bug 52560). So I let the VM quiet down and retook the snapshot. That seems to have improved things. I'll know for sure in a few days.
* w10pro64_* w10pro64 had the same issue as w10pro64v2004, plus I needed to install some more languages which requires un-metering the network at which time Windows Update kicks in...
So I applied all updates and retook this snapshot. It's now on the latest 21H1; Windows did not offer installing 21H2 for some reason. It's just as well, this way test.winehq.org can separate the results from this VM with all its locale tests, from those of the w1064 VM which is more about past Windows versions and other configuration options.
Then I let the TestBot recreate all the snapshots for the locale tests. Windows has a bunch of locales: formats, display language, system locale, keyboard layout, country. The old snapshots mostly had the display language right but sometimes the other locales were still stuck on English. The new snapshots are all consistent on that front (whenever possible see below).
In the process I lost w10pro64_pt_PT which the new SetWinLocale have trouble with (yet this works on my test VM so I blame the latest 21H1 updates). I also wanted to add a 'mixed locales' test configuration but the scripts failed this one too. I'll investigate and get those online later on.
* w10pro64_hi_u8 Before Windows 10 it was impossible to set the the system locale to some values. For instance it was impossible to set it to Hindi. So the w10pro64_hi still has English as its system locale unlike the other locale test configurations.
Windows 10 lifted this restriction but this comes with two caveats: - Setting the system locale to values like Hindi is possible but it requires setting the codepage to UTF-8. - This is considered beta and requires checking an extra box in the GUI.
w10pro64_hi_u8 is one such configuration: Hindi through and through with UTF-8 as the codepage. And based on the test results I think they were not kidding with the 'beta' aspect: I count at least 11 tests with UTF-8-specific failures on Windows. Some of these may be because of issues in the test but I'm pretty sure some are Windows bugs we will have to work around.
I would have liked to add another UTF-8 test configuration if only to tweeze out Hindi-specific issues from the UTF-8 ones. I planned to use en-EA for that because it's an all English UTF-8-only locale which could be nice in case there are any error message that need reading... But that's another locale that requires a SetWineLocale tweak.
* cw-gtx560 This is one of the two not-really-TestBot machines with real graphics cards.
I added a Windows 10 21H2 snapshot. Note that again Windows did not want to update it to 21H2 so I used Windows10Upgrade9252.exe to force it. As far as I know the Nvidia driver is unchanged (391.35 iirc). That machine's other snapshots are unchanged.
* cw-rx460 I also added a Windows 10 21H2 snapshot (Windows10Upgrade9252.exe again, the other snapshots are unchanged).
Windows was suggesting I upgrade the GPU driver so I upgraded to the latest Adrenalin 22.4.1 driver. In the past I had trouble with some of the AMD drivers where it would either interfere with the clipboard (causing tests to fail), or crash entirely (causing WineTest to fail entirely).
So consider this new driver to be on probation.
* w7u* I moved this VM from one host to another on 2022-03-14 which is when I found issues with the new LibvirtTool and SetWinLocale scripts so I ended up having to create most snapshots by hand :-( I restored it again from backup to test the corrected scripts and this time all went well.
The last move coincided with some new failures in mf:mf (2qxl only), user32:sysparams and user32:win (2qxl only). It's possible the 2qxl issues are because the VM is powered on for each test instead of starting from a live snapshot: I suspect Windows 7 did not correctly handle the multi-monitor setup when restored from a live snapshot. This will require some more investigation...