October 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] gdi32: Add a string table resource for the translation.
by Alexandre Julliard Oct. 19, 2011

Oct. 19, 2011

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > @@ -1,7 +1,7 @@ > EXTRADEFS = -D_GDI32_ > MODULE = gdi32.dll > IMPORTLIB = gdi32 > -IMPORTS = advapi32 > +IMPORTS = advapi32 user32 You don't want to import user32 from gdi32. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks (try 2)
by Henri Verbeet Oct. 19, 2011

Oct. 19, 2011

On 18 October 2011 12:43, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Changes: Check for dynamic texture support, moved the format-specific tests to > this patch. > That's not really what I meant with "make this part of the test in patch 3/7". The point is that test_lockrect_offset() is about the offset calculation, not so much about what valid rectangles for block based formats are. And it probably wouldn't hurt to run test_partial_block_lock() on the other formats like e.g. ATI2N anyway.

2 5

Re: [PATCH] kernel32: Output message to stderr in UTF-8
by Dmitry Timoshkov Oct. 19, 2011

Oct. 19, 2011

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > - WideCharToMultiByte( CP_ACP, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > + WideCharToMultiByte( CP_UTF8, 0, msgW, -1, msg, sizeof(msg), NULL, NULL ); > MESSAGE( "wine: %s", msg ); Try CP_UNIXCP intead. -- Dmitry.

1 0

Re: 80121: aclocal.m4: fix compiles on systems that don't support ln -s
by Austin English Oct. 18, 2011

Oct. 18, 2011

On Tue, Oct 18, 2011 at 16:34, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/678 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [avifile.dll16.so] Error 2 > make: *** [dlls/avifile.dll16] Error 2 > make: *** Waiting for unfinished jobs.... Hm, worked here, though trying it again with plain make rather than make -jX, fails. Needs more investigation. Please don't commit. -- -Austin

1 0

Odd valgrind warning on ubuntu 11.10 related to set_wm_hints
by Dan Kegel Oct. 18, 2011

Oct. 18, 2011

I've added a suppression for this already to http://code.google.com/p/winezeug/source/browse/trunk/valgrind/valgrind-sup… It looks benign, but it's annoying because the suppression it needs is so wide. I wonder if the gcc bug on ubuntu 11.10 is why there's no useful backtrace there... Syscall param writev(vector[...]) points to uninitialised byte(s) at writev (writev.c:51) by 0x40004: ??? Address 0x4598748 is 160 bytes inside a block of size 16,384 alloc'd at calloc (vg_replace_malloc.c:467) by XOpenDisplay (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0) by x11drv_init_thread_data (x11drv_main.c:689) by thread_init_display (x11drv.h:580) by X11DRV_create_win_data (window.c:2030) by X11DRV_WindowPosChanging (window.c:2429) by set_window_pos (winpos.c:1951) by USER_SetWindowPos (winpos.c:2077) by SetWindowPos (winpos.c:2151) by show_window (winpos.c:1088) by ShowWindow (winpos.c:1186) by WIN_CreateWindowEx (win.c:1498) by CreateWindowExA (win.c:1550) by init (comboex.c:505) by func_comboex (comboex.c:598) by run_test (test.h:556) by main (test.h:624) Uninitialised value was created by a stack allocation at set_wm_hints (window.c:1128)

1 0

Re: registry keys of serial ports
by Uwe Bonnes Oct. 18, 2011

Oct. 18, 2011

Hello, while hunting down why a drop down box didn't offer me the serial port I configured, I stumbled across Stefans proposal from Summer 09. The patch still applied cleanly, and after setting up hal and the hal development library, the progarm worked as expected. What is the status of that proposal? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: po: Update English (US) translation
by Alexandre Julliard Oct. 18, 2011

Oct. 18, 2011

Ken Sharp <kennybobs(a)o2.co.uk> writes: > From 68519bf26da3d912bf92febc13a34ec00cfd7cc4 Mon Sep 17 00:00:00 2001 > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Sat, 15 Oct 2011 03:50:43 +0100 > Subject: [PATCH] po: Update English (US) translation There's no translation to update, the rc files are already en_US. If the strings need changing they have to be changed in the rc files. -- Alexandre Julliard julliard(a)winehq.org

4 10

Re: mshtml: Added IHTMLDocument2::elementFromPoint implementation
by Marvin Oct. 18, 2011

Oct. 18, 2011

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=14979 Your paranoid android. === TEST64_W7SP1 (32 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY" === TEST64_W7SP1 (64 bit htmldoc) === htmldoc.c:2865: Test failed: unexpected cmd 109 of CGID_Explorer htmldoc.c:4446: Test failed: tag = L"BODY"

2 1

Re: vbscript: Added support for hex literals not ending with '&'
by Marvin Oct. 18, 2011

Oct. 18, 2011

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=14970 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

1 0

Re: [4/7] wined3d: YUY2 and UYVY are block based
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 23:05, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + BOOL gl_compressed; I think the "gl_" prefix is somewhat questionable since the format being compressed or not is a property of the D3D format, it doesn't depend on what GL format we use, at least in the way the flag is currently used. You can change the meaning of the flag to be specific to the GL format, but then you'd have to set it in the format_texture_info[] table. > static const struct wined3d_format_compression_info format_compression_info[] = > { > - {WINED3DFMT_DXT1, 4, 4, 8}, > - {WINED3DFMT_DXT2, 4, 4, 16}, > - {WINED3DFMT_DXT3, 4, 4, 16}, > - {WINED3DFMT_DXT4, 4, 4, 16}, > - {WINED3DFMT_DXT5, 4, 4, 16}, > - {WINED3DFMT_ATI2N, 4, 4, 16}, > + {WINED3DFMT_DXT1, 4, 4, 8, TRUE }, > + {WINED3DFMT_DXT2, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT3, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT4, 4, 4, 16, TRUE }, > + {WINED3DFMT_DXT5, 4, 4, 16, TRUE }, > + {WINED3DFMT_ATI2N, 4, 4, 16, TRUE }, > + > + {WINED3DFMT_YUY2, 2, 1, 4, FALSE }, > + {WINED3DFMT_UYVY, 2, 1, 4, FALSE }, > }; If you decouple "block-based" and "compressed", it doesn't make sense anymore to set them in the same table like this. The "compressed" property should go to either the format_texture_info[] or the format_base_flags[] table, depending on whether it's considered a basic property of the format, or specific to the GL format we use for it. > + /* Block-based formats can't be rendered to with FBOs even if GL accepts them > + * (e.g. WINED3DFMT_YV12, which is just a GL_ALPHA texture). Even fragment shaders > + * can't account for that if a block is partially drawn. There's no such restriction on the GL side, the internal format just has to be color-renderable. The reason we can't render directly to these is because there a fixup associated with the format, but that has nothing to do with either being FBO-attachable or being block-based, and applies to e.g. P8 as well. > + * > + * Furthermore some drivers crash instead of generating an error if we attempt to > + * attach s3tc textures to an FBO */ This was an issue with some versions of fglrx, but should be fixed in current versions.

2 3

Still need patch review please (wineps.drv)
by Daniel Santos Oct. 17, 2011

Oct. 17, 2011

Of particular concern is making sure my dynamically allocated memory is being freed. The new data is stored in PSPEN and is allocated when SelectObject (on a wineps.drv device of course) passing a pen and is freed whenever a subsequent pen is selected or the device context is deleted. I'm just not intimately familiar enough with this part of the API to know for certain that this eliminates all room for leaks. Thanks! Daniel

1 1

Re: ntdll: avoid buffer overrun in lookup_manifest_file
by Alexandre Julliard Oct. 17, 2011

Oct. 17, 2011

Dan Kegel <dank(a)kegel.com> writes: > @@ -1877,7 +1877,7 @@ static WCHAR *lookup_manifest_file( HANDLE dir, struct assembly_identity *ai ) > if (build == min_build && revision < min_revision) continue; > tmp = strchrW(tmp, '_') + 1; > tmp = strchrW(tmp, '_') + 1; > - if (!strcmpiW( tmp, wine_trailerW )) > + if (!strncmpiW( tmp, wine_trailerW, dir_info->FileNameLength/sizeof(WCHAR) - (tmp - dir_info->FileName) )) That doesn't do the same thing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: vbscript: Added lexer support for '_'
by Bruno Jesus Oct. 17, 2011

Oct. 17, 2011

On Fri, Oct 14, 2011 at 13:44, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/vbscript/lex.c | 10 ++++++++++ > dlls/vbscript/tests/lang.vbs | 7 +++++++ > dlls/vbscript/tests/run.c | 2 ++ > 3 files changed, 19 insertions(+), 0 deletions(-) > Hi, Jacek, I'm far away from my linux box and I'm just passing by to remember that there is a 24 continuation limit. Here is an invalid operation because it has 26 continuations: x = _ 3 _ + 3 _ + 3 _ + 3 _ + 3 - _ 3 + _ 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 _ + 3 And this is another test that must pass too (there is no new operand after the last _ ) : x = _ 3 _ + 3 _ + 3 _ + 3 _ As I said I can't test in wine but maybe you will find this information useful. Best wishes, Bruno -- universe* god::bigbang (void); //and then it all began...

2 2

Re: [3/7] d3d9/tests: Add a test for locking partial blocks with different pools
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 23:01, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 4, 4, 1, > + pools[i].pool == D3DPOOL_DEFAULT ? D3DUSAGE_DYNAMIC : 0, > + D3DFMT_DXT5, pools[i].pool, &texture, NULL); Same comment about dynamic textures as for patch 2/7. > + rect.left = 0; rect.top = 0; rect.right = 2; rect.bottom = 2; I don't care strongly about this, but note that SetRect() exists.

1 0

Re: [2/7] wined3d: Locking partial blocks is not allowed in DEFAULT pool resources
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

On 16 October 2011 22:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + hr = IDirect3DDevice9_CreateTexture(device, 128, 128, 1, D3DUSAGE_DYNAMIC, dxt_formats[i].fmt, > + D3DPOOL_DEFAULT, &texture, NULL); You should check D3DCAPS2_DYNAMICTEXTURES before using dynamic textures. Also, wouldn't it be more appropriate to make this part of the test in patch 3/7?

1 0

Re: d3dx9_36: Buffer size does not depend on the size of the created buffer
by Henri Verbeet Oct. 17, 2011

Oct. 17, 2011

This is because the buffer is supposed to be created by D3DXCreateBox().

1 0

Re: riched20: Prevent setting an invalid default format rect
by Thomas Faber Oct. 17, 2011

Oct. 17, 2011

Hey, On 2011-10-15 12:10, Thomas Faber wrote: > The patch fixes this by adding checks to ME_SetDefaultFormatRect to > use the minimal rectangle that is still valid in this case. I've made some tests (will post them later) and it turns out this rectangle is also invalid in Windows in this case, so this is not the correct solution. Please ignore the patch, I will try to come up with a better one soon. Regards, Tom

1 0

Re: [patch] Support NULL puLen in VerQueryValue
by Andrew Nguyen Oct. 15, 2011

Oct. 15, 2011

On 01/03/2011 09:25 PM, Rafael Ávila de Espíndola wrote: > I couldn't find any documentation saying that this must be supported, > but running google code search on VerQueryValue.*NULL found some uses. > > Cheers, > Rafael > > > > You should write some tests to examine the behavior of VerQueryValue with NULL puLen.

3 2

Fwd: [Announce] Google Code-in 2011
by Austin English Oct. 14, 2011

Oct. 14, 2011

---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Fri, Oct 14, 2011 at 15:28 Subject: [Announce] Google Code-in 2011 To: Google Summer of Code Mentors List <google-summer-of-code-mentors-list(a)googlegroups.com> Hi everyone, We’re pleased to announce that we are planning to run the Google Code-in contest again this November. We had a successful contest last year with 20 mentoring organizations and 361 participating students. We will again be giving 13-17 year old students around the world an opportunity to get involved with open source projects doing tasks ranging from documentation to outreach to coding programs. We’re looking forward to a fun contest this year and hope you’ll consider participating as a mentor and/or org admin yourself, and spreading the word to friends, family, and colleagues about the program. Please check out the timeline [0] for more details on the program. We will soon be accepting applications for open source organizations to become mentoring organizations for this year’s contest. There will be a separate email thread to this list inviting you to apply to be a mentoring organization on Monday, 17 October. Please take some time to discuss with your respective organizations about whether you feel you have the time and mentor capacity to participate this year. We won’t kid you: working with teengers can be demanding. It’s important that your mentors/org be prepared to put the time in over the holiday, but if you participate you will all have the satisfaction of sharing your project and your passion for open source with a truly amazing collection of young people, and getting them started in our community. We've put together an Information Page [1] for this year's program to give you some lessons learned from last year's program. *Please* look this over before deciding to apply to participate in the program. We encourage you to join the Google Code-in contest discussion list [2] and announcement list [3]. Please see our blog post [4] for further details and contact us directly if you have specific questions that aren’t answered in the FAQs [5]. [0] - http://www.google-melange.com/gci/events/google/gci2011 [1] - http://code.google.com/p/google-code-in/wiki/GCIAdminMentorInformation [2] - http://groups.google.com/group/gci-discuss [3] - http://groups.google.com/group/gci-announce [4] - http://google-opensource.blogspot.com/2011/10/google-code-in-are-you-in.html [5] - http://www.google-melange.com/gci/document/show/gci_program/google/gci2011/… Cheers, The Google OSPO Team -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Mentors List" group. To post to this group, send email to google-summer-of-code-mentors-list(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en. -- -Austin

1 0

Re: [6/6] wined3d: Catch nop palette updates
by Henri Verbeet Oct. 14, 2011

Oct. 14, 2011

This looks questionable. Which applications does this help?

2 3

Re: 79927: [3/3] cmd: Make RENAME work for read-only files
by Dan Kegel Oct. 14, 2011

Oct. 14, 2011

gcc complains here: builtins.c: In function 'WCMD_rename': builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] On Fri, Oct 14, 2011 at 2:27 AM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/383 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > builtins.c: In function 'WCMD_rename': > builtins.c:1782:9: error: unused variable 'attribs' [-Werror=unused-variable] > make[1]: *** [builtins.o] Error 1 > make: *** [programs/cmd] Error 2 > make: *** Waiting for unfinished jobs.... > >

