August 2010 - Wine-Devel - list.winehq.org

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Robert Kim App and Facebook Marketing

"my 3G Internet > connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one > cares) > " HAHA!!! Don't you have a starbucks near by??? They do free wifi now! On Tue, Aug 31, 2010 at 3:58 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Is the attached patch well formed ? > Can someone give it a try ? > I don't want to run it, I fear it'll download all tables : my 3G Internet > connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one > cares) > > > > -- Robert Q Kim 2611 S Coast Highway San Diego, CA 92007 310 598 1606 My Latest Blog Post: http://sparkah.com/2010/07/29/experienced-iphone-app-developer-los-angeles-… http://sparkah.com/2010/08/25/facebook-marketing-strategies-from-nyc-and-lo…

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:48, misha680 <misha680(a)gmail.com> wrote: > D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per > include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 > it is last, I assume it would also come last? > The LASTBETA FVF flags don't add elements themselves, they modify the D3DFVF_XYZBn ones. See also D3DXDeclaratorFromFVF() for reference.

Aug. 31, 2010

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.

by Francois Gouget

On Tue, 31 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4872 [...] > === W98SE (32 bit process) === > Failure running script in VM: Exceeded timeout limit of 315 sec This is strange. Testbot says the process timed out yet the full log has the expected summary line listing the tests that were run as well as the 'process done' line so it looks like the test completed: > process: 320 tests executed (0 marked as todo, 0 failures), 5 skipped. > kernel32:process done (0) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >>> Well yes, but I'd say that ordering should apply to *any* FVF element, >>> not just colors and normals. E.g., point size before position or >>> texture before color should be just as untranslatable. >> Thank you. I was not aware of these constraints. >> >> Is there, by any chance, a good place for this? I have been checking >> the MSDN docs so far: >> http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx >> but at least upon my initial reads did not notice any such guidelines. >> > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | > D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific > vertex buffer layout, if you translate a declaration to that, it > should better describe that exact same layout.) > Thank you. I had to check a reference but I think I understand now. http://www.xmission.com/~legalize/book/download/05-Modeling.pdf pg. 168 "The vertex components are laid out in memory in the same order as the vertex components listed in the table, starting with the position component. #define D3DFVF_XYZ 0x002 #define D3DFVF_XYZRHW 0x004 #define D3DFVF_XYZB1 0x006 #define D3DFVF_XYZB2 0x008 #define D3DFVF_XYZB3 0x00a #define D3DFVF_XYZB4 0x00c #define D3DFVF_XYZB5 0x00e #define D3DFVF_NORMAL 0x010 #define D3DFVF_PSIZE 0x020 #define D3DFVF_DIFFUSE 0x040 #define D3DFVF_SPECULAR 0x080 #define D3DFVF_TEX0 0x000 #define D3DFVF_TEX1 0x100 #define D3DFVF_TEX2 0x200 #define D3DFVF_TEX3 0x300 #define D3DFVF_TEX4 0x400 #define D3DFVF_TEX5 0x500 #define D3DFVF_TEX6 0x600 #define D3DFVF_TEX7 0x700 #define D3DFVF_TEX8 0x800 #define D3DFVF_LASTBETA_UBYTE4 0x1000 Every FVF must include a position with one of the D3DFVF XYZ, D3DFVF - XYZRHW, D3DFVF XYZB1, D3DFVF XYZB2, D3DFVF XYZB3, D3DFVF XYZB4, or D3D- FVF XYZB5. The remaining FVF flags are all optional." D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 it is last, I assume it would also come last? Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXFVFFromDeclarator-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >> Well yes, but I'd say that ordering should apply to *any* FVF element, >> not just colors and normals. E.g., point size before position or >> texture before color should be just as untranslatable. > Thank you. I was not aware of these constraints. > > Is there, by any chance, a good place for this? I have been checking > the MSDN docs so far: > http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx > but at least upon my initial reads did not notice any such guidelines. > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific vertex buffer layout, if you translate a declaration to that, it should better describe that exact same layout.)

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Misha Koshelev

On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 31 August 2010 14:47, misha680 <misha680(a)gmail.com> wrote: >> As you can see by the tests added, colors and normals have an ordering that >> is specifically constrained within the FVF. >> > Well yes, but I'd say that ordering should apply to *any* FVF element, > not just colors and normals. E.g., point size before position or > texture before color should be just as untranslatable. Thank you. I was not aware of these constraints. Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines. > >> To clarify, by saying that the booleans are redundant, do you mean to say >> that, say, if I have a normal element, I should iterate back through all >> declaration elements that have already been processed and check for a prior >> color element, and then return D3DERR_INVALIDCALL? >> > No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already > have a normal. That is a great idea! I honestly did not think of that at all. Thank you for the wonderful hint. Misha

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Owen Rudge

Hi Henri, > Probably depends on the device supporting NPOT textures again. The capabilities are checked in the D3DXCheckTextureRequirements function, and the values adjusted if necessary. > (Yeah, this is a mostly unchanged copy of my earlier comments.) My apologies, I somehow missed the previous e-mail at the time. (I do see it now.) Thanks for your feedback, -- Owen Rudge http://www.owenrudge.net/

