- Wine-Devel - list.winehq.org

Wine staging 9.0-rc2 release
by Alistair Leslie-Hughes Dec. 16, 2023

Dec. 16, 2023

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc2 (498 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * [45455] setupapi: Add stub for DriverStoreFindDriverPackageW. * [55282] where: Implement search with default options. Updated: * vkd3d-latest to latest. 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.

1 0

Code freeze for Wine 9.0
by Alexandre Julliard Dec. 10, 2023

Dec. 10, 2023

Folks, With the end of the year approaching, it's time to start preparing for the 9.0 stable release. We'll follow the same schedule as every year, with code freeze in early December, and a final release sometime in January. This year, the code freeze period will start on December 8th. So if you have things that you'd like to see included in 9.0, make sure to submit them soon, so that there's enough time for review before code freeze starts. -- Alexandre Julliard julliard(a)winehq.org

1 1

Wine staging 9.0-rc1 release
by Alistair Leslie-Hughes Dec. 9, 2023

Dec. 9, 2023

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc1 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * bcrypt: Allow multiple backends to coexist. * bcrypt: Implement BCryptSecretAgreement with libgcrypt. * bcrypt: Implement BCRYPT_KDF_HASH. Added: * None Updated: * vkd3d-latest to latest. * ntdll-DOS_Attributes * mfplat-streaming-support * ntdll-ForceBottomUpAlloc 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.

1 0

Wine 8.0.2 fails to create a window
by volker.schlegel＠tutanota.com Dec. 1, 2023

Dec. 1, 2023

Hello everyone,I've recently switched from Manjaro to Mint, and just installed WINE again.Latest stable release, 8.0.2, from the wineHQ repos.Any application trying to create a window seems to crash.Example crash dump (new prefix): https://pastebin.com/T6WG9EhQ Since it seems to be a graphics issue, here is the output of inxi -G: https://pastebin.com/SvURv3fYWhile searching for a fix I stumbled across this bug, might be related? https://bugs.winehq.org/show_bug.cgi?id=51210"Deactivate your GPU" isn't really a solution though in my opinion.I'd try to actually fix it myself (I've built wine myself before, and I have written quite a bit of C code), but I've never used Vulkan or OpenGL, so any help is appreciated!

1 0

Wine staging 8.21 release
by Alistair Leslie-Hughes Nov. 25, 2023

