https://bugs.winehq.org/show_bug.cgi?id=50779
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |90107bba944a1da286e9ebd246a | |b3fd5dd7cb115 Component|-unknown |winegstreamer
--- Comment #25 from Zeb Figura z.figura12@gmail.com --- (In reply to Rafał Mużyło from comment #23)
What part of this is infeasible?
Short version: fuck you, that's why.
Rafał, I'm sorry to be short with you.
On the other hand, it's hard to have much patience when you waste people's time like this. This is a recurring pattern: you make guesses and assumptions with little relevance to the code, which often turn out to be wrong; you ask people directed questions about these guesses which end up having nothing to do with your application; you refuse or ignore requests for bisects, logs, backtraces, or even the name of the application that you're reporting bugs against.
Longer variant:
- 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
So don't keep it around? Cloning isn't instant, sure, but if you're concerned about space it seems like a worthwhile tradeoff.
Admittedly this also didn't occur to me since earlier comments here (comment 18) had implied you already had a wine tree available.
I understand that bisecting takes a lot of time; I don't really want to fault anyone for not being able to do a bisect. But for someone who's already built wine, I feel like asking for one build is not unreasonable.
Especially when the implicit expectation, with this kind of bug report, seems to be "please examine all of the winegstreamer commits between 6.0 and 6.1 for errors". That's not a reasonable request for a developer.
Examining a single commit for errors is a lot closer to feasible. Examining a single commit, with appropriate debug logs, is solidly within the realm of feasibility. Being able to test the program myself all but assures it'll get fixed.
- 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
A quick Internet search implies that Gentoo ships a mingw-w64 toolchain. All that should be necessary to build Wine is to have that toolchain and compiler installed and available; our configure script will do the rest. I haven't used Gentoo, and maybe there are bugs that cause it to be broken in subtle ways, but it would be a lot more productive for me to spend that effort on helping to fix those bugs so that Gentoo users can effectively test wine.
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.
Thank you, that's useful information. Can you please attach a log with WINEDEBUG=+quartz,+timestamp,+seh,+pid GST_DEBUG=6 ?