Aug. 31, 2010

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs

by Alexandre Julliard

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > /*********************************************************************** > + * WS2_async_recv_accept (INTERNAL) > + * > + * This function is used to finish the read part of an accept request. It is > + * needed to place the completion on the correct socket (listener). > + */ > +static NTSTATUS WINAPI WS2_async_recv_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ > + void *junk; > + struct ws2_accept_async *wsa = arg; > + > + status = WS2_async_recv( wsa->read, iosb, status, &junk ); > + if (status == STATUS_PENDING) > + return status; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} > + > +/*********************************************************************** > + * WS2_async_accept (INTERNAL) > + * > + * This is the function called to satisfy the AcceptEx callback > + */ > +static NTSTATUS WINAPI WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ These are not valid async callbacks, the way async callbacks work has changed since the patch was first written. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Mikko Rasa

On 31.08.2010 16:16, Henri Verbeet wrote: > On 30 August 2010 18:37, Mikko Rasa<tdb(a)tdb.fi> wrote: >> + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); > ... >> - stream_sizes->cbHeader = 5; >> - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ >> + stream_sizes->cbHeader = ctx->header_bytes; >> + stream_sizes->cbTrailer = ctx->trailer_bytes; > Does this imply TLS record padding should be disabled? I imagine an > encrypted message may not fit in the application provided buffers > otherwise. That was originally so I could determine the end of the message and fill a SECBUFFER_EXTRA buffer if there's any leftover data (probably because the input buffer contained part of the next message). However, since I had to do my own TLS frame decoding anyway in a later patch, I don't really need to know the MAC size anymore. I'll produce a revised patchset shortly, taking into account Hans's feedback as well. -- Mikko

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Henri Verbeet

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote: > + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); ... > - stream_sizes->cbHeader = 5; > - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbHeader = ctx->header_bytes; > + stream_sizes->cbTrailer = ctx->trailer_bytes; Does this imply TLS record padding should be disabled? I imagine an encrypted message may not fit in the application provided buffers otherwise.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 14:47, misha680 <misha680(a)gmail.com> wrote: > As you can see by the tests added, colors and normals have an ordering that > is specifically constrained within the FVF. > Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable. > To clarify, by saying that the booleans are redundant, do you mean to say > that, say, if I have a normal element, I should iterate back through all > declaration elements that have already been processed and check for a prior > color element, and then return D3DERR_INVALIDCALL? > No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already have a normal.

Aug. 31, 2010

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage

by Hans Leidekker

On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote: > + SIZE_T expected_size; > ssize_t received = 0; > ssize_t ret; > int idx; > - char *buf_ptr; > + unsigned char *buf_ptr; > unsigned int offset; > > TRACE("context_handle %p, message %p, message_seq_no %d, quality %p\n", > @@ -1230,12 +1243,22 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if (idx == -1) > return SEC_E_INVALID_TOKEN; > buffer = &message->pBuffers[idx]; > + buf_ptr = (unsigned char *)buffer->pvBuffer; > + > + expected_size = 5 + ((buf_ptr[3] << 8) | buf_ptr[4]); > + if(buffer->cbBuffer < expected_size) > + { > + TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } This produces a compiler warning here: schannel.c: In function ‘schan_DecryptMessage’: schannel.c:1251: warning: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘SIZE_T’

Aug. 31, 2010

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does

by Hans Leidekker

On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote: > - memcpy(buffer->pvBuffer, data, received); > - buffer->cbBuffer = received; > + buf_ptr = (char *)buffer->pvBuffer; You don't need this cast. > + offset = ctx->header_bytes; > + memcpy(buf_ptr + offset, data, received); > HeapFree(GetProcessHeap(), 0, data); > > + schan_decrypt_fill_buffer(message, SECBUFFER_DATA, buf_ptr + offset, received); > + offset += received; > + > + schan_decrypt_fill_buffer(message, SECBUFFER_STREAM_TRAILER, buf_ptr + offset, buffer->cbBuffer - offset); > + offset += ctx->trailer_bytes; > + > + if(buffer->cbBuffer > offset) > + schan_decrypt_fill_buffer(message, SECBUFFER_EXTRA, buf_ptr + offset, buffer->cbBuffer - offset); > + > + buffer->BufferType = SECBUFFER_STREAM_HEADER; > + buffer->cbBuffer = ctx->header_bytes; > + FWIW, this patch set passes my tests.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: >> Looking forward to (constructive) comments. >> > Why are colors and normals special? What use is hasPosition? What > happens when the source declaration has e.g. two color elements with > usage index 0, or two position elements? Note that the booleans are > redundant, you store that information in the FVF. > > > > As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF. To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL? Again, for the case of two color elements or two normal elements, are you suggesting I do the same (iterate through all past elements)? Wouldn't, in this case, a boolean be more efficient? hasPosition I apologize does not need to be there. Just trying to clarify your points regarding your comments re booleans and specialty of colors and normals. Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXFVFFromDeclarator-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Jacek Caban

On 8/31/10 2:03 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: >> They are defined by default by midl. > __midl is supposed to be set to the midl compiler version, and I'm not > entirely convinced it's appropriate for us to define it. My motivation was to make headers prepared for midl to work. They usually check only if __midl is defined and that's all we can sanely do. > Also, _WIN64 can't depend on how widl was built, since it can generate > both 32-bit and 64-bit code. Right, I've sent the patch too quickly, sorry. > You'd have to parse everything twice if you wanted to make use of this. That's a matter of not using it, but if midl defines it, I think we should do it as well. I will resend the patch with _WIN32 define only. Thanks, Jacek

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Henri Verbeet

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability. (Yeah, this is a mostly unchanged copy of my earlier comments.)

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > They are defined by default by midl. __midl is supposed to be set to the midl compiler version, and I'm not entirely convinced it's appropriate for us to define it. Also, _WIN64 can't depend on how widl was built, since it can generate both 32-bit and 64-bit code. You'd have to parse everything twice if you wanted to make use of this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Nicolas Le Cam

2010/8/31 Francois Gouget <fgouget(a)free.fr> > On Tue, 31 Aug 2010, Alexandre Julliard wrote: > > > Francois Gouget <fgouget(a)free.fr> writes: > > > > > http://source.winehq.org/patches/data/65442 > > > > > > According to http://source.winehq.org/patches/ this patch causes a > build > > > error (or maybe a new warning). However here (gcc 4.4) I see no warning > > > at all. > [...] > > It's an undefined reference, probably you don't have OpenAL so that code > > doesn't get compiled. > > Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if > OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 > system so there's no package providing the 32bit version :-( > > Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 > and libopenal on a 64bit Debian system? I would try apt-cross but I was > once told that using it to get 32bit libraries on 64bit system was > stupid, not meant to work, etc. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > > I don't know of a 'clean' way (and I'm also interested if anyone knows) but, at least, lib32v4l-0 is available for squeeze and sid since early june (it also seems to be in lenny-backports but from the older, now removed, libv4l source package). -- Nicolas Le Cam

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

Is the attached patch well formed ? Can someone give it a try ? I don't want to run it, I fear it'll download all tables : my 3G Internet connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one cares)

