May 2026 - Wine-Devel - list.winehq.org

Re: GitLab merge warnings

by Alexandre Julliard

"Alex Henrie" <alexhenrie24(a)gmail.com> writes: > Can we please update gitlab.winehq.org to GitLab 19.0 and enable > automatic rebase on all of the WineHQ projects? Since few people are > allowed to merge MRs and none of you seem to actually do merges via > the GitLab UI, the change should be purely cosmetic and not affect > your workflow at all. I've upgraded to Gitlab 19 and changed the setting, we'll see how it goes. Thanks for the suggestion! -- Alexandre Julliard julliard(a)winehq.org

May 30, 2026

Wine staging 11.10 release

by Alistair Leslie-Hughes

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 11.10 (287 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None Removed (No longer required). * None Added: * [45364] - Frostpunk is very dark * [57980] - kernel32: Implement SetThreadpoolTimerEx. * [43703] - rtscom: Rebelle demo crashes when using "Microsoft Ink compatible" tablet * [31554] - inkobj: PDF Annotation crashes on second startup Updated: * vkd3d-latest * dcomp-DCompositionCreateDevice2 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.

May 30, 2026

Re: GitLab merge warnings

by Henri Verbeet

On 26/05/2026 07.05, Alex Henrie wrote: > Currently, unless a merge request is based on the absolute latest > upstream master branch, GitLab displays the following warnings: > > ⛔ Merge blocked: 1 check failed > ⛔ Fast forward merge is not possible. Please rebase. > > More than once, I've seen well-meaning contributors follow those > instructions and rebase their merge requests every single day to > resolve the warning. That adds pointless noise to the merge request > and wastes time rerunning the test suite. > > GitLab 19.0 introduced a new feature to suppress those warnings, > called "automatic rebase".[1] To enable it, a GitLab administrator > needs to go to the project Settings, click "Merge requests", under > "Fast-forward merge" check the box "Enable automatic rebase prior to > merge", and click "Save changes". > > Can we please update gitlab.winehq.org to GitLab 19.0 and enable > automatic rebase on all of the WineHQ projects? Since few people are > allowed to merge MRs and none of you seem to actually do merges via > the GitLab UI, the change should be purely cosmetic and not affect > your workflow at all. It's not up to me, but I don't immediately see an issue with that. I can't say excessive rebasing of MRs has been much of an issue for vkd3d either though. Henri

May 28, 2026

Re: Feedback needed for a theme PR

by fatihbakal7＠protonmail.com

>If scripting is considered too inconvenient then replacing default (aero) theme for wine/launcher install directory is easier I have multiple wine/proton builds for games (latest ge-proton, older ge-proton,default proton, wine). Not to mention whenever launchers update said builds the modification would be lost. Heroic games launcer/lutris/protonplus/protonup-qt all update to latest versions as they should (this is still a hassle as to there will be cases where the wine/proton build will update and the theme file you replaced will be overwritten meaning you gotta do it again) > Do you have examples of some games where the theme matters more? All wine applications (explorer, taskmgr, regedit) cheat engine, some adobe apps, the file import/export dialogs, all qt apps (the boolean switch for dark theme) What about making it so that it uses whatever is theme inside `~/$USER/.config/wine/` if there is something there. And also an env var WINE_IGNORE_GLOBAL_THEME that can be set to 1 to ignore the theme in `~/$USER/.config/wine/` ? This seems like a reasonable approach to me. I'll start working on it if you guys think it's reasonable as well

May 27, 2026

Re: Feedback needed for a theme PR

by Ty

I think the approach of referencing a file in ~/$USER/.config may work, with added functionality for ignoring the global being an absolute must, in the event it breaks something for that game/software. perhaps a file added to the prefix that wine checks if exists, and if so then ignores the users .config settings, or an envvar that ignores the users .config settings? frankly, having both options to opt-out of the global theming would be better for compatibility of management tools(launchers/scripts). Adding an envvar to every prefix to opt-in seems time consuming and tedious, at that point you almost might as well change the theme per prefix. common practice is definitely a prefix per software/game. keeps things santised, separated, not conflicting, allows different runners or dependencies to be used for compatibility. A lot of launchers like lutris make a new prefix per game. Other times you end up with small projects(like one of mine) for odd games that really don't like to run right, where we create a prefix via script and have wine versions modularly plugged into the prefix. The latter is definitely a bit dirty, but is fantastic for rapid testing and portability. Certainly it could be changed such that launchers/installer scripts set envvars or files placed in the prefix, but that would leave users at the mercy of their launcher or install method to support it. On Wed, May 27, 2026 at 4:53 AM Stian Low via Wine-Devel < wine-devel(a)list.winehq.org> wrote: > > Again defeats the whole point (idk how id even script it tbh) launchers > usually create a new prefix whenever you add in a new game. Most launchers > (Heroic & lutris which are the most used ones) seem to be against adding > this auto theme change thing. I could make something that's listening for > new prefixes 7/24 to apply themes but that's just overkill. > > If scripting is considered too inconvenient then replacing default (aero) > theme for wine/launcher install directory is easier: > https://bugs.winehq.org/show_bug.cgi?id=59739#c26 > > Downside is it only copies themes for new prefixes so old prefixes would > still need to be manually replaced, same as for wine/installer. > > Having to replace wine/installer theme each time between upgrades may also > be considered another one-time inconvenience. > > All recommendations so far seem to require time or skill level considered > too inconvenient for end users. > > Emacs makes file search/replace of themes as trivial as scripting but both > are less common among end users. > > Therefore it seems the level of ease sought is for game launchers to be > started with some WINE_THEME_ENVVAR to be applied to each wine call they > make to launch games. ENVVAR option has the goal of avoiding having to > make changes for each game manually within the launcher which is considered > as inconvenient as performing file replacements of themes per existing wine > prefixes. > > Therefore adding an ENVVAR seems to be the clearest option to achieve such > a level of ease. If so, is the level of effort worth it compared to > existing (maybe less convenient) solutions? I do not know. > > I need to familiarize myself with launchers because I only use vanilla > wine to test games and only involve launchers when bugs are created for > them. ENVVAR does seem to offer a universal solution so that each launcher > would not require their own custom theme setting conveniences to relieve > end users of whatever burden is considered too much. > >

May 27, 2026

Re: Feedback needed for a theme PR

by Stian Low

> is the level of effort worth it compared to existing (maybe less convenient) solutions? Regarding level-of-effort vs time-worthiness: How common/edge-case are Windows themes for games? Many games I've tested do not even show a UI that reflects themes but seem more common for older games. GOG The Witcher for example is fairly old but handles its own rendering even for its launcher. Do you have examples of some games where the theme matters more?

May 27, 2026

Re: Feedback needed for a theme PR

by Stian Low

> Again defeats the whole point (idk how id even script it tbh) launchers usually create a new prefix whenever you add in a new game. Most launchers (Heroic & lutris which are the most used ones) seem to be against adding this auto theme change thing. I could make something that's listening for new prefixes 7/24 to apply themes but that's just overkill. If scripting is considered too inconvenient then replacing default (aero) theme for wine/launcher install directory is easier: https://bugs.winehq.org/show_bug.cgi?id=59739#c26 Downside is it only copies themes for new prefixes so old prefixes would still need to be manually replaced, same as for wine/installer. Having to replace wine/installer theme each time between upgrades may also be considered another one-time inconvenience. All recommendations so far seem to require time or skill level considered too inconvenient for end users. Emacs makes file search/replace of themes as trivial as scripting but both are less common among end users. Therefore it seems the level of ease sought is for game launchers to be started with some WINE_THEME_ENVVAR to be applied to each wine call they make to launch games. ENVVAR option has the goal of avoiding having to make changes for each game manually within the launcher which is considered as inconvenient as performing file replacements of themes per existing wine prefixes. Therefore adding an ENVVAR seems to be the clearest option to achieve such a level of ease. If so, is the level of effort worth it compared to existing (maybe less convenient) solutions? I do not know. I need to familiarize myself with launchers because I only use vanilla wine to test games and only involve launchers when bugs are created for them. ENVVAR does seem to offer a universal solution so that each launcher would not require their own custom theme setting conveniences to relieve end users of whatever burden is considered too much.

May 27, 2026

Re: GitLab merge warnings

by Alex Henrie

On Tue, May 26, 2026 at 2:16 PM Esme Povirk <esme(a)codeweavers.com> wrote: > > If it matters, I actually do use the GitLab UI to do merges. > > However, the GitLab UI discourages using it for rebases, linking to this > page: > https://gitlab.winehq.org/help/ci/pipelines/merge_request_pipelines.html#ru… > > Therefore, I do not use the GitLab UI to do rebases. Does the new > version address this somehow? If I understand that page correctly, it's just saying that merge requests can introduce malicious code that is run as part of the test suite before the merge request is actually merged. GitLab is just trying to warn you to not do test runs on untrusted code, and warn you that you clicking "Rebase" will automatically trigger a test run even if the merge request's author does not have permissions to do a test run. If you want to rebase without doing a test run, there is a separate "Rebase without pipeline" button on the merge request. The "automatic rebase" option that I'd like to enable effectively clicks "Rebase without pipeline" for you when you click "Merge".[1] I think the new option would be perfect for your workflow. -Alex [1] https://docs.gitlab.com/19.0/user/project/merge_requests/methods/#automatic…

May 27, 2026

Re: Feedback needed for a theme PR

by fatihbakal7＠protonmail.com

> For shared themes, you can already achieve your goal by scripting things, e.g., by regedit to set the default theme. Again defeats the whole point (idk how id even script it tbh) launchers usually create a new prefix whenever you add in a new game. Most launchers (Heroic & lutris which are the most used ones) seem to be against adding this auto theme change thing. I could make something that's listening for new prefixes 7/24 to apply themes but that's just overkill. > However, they sort of break here and there. I have a prefix which I have set the theme manually and everything I use (explorer, cheat engine, taskmgr, regedit..) works and looks good. > unless we have more working themes There is a chance people will start doing more themes focused for wine (https://github.com/listumps/wine_themes) if some sort of global theme option is added. (I sure will) > which can be done via adding support for parsing Win7/10 era themes for example. Can be done afterwards in my opinion as even when support for that is added the same having to apply it manually issue will still be a thing.

May 26, 2026

GitLab merge warnings

by Alex Henrie

Hello Wine maintainers, Currently, unless a merge request is based on the absolute latest upstream master branch, GitLab displays the following warnings: ⛔ Merge blocked: 1 check failed ⛔ Fast forward merge is not possible. Please rebase. More than once, I've seen well-meaning contributors follow those instructions and rebase their merge requests every single day to resolve the warning. That adds pointless noise to the merge request and wastes time rerunning the test suite. GitLab 19.0 introduced a new feature to suppress those warnings, called "automatic rebase".[1] To enable it, a GitLab administrator needs to go to the project Settings, click "Merge requests", under "Fast-forward merge" check the box "Enable automatic rebase prior to merge", and click "Save changes". Can we please update gitlab.winehq.org to GitLab 19.0 and enable automatic rebase on all of the WineHQ projects? Since few people are allowed to merge MRs and none of you seem to actually do merges via the GitLab UI, the change should be purely cosmetic and not affect your workflow at all. -Alex [1] https://gitlab.com/gitlab-org/gitlab/-/work_items/895

May 26, 2026