https://bugs.winehq.org/show_bug.cgi?id=50779
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl ---
What part of this is infeasible?
Short version: fuck you, that's why.
Longer variant:
1. keeping wine git around is quite annoying when you're not working with it constantly 2. if you need some patches on top of the tarball/git tree, bisect becomes far less automatic 3. I'm not sure I'd be able to pull off non-mingw wine build outside portage and nearly sure I'd botch a mingw one 4. there might be other issues (more on that later)
So as I've said, for reasons.
Having said that, fortunately I've still had the old ebuild for 6.1 and its patches. With some elbow grease and both live ebuild framework and the ebuilds for additional wine variants, I've managed to put together something that won't inconvenience me *too* much.
So, those other issues... In this instance, I needed a far later 'msvcrt: Add sincos to importlib' commit to get things to build at all.
Then I've started looking for the commits behind the problem...and it's a bit more complicated than I thought.
I was right about the patchset, if not about particular commit.
With wine 6.0, VM consumption starts a bit below 3300M, then with the test procedure mentioned earlier rises quite quickly to 3500M, then much more slowly and quite randomly might reach 3700M.
This holds true till 'winegstreamer: Keep the stream in paused state for its entire lifetime'. Now, it rises quickly (seemingly faster than before) to nearly 4000M, but it may take awhile till it goes over and triggers a freeze. So I was kind of right about things getting stuck somewhere - they were, deliberately so.
The process is finalized with 'winegstreamer: Manage our own thread for read requests'. Now, within less than 20 seconds, the procedure leads to a freeze. Comment on that commit sounds a bit ironic in this context.