wine-devel

wine-devel@winehq.org

11 participants
84462 discussions

Wine staging 9.0-rc3 release
by Alistair Leslie-Hughes 23 Dec '23

23 Dec '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 9.0-rc3 (498 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Added: * None Updated: * None 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 staging 9.0-rc2 release
by Alistair Leslie-Hughes 16 Dec '23

16 Dec '23

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 10 Dec '23

10 Dec '23

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 09 Dec '23

09 Dec '23

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 01 Dec '23

01 Dec '23

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 25 Nov '23

25 Nov '23

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 22 Nov '23

22 Nov '23

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 11 Nov '23

11 Nov '23

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 08 Nov '23

08 Nov '23

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

A case for policy changes to get to zero test failures
by Francois Gouget 31 Oct '23

31 Oct '23

TL;DR; Making lasting progress on fixing the Wine tests requires TBD policy changes to incentivize working on them. While there has definitely been progrees on the Wine tests front lately (and I'm grateful for all the Wine developpers who made it possible), I think there are structural problems that will prevent us from ever getting close to zero failures. Why would a developer work on fixing Wine test bugs? The naive thinking was that they would do so out of pride in the Wine code. Or that they would jump at the chance of fixing issues where all the source is available. But if those where the only factors we would not still have 200 hundred failing test units afer two decades. Another part of the naive thinking was that if developers did not work on the tests it was just because the tools needed to be improved or the test environments were too unreliable. So for a long time all efforts have centered on that. But I think the CI is good enough now to not be the main obstacle [1]. The inconvenient truth is there are forces that discourage working on the Wine tests: * Most developers come to Wine to fix a game or application they want to run, or to add some sexy new functionality. They will prefer to work on these over fixing tests. * Professional developers will be asked to work on issues for paying customers, not fixing tests. * There is a big exception to the source availability: Windows. So figuring out the logic behind the Windows behavior can still be maddeningly frustrating. * 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. * The CI itself can be an obstacle when it systematically reports failures unrelated to the current MR (a warning light that is on all the time is no warning light at all). [3] * The GitLab CI has been allowed to have a 99% failure rate for days on end (see failures-mr.txt in my 2023-10-20 email). That tells the developers that fixing tests is unimportant. There is also nothing to counterbalance that and push developers to work on Wine tests. A developer will not see their patches reverted if they don't fix the failures they introduce. In fact I'm not sure introducing new failures in Wine has any negative consequences. And that's assuming the commit causing the failures is ever identified. Developers fixing tests don't get rewards either. So the conclusion I have come to is that making further and lasting progress will require policy changes to incentivize work on the tests. This touches on the domain of social sciences so there will be no obvious 'right fix'. It's also something I cannot do myself since I don't have any authority to make policy changes. Anyway, here are a few ideas, including some extreme ones, and hopefully we can decide on something that works for Wine: * Revert commits that introduced new failures. - Do it the very next day if the failure is systematic? - What if the failure is random and only happens once a day? Or once a week? - What if the failure does not impact the CI? For instance if the CI has no macOS test configuration and the failure only happens on macOS. - Should only the test part of the MR be reverted? (if that's the cause of the failure) - Who makes the decision to revert? Alexandre? A dedicated person who will catch a lot of flak? * Block an author's new MRs if they did not fix failures introduced by one of their previous commit. - This has the potential to slow down Wine development. - Or the author could request their previous commit to be reverted to get unblocked. * If the CI shows failures, block the MR. - That can still cause the Wine development to halt when the CI has a 100% failure rate (as has been the case for the GitLab CI recently). - So it's only doable if the false positive rate is pretty low. But then it's likely to just result in the developer trying their luck with the next CI run. * If the CI shows failures, require that the author explain why they are not caused by their MR before it can be considered for merging. - The TestBot's new failure lookup tool would be a good way to prove the failure pre-existed the MR. https://testbot.winehq.org/FailuresList.pl - This is a softer version of the previous option and should not block Wine development. It may also push developers to fix the failures out of frustration at having to explain them away again and again since they cannot ignore them. - Reviewers would also be responsible for verifying that the explanations are accurate and for objecting to the merge if not. - Determining if the CI results contain new failures would not longer fall on Alexandre alone. * Have someone dedicated to tracking the source of new failures, reporting them to the authors, following up on the failures, asking for progress on a fix, etc. This would be a developer role bordering on community manager. * Do away with direct commits? (see the 'New failures analysis' email) * Use the Wine party fund to pay developers to fix test bugs. * Send swag to developers who fixed 10 or more test failures. Or set rewards for fixing specific test units like user32:msg, d3d11:d3d11, etc. * Point test.winehq.org/ to the patterns page instead of the index page: the patterns page better reflects the tests progress [4] and thus is less discouraging than the main index page. https://gitlab.winehq.org/winehq/tools/-/merge_requests/71 Suggestions welcome. Hopefully we can figure something out that will get us on the path to zero failures. [1] There are still a few infrastructure improvements that could help: - Fix the TestBot integration with GitLab so its reports don't go into a black hole. At least, while I cannot fix the bridge, I think I can replace it with a better solution. - Allowing to run the tests with WINEDEBUG. - Taking screenshots while the test runs. - Make it easier for developers to replicate the GitLab CI debian environment, build their Wine in it, run the tests, interact with the virtual X server, etc. [2] I will very humbly claim that the wt-test-bisect tool represents a huge step forward on that front when the faiure only happens in full test suite runs. https://gitlab.winehq.org/fgouget/wt-daily/-/blob/bisectors/wt-test-bisect?… [3] Though the GitLab CI false positive rate needs to get better. However my understanding is that the strategy there is to not have the CI try to distinguish false positives from the real issues. Rather my understanding is that it's a two prong approach: 1. Summarily hide unreliable tests by marking them as flaky. 2. Let all the systematic failures annoy the developers so they fix them out of frustration. However this is essentially the naive strategy that was used for years with the TestBot and that only resulted in the developers dismissing and ignoring the CI results. [4] For instance the patterns page makes it clear that there has been progress for Windows 10 1809 whereas that is invisible on the index page. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.

11 14

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-devel