September 2011 - Wine-Devel

Re: winecfg: Remove driver selection from Audio tab.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > The part you forgot is Linux (referring to kernel here) being the most > successful FOSS project, used on super computers, stock exchanges, > banks, etc. While Wine still in it's perpetual alpha-beta state, > limited user base, and not recommended for production use. > > Not saying that AJ's ways are all that bad, but obviously not giving > the same results. Don't you think it's time to change things up a bit? So what do you suggest? -- Alexandre Julliard julliard(a)winehq.org

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by Frédéric Delanoy

2011/9/29 Alex Henrie <alexhenrie24(a)gmail.com>: > 2011/9/28 Frédéric Delanoy <frederic.delanoy(a)gmail.com> >> >> Please do not include bug number in commit message summary line. >> Put something like 'fixes bug 123 in the commit header >> >> See http://wiki.winehq.org/SubmittingPatches for more info (e.g. >> "subject line" and "include a description" sections) > > Thanks for the info. I'll follow those guidelines more closely from now on. > Apologies for submitting the patch twice--the first time I sent it, it > didn't go through. I figured that it didn't work because I wasn't subscribed > to wine-devel, so I subscribed and submitted it again, and then both > attempts went through. In any case, I hope you find the patch helpful and > I'll do better about submitting patches properly in the future. BTW http://source.winehq.org/patches/ show the current patch list. Note however that patches won't be committed (if accepted) until next week since there's wineconf this week-end Frédéric

Sept. 29, 2011

Re: d3dx9_26: Add custom ID3DXEffect interface

by luis.busquets＠ilidium.com

And what about introducing wined3dx to wrap up all d3dx9, d3dx10, ... functions?

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by Alex Henrie

2011/9/28 Alex Henrie <alexhenrie24(a)gmail.com> > I figured that it didn't work because I wasn't subscribed to wine-devel > I meant to say, it didn't work because I wasn't subscribed to wine-patches... -Alex

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by Alex Henrie

2011/9/28 Frédéric Delanoy <frederic.delanoy(a)gmail.com> > Please do not include bug number in commit message summary line. > Put something like 'fixes bug 123 in the commit header > > See http://wiki.winehq.org/SubmittingPatches for more info (e.g. > "subject line" and "include a description" sections) > Thanks for the info. I'll follow those guidelines more closely from now on. Apologies for submitting the patch twice--the first time I sent it, it didn't go through. I figured that it didn't work because I wasn't subscribed to wine-devel, so I subscribed and submitted it again, and then both attempts went through. In any case, I hope you find the patch helpful and I'll do better about submitting patches properly in the future. -Alex

Sept. 29, 2011

Favorite bug: deadlock preventing backtraces?

by Dan Kegel

On one of my boxes, if I run winmm/midi.ok in a loop, it will eventually deadlock/crash ( http://bugs.winehq.org/show_bug.cgi?id=28388 ): err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0022, blocked by 001f, retrying (60 sec) wine: Critical section 00110060 wait failed at address 0x7bc3484a (thread 0022), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0022, blocked by 001f, retrying (60 sec) Sadly, no backtrace follows ( http://bugs.winehq.org/show_bug.cgi?id=28265 ). Since I'm not around when it finally happens, I haven't tried btall yet. I suppose I should write a shell script to watch for that error message in the log, and run btall then... any better ideas? (I did try giving winedbg a private heap, didn't seem to prevent the deadlock.)

Sept. 29, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Scott Ritchie

On 09/28/2011 10:10 AM, Austin English wrote: > On Wed, Sep 28, 2011 at 11:55, Scott Ritchie <scott(a)open-vote.org> wrote: >> On 09/28/2011 05:57 AM, Vitaliy Margolen wrote: >>> On 09/28/2011 04:18 AM, Alex Bradbury wrote: >>>> Do correct me if I'm wrong here, but users who don't want regressions >>>> in their favourite apps/games should be using the stable release. It >>>> doesn't seem fair to complain about regressions being ignored unless >>>> 1.4 releases with a significant number of them. >>> >>> If Wine would release stable versions every 3-4 months sure. But last >>> stable version released on April 8. And only contains small number of >>> fixes since wine-1.2 which was released on July 16. >>> >>> Many programs don't work with wine-1.2.3 for number of reasons. Besides, >>> everywhere (forum, bugzilla, irc) we tell users to upgrade to latest >>> development version, because we not going to fix any bugs in old >>> "stable" versions. >>> >>> >> >> There's a reason I've consistently been advocating for more frequent, or >> even regular, stable releases. We don't need fancy big features to >> justify a release, mere apps working is enough. > > There's no reason you (as a package manager) couldn't choose a > particular development release and mark it as stable in your > distribution. E.g., Fedora does this, currently has wine 1.3.21, > unless you enable updates-testing, which has 1.3.29. > > In any case, I think this topic is best reserved for discussion at > Wineconf, especially since it's not that far away ;). > Yes, I already ship a Wine1.3 package in the install, and it should be the "default" most people find when searching for Wine. But that means users aren't getting the advantage of a real release process here. If that's too involved an effort to do frequently enough for distros to not feel obligated to ship development releases by default, then perhaps we need to discuss a different strategy. In either case, I think we can all agree that more automated continuous testing of git would be a nice thing to have. So I got my daily PPA, Dan's got buildbot, and many of us have been expanding Wine's test suite. I hope to also tie in automated winetricks and winetricks-style application tests to the daily PPA soon as well. Thanks, Scott Ritchie

