December 2016 - Wine-Devel - list.winehq.org

Re: [PATCH 5/5] bcrypt/tests: Add BCryptEncrypt/Decrypt tests

by Bruno Jesus

On Fri, Dec 2, 2016 at 4:36 PM, Marvin <testbot(a)winehq.org> wrote: > 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 > https://testbot.winehq.org/JobDetails.pl?Key=27070 > > Your paranoid android. > > > === wvistau64 (64 bit bcrypt) === > bcrypt.c:792: Test failed: got 598 > bcrypt.c:848: Test failed: got 598 > > === w2008s64 (64 bit bcrypt) === > bcrypt.c:792: Test failed: got 598 > bcrypt.c:848: Test failed: got 598 > > === w7pro64 (64 bit bcrypt) === > bcrypt.c:792: Test failed: got 622 > bcrypt.c:848: Test failed: got 622 > > === w864 (64 bit bcrypt) === > bcrypt.c:792: Test failed: got 654 > bcrypt.c:848: Test failed: got 654 > > === w1064 (64 bit bcrypt) === > bcrypt.c:792: Test failed: got 654 > bcrypt.c:848: Test failed: got 654 When I run the tests manually the results are OK, I have no idea why when testbot ran then automatically everything failed... I guess I'll have to accept these values too.

Dec. 2, 2016

Re: [PATCH] user32: Handle WM_SYSKEYDOWN in MENU_SuspendPopup.

by Alexandre Julliard

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Instead of adding WM_SYSKEYDOWN to the switch statement, we could fix > the bug in one line by moving "pmt->trackFlags |= TF_SKIPREMOVE;" into > the WM_KEYDOWN case. Or, we could delete MENU_SuspendPopup entirely > and the if statements that call it. However, we wouldn't be setting > TF_SKIPREMOVE anymore for unrecognized messages, likely causing a > return of the bug that d75b0cdc tried to fix. > > By the way, I'm not exactly reverting d75b0cdc. I changed PM_REMOVE to > PM_NOREMOVE to make sure that messages are removed only if they are > recognized. > > I hope that makes sense; I admit that my previous explanation was not > as well thought out as it could have been. Thanks for the feedback. Sorry for the delay in reviewing this. It still doesn't quite make sense to me. Changing to PM_NOREMOVE now means that the keyboard message won't get removed if some other message happened in between. I'm not sure that's a good idea. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2016

Re: [PATCH 5/5] bcrypt/tests: Add BCryptEncrypt/Decrypt tests

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 https://testbot.winehq.org/JobDetails.pl?Key=27070 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 622 bcrypt.c:848: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654

Dec. 2, 2016

Re: [PATCH 4/5] bcrypt/tests: Add BCryptGenerateSymmetricKey tests

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 https://testbot.winehq.org/JobDetails.pl?Key=27069 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 598 bcrypt.c:848: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 622 bcrypt.c:848: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:792: Test failed: got 654 bcrypt.c:848: Test failed: got 654

Dec. 2, 2016

Re: [PATCH 3/5] bcrypt/tests: Add AES provider tests

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 https://testbot.winehq.org/JobDetails.pl?Key=27068 Your paranoid android. === wvistau64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 598 === w2008s64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 598 === w7pro64 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 622 === w864 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 654 === w1064 (64 bit bcrypt) === bcrypt.c:783: Test failed: got 654

Dec. 2, 2016

Re: [PATCH 1/3] server: Introduced iosb struct for server-side IO_STATUS_BLOCK representation and use it in irp_call.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > +/* release iosb reference */ > +void release_iosb( struct iosb *iosb ) > +{ > + if (--iosb->refcount) return; > + > + free( iosb->in_data ); > + free( iosb->out_data ); > + free( iosb ); > +} I think you should use a proper server object instead. -- Alexandre Julliard julliard(a)winehq.org

Dec. 2, 2016