2 1

Re: ddraw: Keep track of interface attached by AddAttachedSurface and detach correct interface when parent is released. (try 3)
by Saulius Krasuckas Oct. 14, 2011

Oct. 14, 2011

Hello, Octavian. * On Tue, 11 Oct 2011, Octavian Voicu wrote: > > try 3: > - fix test failure by moving error check from *_DeleteAttachedSurface to > ddraw_surface_delete_attached_surface, after another check (thanks Henri). > > try 2: > - use IUnknown_Release(attached_iface) instead of manual dispatch, > as suggested by Henri; > - change type of attached_iface from void* to IUnknown* to reflect > fact that it's a pointer to an interface; > - add test to show that attaching a surface only attaches a specific > interface and return error if DeleteAttachedSurface is called with > another interface than the attached one (instead of detaching the > surface anyway). > > Fixes a bug that causes a stencil buffer leak in the game The Longest Journey. > Problem can be seen in the console output log attached to bug #11819. > This patch doesn't fix the original bug, but now game exits cleanly. > > The root of the problem is that when releasing a surface, its attached > surfaces are detached using IDirectDraw7_DeleteAttachedSurface, regardless > of what interface was originally attached. I am troubled by seeing (via test.winehq.org) your ddraw:refcount tests to account only results for "VMware SVGA 3D" adapter/driver (and only those with 3D acceleration disabled), I guess. But if this driver is 3D-enabled or just present real physical adapter (with no 3d acceleration) then ddraw:refcount contains 6 static failures such as: refcount.c:214: Test failed: AddAttachedSurface returned 8876000a refcount.c:235: Test failed: AddAttachedSurface returned 8876000a refcount.c:237: Test failed: Got refcount 1, expected 2 refcount.c:262: Test failed: AddAttachedSurface returned 8876000a refcount.c:275: Test failed: AddAttachedSurface returned 8876000a refcount.c:277: Test failed: Got refcount 1, expected 2 refcount: 112 tests executed (0 marked as todo, 6 failures), 0 skipped This relation can be easily tracked by looking at d3d9:visual or (if they aren't present) at opengl32:opgenl tests. Eg. failures occuring here: * Intel(R) 82865G Graphics Controller http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_af-… * NVIDIA GeForce FX 5200 http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_s… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/xp_s2-… * ATI Radeon HD 4800 Series (telling it has no IDirect3D[7] support for DDraw) http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… http://test.winehq.org/data/a843acef5567bc30901612ce5013da543259b21b/win7_w… * VMware SVGA II http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/2000_f… * VMware SVGA 3D (telling it has not IDirect3D[7] support for DDraw) http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_f… All other cases succeed. AFAICS all of them represent the only driver (with 3D support turned off): * VMware SVGA 3D http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… visual.c:194: Driver string: "vm3dum.dll" visual.c:195: Description string: "VMware SVGA 3D (Microsoft Corporation - WDDM)" visual.c:197: Device name string: "\\.\DISPLAY1" visual.c:199: Driver version 7.14.1.40 visual.c:12627: Tests skipped: Creating the device failed visual: 5 tests executed (0 marked as todo, 0 failures), 1 skipped. with following results: http://test.winehq.org/data/d0c38ece9db657431559024abb34285cd8b717b6/win7_w… refcount: 121 tests executed (0 marked as todo, 0 failures), 0 skipped. IMHO, it would be nice to conform to real world configuration. Wish you best luck with fixing your tests:) S.

3 2

Re: [2/6] wined3d: Pass the destination surface to blitters
by Henri Verbeet Oct. 14, 2011

Oct. 14, 2011

On 13 October 2011 01:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > -static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *surface) > + static HRESULT arbfp_blit_set(void *blit_priv, struct wined3d_context *context, struct wined3d_surface *src, > + const struct wined3d_surface *dst) Whitespace error. The parameter you're adding isn't used anywhere, not even in the same patchset. Perhaps more important though is the point that "set_shader" is pretty much the wrong interface for blitters and should go away. Note that the blitter interface is something I'm actually working on as part of the ddraw work, it's just that other things keep coming up.

2 3

One more review: wineps.drv: Implement PS_USERSTYLE on printers
by Daniel Santos Oct. 14, 2011

Oct. 14, 2011

Is anybody intimately familiar with the life cycle of device context and pens? I don't necessarily mean that you went to bed with either of them, but that would be OK too. I mean, this is the 2010s, we're supposed to be modern here. Specifically, I want to make sure I'm not leaking my dynamically allocated memory block. This block is allocated when the pen is selected (not when it's created). Thanks in advance Daniel

1 1

Re: 79921: ntdll: Move adding VPROT_READ for Solaris to the same place where it's done for FreeBSD. Take 2.
by Dan Kegel Oct. 14, 2011

Oct. 14, 2011

Fails to apply here: $ patch -p1 < vprot.patch patching file dlls/ntdll/virtual.c Hunk #1 FAILED at 187. 1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej On Thu, Oct 13, 2011 at 10:02 PM, <buildbot(a)kegel.com> wrote: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > For more info about this message, see http://wiki.winehq.org/BuildBot > > The Buildbot has detected a failed build on builder runtests-default while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/373 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed git > > Errors: > error: patch failed: dlls/ntdll/virtual.c:187 > error: dlls/ntdll/virtual.c: patch does not apply > >

2 1