I have been reviewing the TestBot and GitLab CI test results for the
merged MRs. While doing that I updated the TestBot's known failures list
(https://testbot.winehq.org/FailuresList.pl) in order to drive down the
false positive rate.
Incidentally I also collected the list of test units causing false
positives, so I'll start with that. Specifically, here are the bugs to
fix to help the GitLab CI:
* Bug 53433 - mmdevapi:capture - impacted 18 MRs
* Bug 54064 - ntdll:threadpool - impacted 15 MRs
* Bug 54078 - ntdll:pipe - impacted 11 MRs
* Bug 54140 - mmdevapi:render - impacted 5 MRs
* Bug 54005 - ole32:clipboard - impacted 5 MRs
* Bug 54037 - user32:msg - impacted 5 MRs
* Bug 54074 - ws2_32:sock - impacted 5 MRs
I classified the TestBot / GitLab CI results as follows:
* False positive
Cases where the CI system incorrectly claimed the MR introduces new
failures. This is typically the case when the failures that are
already present in nightly WineTest results.
* Bad merge
MRs that break a test and got merged anyway.
* Collateral Damage from a bad merge
The false positives (aka collateral damage) caused by one of the bad
merges above.
* Outside interference
This identifies false positives that are not random and intrinsic to
the test but that result from change outside the Wine infrastructure,
for instance certificates that expire, or configuration changes to
servers that break the tests that depend on it.
Of those the only ones that a CI can really avoid are the first type,
aka "False positive". So I calculated the corresponding weekly rate:
Adjusted False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 21.9% | 8.3%
2022-11-21 | 8.0% | 21.6%
2022-11-28 | 14.7% | 28.4%
2022-12-05 | 8.5% | 24.5%
2022-12-12 | 0.0% | 20.0%
Note that the TestBot's 8% rate for the 11-21 week is not representative
because Wine was broken that week (collateral damage) which prevented
the tests from running in Wine, and thus from contributing real "false
positives". Also the 12-12 week is still incomplete obviously.
Even so I think his shows the TestBot is improving.
Here's a list of the incidents for the weeks above:
* 11-14 An external certificate revocation issue caused crypt32:cert to
fail systematically. This impacted 14 merge requests and was fixed in
MR1360.
* 11-17 MR!1399 got merged despite the TestBot detecting that it
prevented 32-bit Wine tests from running to completion. This impacted
39 merge requests. I could have reduced that number if I had been
faster to reconfigure the TestBot to stop running the full 32-bit Wine
test suite. This was fixed in MR!1524.
* 11-17 MR!1398 got merged despite the TestBot detecting that it broke
ntoskrnl.exe:ntoskrnl on Windows 7. This was fixed in MR!1803.
* 11-22 MR!1495 got merged despite the TestBot detecting that it broke
vbscript:run on Windows *. I don't have a record of the impacted MRs
or of when it was fixed.
* 11-23 The b00a831d direct commit broke kernel32:process in Wine. This
got fixed since.
* 12-07 MR!1732 got merged despite the TestBot detecting that it broke
taskschd:scheduler on Windows *. I immediately added a known failure
entry and no MR got impacted. This was fixed in MR!1736.
If not filtering out the failures caused by these incidents, the false
positive rate is:
Raw False Positive rate
Week | TestBot | GitLab CI
2022-11-14 | 52.1% | 27.1%
2022-11-21 | 50.0% | 29.5%
2022-11-28 | 20.0% | 33.7%
2022-12-05 | 19.1% | 57.4%
2022-12-12 | 0.0% | 20.0%
I think that also shows that the TestBot is improving.
I have attached the raw data I collected and shell snippets to
extract various statistics (failures-mr.txt) as well as a spreadsheet
import (failures.xls).
--
Francois Gouget <fgouget(a)codeweavers.com>
I reviewed the tests that are skipped because the dll is missing on
Windows and I found 4 tests that are never run on Windows which makes
them a bit pointless:
* d3dcompiler_46
I can install version 43 and 47 from dxwebsetup.exe without trouble.
But d3dcompiler_46.dll? No idea.
* d3drm
Is this a deprecated Direct 3D 8 dll? dxwebsetup.exe does not install
it.
* msvcr70
As far as I know this dll is part of the Visual Studio 7.0 runtime.
But that runtime is nowhere to be found.
* msvcrtd
The test look like they succeed on test.winehq.org but in fact all
they do is skip the tests:
debug.c:45: Tests skipped: LoadLibraryA failed to load msvcrtd.dll with GLE=126
(where 126 == ERROR_MOD_NOT_FOUND)
That's the debug version of the Visual C++ C library. As such it's not
shipped by the runtime redistributables. Also, which C runtime does it
correspond to? (iirc it was already there in the 90s)
Note: I'd rather not download these dlls from the many
'not.trojan.horse.dlls.trust.me.com' websites.
VM updates:
* debiant
The gst-plugins-base1.0-dev maintainer intentionally removed
multi-arch support in version 1.20.3-2. As a result GStreamer support
went missing in 32-bit builds when Wine's detection code was tweaked
recently, which in turn caused a lot of new failures (bug 53977).
So I hacked multi-arch support back in and the 32-bit tests are back
to normal.
Another point is that updating the X11 / Mesa packages causes the X
server to crash during the Direct 3D tests. So for now that VM is
frozen in time. That's all worrying for the future Debian 12.
* w11pro64
I added a bunch of Visual Studio C runtime dlls, including msvcr71
which I got through the .Net 1.1 framework. I also added a number of
Direct 3D dlls that don't ship with Windows by default.
* w1064v1709
It seems this snapshot was not entirely idle so I retook it after
Windows Update finished installing the already downloaded
updates (see bug 54158).
This does not seem to have made much of a difference :-(
(particularly for bug 53227)
* w1064v1909
Windows Defender was not disabled and was intefering with the tests
from time to time. That's because 1909 is the first Windows version
where Defender cannot be disabled and where I have to exclude the
WineTest folder instead.
This is fixed now.
* w1064v2004
This snapshot also had some trouble with Windows Update not being idle
so I retook it. This does not seem to have made much of a difference
either :-(
--
Francois Gouget <fgouget(a)codeweavers.com>
Hi all,
I have noticed a "new" issue in Wine Staging that I believe must have
found its way into it in the October to November time frame.
I am heavily using CPython on top of Wine. When Python imports modules,
it looks for them in certain paths, specified in `sys.path`. For
development, it is common practise to symlink a package's folder from
e.g. a git repo into one of the folders contained in `sys.path`, usually
`site-packages`. Python then happily imports the module from there for
e.g. testing. Many tools are built around this workflow.
This used to work with Wine Staging until about September and still
works with stable releases of Wine 7. However, in recent versions of
Wine Staging, 7.22 and 8.0-rc2, the import fails:
```
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "Z:\work\bar\__init__.py", line 1, in <module>
from .subbar import funcbar
ModuleNotFoundError: No module named 'bar.subbar'
```
Python's module import mechanism appears to follow the symlink correctly
(into module "bar") but fails to "locate" stuff within the linked folder
(submodule "bar.subbar"). Other Python code can at least correctly
navigate the linked folder's contents, so I am suspecting a `stat`
syscall of some kind to return unusual values.
Python's import mechanism was rewritten recently, so only versions prior
to Python 3.10 appear to be affected. Many packages support down to 3.7
at the moment.
A minimal reproducer, all steps included:
https://gist.github.com/s-m-e/84d5fbf5663825a46d9ae98e4636d8ec
Wine builds from dl.winehq.org/wine-builds/ubuntu
on Ubuntu 22.04.
I am not sure what I am looking for. How would I debug this from Wine's
side or, in other words, what am I looking for in Wine's logs? Is there
something that I can try as a workaround (other than going back to older
versions of Wine)?
Thanks,
Sebastian
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.0-rc2 (474 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* none
Added:
* None
Updated:
* ntdll-NtDevicePath
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Hello wine-devel,
trying to get more work done on UiRibbon during the holidays, could need some
help regarding planning though.
Short rundown:
uiribbon.dll uses a proprietary binary format to load ribbon structure data.
This is created using UICC.exe (shipped by windows SDK) from a XML markup; the
binary is embedded into the application.
I already reversed the binary format pretty far, and wrote a file format
description.
That file format description uses Kaitai Struct, a declarative language to
generate binary data parsers. Currently I'm working on a Kaitai backend to
generate a C parser.
I'm probably going to create a folder under "libs" called "uiribbon" where
said description and classes generated by kaitai struct (and the runtime) can
lie.
I do believe that leaving the parser/generation up to Kaitai is a good idea,
especially since Wine itself doesn't need to rely on Kaitai. Just need it to
regenerate the parser if the format description is modified.
I hope that's not a problem, because I really want to go the Kaitai Struct
route.
The problem:
Still not sure how to deal with tests. And if we need to use a writer..
I could make a "custom UICC", a program to turn XML markup into the binary
format. Not really useful for applications, but could be a "nice to have" or
useful for tests. Lots of work though.
Problem 1: Windows doesn't ship UICC by default. That means if we need it for
tests, it needs to be installed, or tests won't be able to run.
Problem 2: Windows doesn't really have a parser exposed for the binary markup.
You can load it and it either works, or doesn't - in the worst case the
application simply crashes. Other error cases simply create a broken ribbon,
only displayed completely in black. Not easy to see what's wrong, or test if
it's wrong to begin with.
Although it should probably be possible to extract existing UI elements using
uiautomation. Not sure exactly how useful it is.
Question is how we do the tests:
1) Put markup and according binaries into the tests, write tests against the
binaries to assert what we expect from the written markup. If I recall
correctly, embedding binary blobs wasn't too well received.
2) Put markup into tests. Compile it on windows using real UICC, test the
parser that way (using something like C_SRCS = ../uiribbon_parser.c to have
the parser available in the tests)
3) Compile markup using custom UICC, test the ribbon against windows (using
uiautomation, limited testing only).
Maybe some combination.
Thoughts?
Regards,
Fabian Maurer
On Tue, 13 Dec 2022, Gerald Pfeifer wrote:
> https://wiki.winehq.org/Git_Wine_Tutorial#Deleting_branches has
>
> Deleting branches
>
> git branch -D new-branch
>
> Alas that does not work for me.
>
> % git branch -a
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/dll_soinit.c-stddef.h
:
>
> % git branch -D dll_soinit.c-stddef.h
> error: branch 'dll_soinit.c-stddef.h' not found.
I believe I can now answer my own question, having dug into it a bit.
The invocation above is for *local* branches, branches in the local
checkout.
To remove a *remote* branch, for example where a merge request was not
accepted or was "bad" for some reason, we need to use `git push` instead
of `git branch`:
% git push origin --delete dll_soinit.c-stddef.h
I plan on adding this to the Wiki in a few days.
Any suggestions/concerns?
Gerald
These days I find myself spending more time wrestling with Git/Gitlab than
it takes me to create and test a patch.
So I am keenly interested to help improve
https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab :-)
Here is the first item: I ran
# git clone [email protected]:gerald/wine.git
# git remote add upstream https://gitlab.winehq.org/wine/wine.git
followed by
# git pull --rebase upstream
following https://wiki.winehq.org/Git_Wine_Tutorial#Creating_a_fork_on_Gitlab
And there is where the instructions fail as follows:
# git pull --rebase upstream
From https://gitlab.winehq.org/wine/wine
* [new branch] master -> upstream/master
* [new branch] oldstable -> upstream/oldstable
* [new branch] stable -> upstream/stable
You asked to pull from the remote 'upstream', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
It appears the invocation should be shown as
# git pull --rebase upstream master
instead?
Gerald
PS: I'd volunteer to update the Wiki accordingly if confirmed, alas my
wiki.winehq.org account (GeraldPfeifer) does not appear to exist any
longer? And creating a new one is not possible?
Hi everyone!
It's been some time since our last Wayland driver update ([1]), and,
with the year coming to an end, I wanted to share information about the
progress we made this year and discuss future steps.
The focus in 2022 was on maturing the Wayland driver and keeping up to
date with the Wine upstream internal changes. This involved, among other
things, splitting the driver into a PE and Unix part, updating it for
the latest internal driver APIs, and making preparations to support
WoW64 (we are not there yet, but we are close).
A significant improvement compared to last year is support for
cross-process rendering, which is required by Chromium/CEF applications.
Last year the driver was able to run Chrome with the "--in-process"
command-line option. This year Chrome is supported without any special
flags, fully GPU accelerated on both OpenGL and Vulkan! This was
achieved by implementing what is effectively an internal off-screen
swapchain in the driver's OpenGL and Vulkan integration code, along with
a mechanism to send buffers to other processes for presentation when
needed.
This update also brings enhanced support for the linux-dmabuf v4 Wayland
protocol (aka dmabuf-feedback), which allows compositors to dynamically
send information about optimal formats and modifiers, e.g., depending on
the surface presentation mode (fullscreen vs windowed). Our new
internal OpenGL swapchain can handle such feedback directly, while for
Vulkan we rely on the Wayland WSI to provide this functionality.
This year we also made a lot of smaller scale fixes and enhancements,
that in aggregate have greatly improved driver stability. These were a
result of both testing we performed ourselves, and also of reports from
people trying out the Wayland driver, for which we are very grateful.
All the features listed in our previous update (multi-monitor, display
mode changes, copy-paste, keymaps, relative mouse etc) have been further
refined. One issue for which we haven't yet found a reasonable solution,
is how to properly position the context/right-click menu in the
standalone systray.
The Wayland driver uses the Wayland protocol in a manner that, although
in spec, exercises less well-trodden paths in compositor code.
Throughout the year we have come across a few issues with compositors,
which we have been working with upstreams to address. One issue that
people should be aware of, in particular, manifests as improper relative
mouse motion in first-person 3D games when using the Wayland driver with
some compositors (e.g., see [2]).
TL;DR of how to use the development branch:
$ git clone -b wayland https://gitlab.collabora.com/alf/wine/
$ cd wine
$ ./configure --with-wayland [--with-vulkan]
$ make [-jN]
$ DISPLAY= WAYLAND_DISPLAY=wayland-0 ./wine ...
Especially note the use of 'DISPLAY=', which we use to opt in to the
Wayland driver by disabling the higher priority X11 driver.
Here is a video showing the latest version of the Wayland driver in
action (note that in this video I am using Mutter from git main that
includes the fix for the relative motion issues mentioned above):
https://www.youtube.com/watch?v=lZ-MK72Kyp8
---
Next steps:
Last year, due to the extensive ongoing internal rework in Wine (e.g.,
win32u), the decision was made to postpone the upstreaming of the
Wayland driver until some amount of internal stability had been reached.
My impression is that things are a lot more stable now, from the
drivers' point of view at least. Is there any upcoming work that people
feel would be severely hindered by the upstreaming of the Wayland
driver?
Ideally, I would like to start the upstreaming effort (which I expect
will take some time) at some point early next year, after the codebase
has been unfrozen. Does this sound reasonable?
Thanks,
Alexandros
[1] https://www.winehq.org/pipermail/wine-devel/2021-December/203035.html
[2] https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
Hello,
For a while now I'm curious, so I have to ask: Why is vkd3d an extra project?
Is that because it is reusable as standalone library? Just curious, because
it's the only library in Wine that is a separate project.
Wouldn't it have made sense to develop it as part of Wine to reuse the wine
infrastructure and always have the most recent code for dx12/shaders?
Regards,
Fabian Maurer