Re: server: Signal pipe server fd in create_pipe_server.

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 https://testbot.winehq.org/JobDetails.pl?Key=27047 Your paranoid android. === w2008s64 (32 bit pipe) === Unable to set the VM system time: the "nc -q0 '10.42.42.136' '4242'" command returned 1 (settime/connect). Maybe the TestAgentd process is missing the required privileges. The test VM is powered off! Did the test shut it down?

Dec. 2, 2016

Re: [PATCH] dxgi: Silence a noisy fixme

by Henri Verbeet

On 2 December 2016 at 10:26, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > static HRESULT STDMETHODCALLTYPE dxgi_output_WaitForVBlank(IDXGIOutput *iface) > { > - FIXME("iface %p stub!\n", iface); > + BOOL once = FALSE; > + > + if (!once++) > + FIXME("iface %p stub!\n", iface); > > return E_NOTIMPL; > } Did you test that this does what you think it does? Leaving that issue aside for the moment, while printing the FIXME only once is probably fine, not tracing anything on subsequent calls isn't.

Dec. 2, 2016

Re: [PATCH] dxgi: Silence a noisy fixme

by Hans Leidekker

On Fri, 2016-12-02 at 09:26 +0000, Alistair Leslie-Hughes wrote: > diff --git a/dlls/dxgi/output.c b/dlls/dxgi/output.c > index 0cf8084..61a7043 100644 > --- a/dlls/dxgi/output.c > +++ b/dlls/dxgi/output.c > @@ -268,7 +268,10 @@ static HRESULT STDMETHODCALLTYPE dxgi_output_FindClosestMatchingMode(IDXGIOutput > > static HRESULT STDMETHODCALLTYPE dxgi_output_WaitForVBlank(IDXGIOutput *iface) > { > - FIXME("iface %p stub!\n", iface); > + BOOL once = FALSE; > + > + if (!once++) > + FIXME("iface %p stub!\n", iface); > > return E_NOTIMPL; > } static BOOL once;

Dec. 2, 2016

Re: Call for tests - GNU/Linux & specially OSX - iphlpapi

by Ken Thomases

Hi, On Nov 30, 2016, at 1:54 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > > Hello all, in order to exercise an IP ordering problem from bug 40247 > (OSX) [1] I would like to request help for testing the crosstest at > [2]. Valid testers must have at least 1 network interface with a valid > IP and a the loopback interface up. > > A good test should result in 1 error, if not send me the results > anyway, only the traces from lines 262 and 266 are needed (first in > the log, 10 lines should be enough). If you find the lines I'm > expecting just paste them, if you don't have patience just attach the > whole results, pĺease. Here's the result from my work iMac running macOS 10.12, running a Wine build from before your commit 95298b444: iphlpapi.c:262: Entry[0]: addr 127.0.0.1, dwIndex 1, wType 0x1 iphlpapi.c:266: Test failed: Loopback interface wrongly at position 0/2 iphlpapi.c:262: Entry[1]: addr 10.69.137.110, dwIndex 4, wType 0x1 iphlpapi.c:262: Entry[2]: addr 10.69.137.226, dwIndex 5, wType 0x1 fixme:iphlpapi:GetIcmpStatisticsEx unimplemented for IPv6 iphlpapi.c:617: Test failed: GetIcmpStatisticsEx returned 50, expected NO_ERROR […] Here's the result after your commit: iphlpapi.c:262: Entry[0]: addr 10.69.137.110, dwIndex 4, wType 0x1 iphlpapi.c:262: Entry[1]: addr 10.69.137.226, dwIndex 5, wType 0x1 iphlpapi.c:262: Entry[2]: addr 127.0.0.1, dwIndex 1, wType 0x1 fixme:iphlpapi:GetIcmpStatisticsEx unimplemented for IPv6 iphlpapi.c:617: Test failed: GetIcmpStatisticsEx returned 50, expected NO_ERROR […] Thanks for addressing this! -Ken

Dec. 2, 2016