Aug. 31, 2010

Re: Chinese translation of key pages on wiki.winehq.org?

by Frédéric Delanoy

On Tue, Aug 31, 2010 at 02:40, Dan Kegel <dank(a)kegel.com> wrote: > Are there any Chinese speakers on the list? > Any interest in starting a Chinese translation of wiki.winehq.org? > > I bring this up because a Chinese user/developer is asking for help > getting started with submitting translations to Wine. I think he would find > Chinese versions of > http://wiki.winehq.org/SubmittingPatches > and perhaps even > http://wiki.winehq.org/Translating > helpful. > > It seems strange for a translator to need help reading English > documents, but perhaps it would help them come up the curve > faster. Well maybe it's because (some of) these pages are not clear enough for non-techies. Maybe he could tell what parts he didn't understand so the wiki pages can be improved (it would help for other languages, too). Rgds, Frédéric

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/31/2010 12:23 PM, Dmitry Timoshkov wrote: > Wine's aim is to run Windows applications, not to implement everything > Windows has. I disagree about that but it doesn't matter after all. > Spending time fixing > differencies nobody cares about is a time loss You're probably right but what about if the solution is known and working ? I don't ask you to waste your time fixing useless things (that's what I seems to do) but just help me to translate a single line change in a C file into a (probably single) perl line. [1] After that, all msvcrt:string tests (1415 exactly) will pass and I won't have to change these locale files again. --- [1] You're not paid for that so if anyone could help me on it, this topic will simply end .. with a better Wine.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Francois Gouget

On Tue, 31 Aug 2010, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > > > http://source.winehq.org/patches/data/65442 > > > > According to http://source.winehq.org/patches/ this patch causes a build > > error (or maybe a new warning). However here (gcc 4.4) I see no warning > > at all. [...] > It's an undefined reference, probably you don't have OpenAL so that code > doesn't get compiled. Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 system so there's no package providing the 32bit version :-( Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 and libopenal on a 64bit Debian system? I would try apt-cross but I was once told that using it to get 32bit libraries on 64bit system was stupid, not meant to work, etc. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: > Looking forward to (constructive) comments. > Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Dmitry Timoshkov

GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > You've done great things on wine for a long time and fixed plenty of > bugs (again, thanks) but ... how can you say that (the last sentence) ? > I don't want to offense you, I'm no one, and I don't say that just to be > mean .. but there won't be any problem until an application rely on it. > And that's wine is for : provide an implementation of win32 API, mimic > windows behavior (and its bugs). Wine's aim is to run Windows applications, not to implement everything Windows has. Therefore Wine only implements things the Windows applications depend upon. There are hundreds (if not thousands) APIs, or things that differ in Wine in comparoson to Windows. That only starts to matter once there is a Windows application that doesn't run due to that. Spending time fixing differencies nobody cares about is a time loss. -- Dmitry.

Aug. 31, 2010

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.

by testbot＠testbot.winehq.org

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=4872 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

Aug. 31, 2010