Nov. 25, 2023

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.21 (491 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * vkd3d-latest to latest. 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.

1 0

GCC 4.3 support and language features
by Fabian Maurer Nov. 22, 2023

Nov. 22, 2023

Hello wine-devel, I wanted to follow up on the discussion on https://gitlab.winehq.org/wine/ wine/-/merge_requests/3059 For those not in the loop: The question came up what GCC version is the oldest supported one, and which language features can't be used in Wine. Is there already a wiki entry on this? Associated bug report: https://bugs.winehq.org/show_bug.cgi?id=54601 (Compilation fails with gcc 4.3.4 (error: unknown field ‘Type’ specified in initializer) I have a bunch of gcc 4.3 patches, and if it's supported, I think it would be useful getting those in before the next stable. Although ongoing gcc 4.3 support is probably a bit of work, since most people don't test against gcc 4.3 compatibility so there's some "regressions" from time to time. An option would be to just patch it when someone complains, which would be the most reasonable to me. Or just cap it at 4.8 which currently works. In the end, some compiler will be too old, so where is the line? In a similar vein, what about https://bugs.winehq.org/show_bug.cgi?id=20474 (Wine can't be built with GCC in C99 mode) Is this a supported setup? IMHO itwould be too much effort work to get this working, but I don't make the decisions. Regards, Fabian Maurer

8 9

Wine staging 8.20 release
by Alistair Leslie-Hughes Nov. 11, 2023

Nov. 11, 2023

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.20 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * winemenubuilder: Create .desktop files for programs that open URIs. * winecfg: Mention protocol associations. Added: * None Updated: * vkd3d-latest to latest. 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.

1 0

Upcoming vkd3d 1.10 release
by Henri Verbeet Nov. 8, 2023

Nov. 8, 2023

Hi all, The planned release for vkd3d 1.10 is about 4 weeks away. As usual, that means the development branch will become increasingly frozen as we're nearing release. If you're an upstream vkd3d developer, please do the following: - Keep an eye on Bugzilla for any reported regressions. - Review any API changes since the previous release. - Verify all the vkd3d tests pass on your hardware, and please send fixes if they don't. - Review and improve the documentation. - Apply your best judgment about which patches are appropriate for the current stage of the release process. If you're a downstream user of vkd3d, please test your applications for regressions, and file bug reports if you find any. If you're the maintainer of a Wine module that (indirectly) depends on vkd3d, like e.g. d2d1, d3dx9, d3dcompiler, or any of the core Direct3D modules, that includes making sure the unit tests still pass with the new version. The planned release date for the release following vkd3d 1.10 is currently sometime in March. Regards, Henri

1 0

Re: A case for policy changes to get to zero test failures
by Francois Gouget Oct. 31, 2023

Oct. 31, 2023

On Mon, 23 Oct 2023, Francois Gouget wrote: [...] > So the conclusion I have come to is that making further and lasting > progress will require policy changes to incentivize work on the tests. * The goal is to get rid of the TestBot so the bridge to GitLab will not be restored in any form. There will also be no further TestBot development. * Wine developers are on their own to figure out if their commits cause new failures, and if they do they are on their own to figure out how to reproduce the issues. * The other policy changes are still to be determined. -- Francois Gouget <fgouget(a)codeweavers.com>

2 1

Re: A case for policy changes to get to zero test failures
by Giovanni Mascellani Oct. 30, 2023

Oct. 30, 2023

Hi, Il 23/10/23 14:29, Francois Gouget ha scritto: > * Replicating failures can sometimes be frustratingly hard. Even if you > happen to have access to the CI environment! [2] > > * And usually one does not have access to the CI environment. That's the > the case for the Windows environments for licensing reasons. On the > Linux side the GitLab CI should mean progress but replicating it needs > to be made much simpler before that's effective. In the meantime that > means no debugger, no watching what happens on screen while the test > runs, little poking into the test environment entrails (short of > writing a dedicated program to do the poking), etc. In short it's > remote debugging. This is indeed a pain point. So much that at some point I even began to write a tentative solution to that, which so far I have only shared inside CodeWeavers. There is in fact (as far as I am aware) no reason why it should not be made available publicly, so here it is, I just released it: https://gitlab.winehq.org/giomasce/minitestbot Here is the train of thoughts that brought to MiniTestBot: * As you say, accessing the TestBot/CI environment is hard: the interface is limited and people have to share the available time, so if many people are hitting the TestBot/CI at the same time they have to wait for each other's job, which can be frustrating. * Much better it would be if you could run the TestBot/CI's environment directly on your hardware. Then you don't compete with others anymore and you can interact with your VM however you please, including changing settings and installing stuff. * As you say, the problem is that we can't just distribute Windows images. But we can distribute the scripts used to generate them, which is essentially what MiniTestBot does! The MiniTestBot user needs to independently provide the Windows ISO (Microsoft distributes them for free, at least for some Windows versions) and is directly responsible for complying with licenses, while distributing the scripts does not infringe any copyright, as they are all free software and free of Microsoft intellectual property. Though I am not a lawyer, so don't take this as legal advice! :-) * If the TestBot/CI used images generated with these scripts (or, rather, what they would become after having made better) we'd have both the possibility to run tests in the cloud, which is handy for many reasons, and the possibility to run them on premises in the same environment, which is handy in other cases. I hope that would help to remove at least some of the frustration of debugging tests on Windows. In practice MiniTestBot is a few scripts that take a Windows image and (nearly) automatically create an image out of it, together with other scripts to submit job to be automatically be executed inside that image, TestBot style. It is really a proof of concept at this stage, but I'm already finding it useful for development. At least another person in CodeWeavers told me they find it useful. It would require some more work to be integrated in the TestBot/CI, but that work shouldn't be impossible to do. What do you think of this approach? Also, I am happy to receive comments, suggestions and MRs (yes, those too!) for MiniTestBot. Gio.

1 0