Sept. 29, 2011

Re: winecfg: Remove driver selection from Audio tab.

by Vitaliy Margolen

On 09/28/2011 11:04 AM, André Hentschel wrote: > Am 28.09.2011 15:09, schrieb Vitaliy Margolen: >> On 09/28/2011 05:31 AM, Michael Stefaniuc wrote: >>> Vitaliy Margolen wrote: >>>> On 09/27/2011 12:17 PM, Michael Stefaniuc wrote: >>>> Wine is driven by wrong objectives. Most developers here don't give much >>>> rip about regressions if the code they've put in is "right". This is >>> Yes, sadly there are Wine developers that consider regressions they have >>> introduced "just normal bugs" which they will fix eventually if they are >> My suggestion would be to revert those "fixes" unless said developers >> willing to fix what they broke. Linus was pretty clear that he won't >> accept patches from such developers. Complete 180 from Alexandre's view. > > Still Linus isn't our projectleader, but AJ. And AJ was pretty clear he > won't do reverts everytime somethings wrong, but will look for a fix. And > AJ does his job for Wine nearly as long as Linus does for Linux and look > where Wine is today, so i don't see the point for quoting Linus in that > discussion. The part you forgot is Linux (referring to kernel here) being the most successful FOSS project, used on super computers, stock exchanges, banks, etc. While Wine still in it's perpetual alpha-beta state, limited user base, and not recommended for production use. Not saying that AJ's ways are all that bad, but obviously not giving the same results. Don't you think it's time to change things up a bit? - Vitaliy

Sept. 29, 2011

Re: [PATCH] Enable X11DRV_DIB_GetImageBits_8 in all cases and optimize X11DRV_DIB_GetNearestIndex to fix bug 2666 and other strange behavior

by Frédéric Delanoy

Please do not include bug number in commit message summary line. Put something like 'fixes bug 123 in the commit header See http://wiki.winehq.org/SubmittingPatches for more info (e.g. "subject line" and "include a description" sections) Frédéric

Sept. 28, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Frédéric Delanoy

On Thu, Sep 29, 2011 at 00:46, Martin Wilck <mwilck(a)arcor.de> wrote: > This is my 4th attempt at fixing the cmd command line treatment. > All patches pass the cmd tests with 0 errors both under wine and > on the Test Bot, including NT. Whitespace issues are fixed, too. > Apart from that, the code is the same as before. > > The size of my patches has been criticized - only patch 2/5 is > really big, but it has to be that way to pass the tests. It's just that the project leader, Alexandre Julliard, generally likes patch as small as possible. YMMV though, and if it's necessary to put it together, it's ok, just indicate it as patch commit "comment" for AJ, if necessary > This will also be my last attempt to get this merged. > If the patches don't get applied this time, I hope that > the cmd Gurus (Frederic or Dan) will take up the bits they > like and get them in over time. If there are any technical issues > or bugs in my code, I'll of course take care (please email me > privately, as I'm not monitoring wine-devel). > > A private side note: I estimate that I have spent at least 10x more > effort and time to get the tests right and the patches > submission-ready than I spent on fixing the actual Wine code. I think that's why Dan pointed that you should probably send a single patch first to avoid reworking the whole series at once, to limit the total amout of effort needed. > I believe > this project needs to think over its policies. I fully understand > that a project this big needs to take a lot of care to maintain > qualitiy standards. But the way this is currently working is > discouraging and frustrating for casual contributors like myself. Yes the "learning curve" is quite steep... I've been bitten by this myself (and cmd test runner wasn't even working properly when I began working on cmd...) BTW if you had issues with the doc regarding patches submissions/testbot (or other things), please tell so we can try to fix that. Anyway, thanks for your patches. TBH I was a bit "scared" to see/fix how the whole quoting stuff is done, after people told how horrific it was. It's nice not to feel being left "alone in the dark" ;) Now that the tests pass, you're just one step further on the way towards patch application. Just need to pass through Alexandre's filter ;) (but since there's wineconf this w-e, there won't probably be any commit rounds until next week) > Martin Wilck (5):

Sept. 28, 2011