September 2012 - Wine-Devel

Re: dmusic: Fix a copy and paste error

by Christian Costa

Le 29/09/2012 17:11, Sven Baars a écrit : > This should fix http://bugs.winehq.org/show_bug.cgi?id=31805 > > Good catch !

Sept. 29, 2012

Re: [PATCH] msi: Use next cabinet from the media table instead of failing when there is a mismatch with continuous cabinet.

by Christian Costa

Le 28/09/2012 09:05, Hans Leidekker a écrit : > On Thu, 2012-09-27 at 23:07 +0200, Christian Costa wrote: >>>> if (!(cabinet_file = get_cabinet_filename(mi))) >>> The requirement that the continuous cabinet name matches the next cabinet in the media table >>> might simply be too strict. Perhaps we need to try them one by one and let FDI decide based >>> on the setID and iCabinet fields. Can you please add some tests? >>> >> Does not seem trivial to test this but I will try. > It shouldn't be too hard, we already have some tests for continuous cabinets. > > > Ok. I will take a look.

Sept. 29, 2012

Re: [PATCH] wined3d: move texture reference decrement to end of usage (Coverity)

by Henri Verbeet

On 29 September 2012 11:14, Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, > > I do not fully understand all this, but it seem the decref needs to > be behind the last usage of prev. > Sort of. It's probably better to do it like this, but a non-zero bind_count implies a non-zero reference count as well, so in practice there's no danger of using prev after it's free'd.

Sept. 29, 2012

Re: Fwd: CIA going down: KGB wants your commits!

by Stefan Dösinger

Am Donnerstag, 27. September 2012, 16:10:56 schrieb Austin English: > IRC bots running in > our personal servers listen for SOAP messages sent by kgb-clients Shouldn't you call them kgb-agents? :-)

Sept. 29, 2012

Re: comctl32: use GetWindowLong to check for scrollbar (try 2)

by Nikolay Sivov

On 9/28/2012 20:43, Daniel Jelinski wrote: > Corrected from first try: > - uses GetWindowLong instead of GetWindowLongPtr > - does not touch dwStyle Sorry, was busy to reply earlier. I think this fix is ok if it really helps, thanks for working on this.

Sept. 28, 2012

Re: [PATCH] configure: use -Wp, -D_FORTIFY_SOURCE=0 instead of -D_FORTIFY_SOURCE=0

by Anssi Hannula

28.09.2012 18:14, Alexandre Julliard kirjoitti: > Anssi Hannula <anssi.hannula(a)iki.fi> writes: > >> Some Linux distributions (at least Mageia) build packages with >> -Wp,-D_FORTIFY_SOURCE=2 by default. There is a check in configure which >> checks for enabled fortify and adds "-U_FORTIFY_SOURCE >> -D_FORTIFY_SOURCE=0". Unfortunately, -Wp,-Dfoo are applied after -Dfoo, >> so the added flags fail to override the fortify in the CFLAGS. > > I would say that's a distro bug. Defaulting to Fortify is already broken > enough, but making it even harder to disable is stupid. I don't think > we want to get into that kind of arms race. Well, the intention is probably not to make it harder to override. Mageia uses the -Wp,x form simply because Mandriva and Fedora use that as well (according to logs at http://koji.fedoraproject.org/ ), I'm not sure if Fedora had some good reason to not use -D_FORTIFY_SOURCE=2 originally... IMHO those three distros (esp. Fedora) using -Wp,x is enough justification to add the "-Wp," prefixes to the existing fortify hack in wine configure.ac. However, I do understand and accept your position that it is not really wine's job to override all the weird compilation flags the user might be using. I wouldn't have sent the patch at all if the existing fortify hack hadn't already been there in the configure script :) For the record, Fedora already disables fortify for wine build, and Mageia is currently rolling updated wine packages that have fortify disabled. Mandriva seems to still be affected. No idea if there are more distributions using -Wp,-D_FORTIFY_SOURCE=2 for package builds. -- Anssi Hannula

Sept. 28, 2012

Re: [PATCH] configure: use -Wp, -D_FORTIFY_SOURCE=0 instead of -D_FORTIFY_SOURCE=0

by Alexandre Julliard

Anssi Hannula <anssi.hannula(a)iki.fi> writes: > Some Linux distributions (at least Mageia) build packages with > -Wp,-D_FORTIFY_SOURCE=2 by default. There is a check in configure which > checks for enabled fortify and adds "-U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=0". Unfortunately, -Wp,-Dfoo are applied after -Dfoo, > so the added flags fail to override the fortify in the CFLAGS. I would say that's a distro bug. Defaulting to Fortify is already broken enough, but making it even harder to disable is stupid. I don't think we want to get into that kind of arms race. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2012

Re: gdiplus: Reuse an existing image stream in GdipImageSelectActiveFrame. Take 2.

by Vincent Povirk

Looks good, thanks.

Sept. 28, 2012

Re: [PATCH 2/2] vbscript: Added MonthName implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=21880 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Sept. 28, 2012

Re: gdi32: Fixed freetype working function

by Alexandre Julliard

Сергей Мосин <svmosin(a)gmail.com> writes: > The function WineEngAddFontMemResourceEx in gdi32/fretype.c contained > strange XOR operation with some random number 0x87654321, instead of > returning the real font handle. Do you have an app that depends on this? What does it do with the handle? -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2012