March 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 01/10] d3d9/tests: Use a separate device for test_vshader_input().

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://newtestbot.winehq.org/JobDetails.pl?Key=5992 Your paranoid android. === w8 (32 bit visual) === visual.c:7297: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00 visual.c:7282: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00 visual.c:7282: Test failed: Input test: Quad 2(1crd) returned color 0x00000000, expected 0x00ffff00

March 26, 2014

Re: [2/2] netcfgx: Add INetCfgLock support (try 2)

by Alistair Leslie-Hughes

On 26/03/2014 12:10 PM, Marvin 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://newtestbot.winehq.org/JobDetails.pl?Key=5989 > > Your paranoid android. This is caused by uuid.lib not being rebuild. Best Regards Alistair Leslie-Hughes

March 26, 2014

Re: [2/2] netcfgx: Add INetCfgLock support (try 2)

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://newtestbot.winehq.org/JobDetails.pl?Key=5989 Your paranoid android. === build (build) === Make failed

March 26, 2014

Re: [2/2] netcfgx: Add INetCfgLock support

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://newtestbot.winehq.org/JobDetails.pl?Key=5988 Your paranoid android. === build (build) === Make failed

March 26, 2014

MS releases vintage DOS source code

by Michael Stefaniuc

Not directly relevant to us as DOS got outsourced to dosbox but here it is nevertheless: http://www.computerhistory.org/atchm/microsoft-ms-dos-2-0-source-code/ If they keep releasing the source roughly 30 years after the OS hit the market, then Windows 3.11 is still 10 years out. bye michael

March 25, 2014

Re: setupapi: Don't confuse ARM with ARM64

by Jactry Zeng

2014-3-26 上午3:03于 "Qian Hong" <fracting(a)gmail.com>写道： > > On Wed, Mar 26, 2014 at 2:46 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > > "You screwed up but AJ missed it, send a fix before someone notices" ;-) > > André, you really should hide some bugs in your code as an evidence to > proving someone stolen your code <grin> > Um...next time anybody catch a bug in my code, i may say "it is not a bug! It is proof!!" ;－) > > -- > Regards, > Qian Hong > > - > http://www.winehq.org > >

March 25, 2014

Re: setupapi: Don't confuse ARM with ARM64

by Qian Hong

On Wed, Mar 26, 2014 at 2:46 AM, André Hentschel <nerv(a)dawncrow.de> wrote: > "You screwed up but AJ missed it, send a fix before someone notices" ;-) André, you really should hide some bugs in your code as an evidence to proving someone stolen your code <grin> -- Regards, Qian Hong - http://www.winehq.org

March 25, 2014

Re: Wine test week 2 - nice apparent progress

by André Hentschel

Am 25.03.2014 16:54, schrieb Jeremy White: >>> Hardware is cheap; we can easily throw more testbots at the problem... >> I got told repeatedly by well informed sources that that isn't needed. >> Just sayin' > > Actually, we've got a new server specced out, and we're going to put it into production use next week. If that goes well, we'll likely plan a migration for WineHQ as well... what about also migrating the wiki to your site? (including the code to Wines git server)

March 25, 2014

Re: [wine-devel] Re: Wine test week 2 - nice apparent progress

by Alan W. Irwin

On 2014-03-25 07:51-0500 Jeremy White wrote: > On 03/25/2014 02:33 AM, Henri Verbeet wrote: >> On 25 March 2014 01:00, Jeremy White <jwhite(a)codeweavers.com> wrote: >>> My script results are here: >>> http://www.winehq.org/~jwhite/ebd5f96aea22.html >>> >> For what it's worth, note that the intermittent failures in >> ddraw:ddraw7 are timeouts, and happening in different places. I >> suspect that's either the generic issue of the testbot timing out on >> occasion, or the testbot just not being fast enough to finish the test >> in time, perhaps due to it being under some load from a different VM. >> >> > > Francois, do we have (or could we easily create) a mechanism to test that by > constraining the number of VMs that run simultaneously? I know it would slow > performance, but it would be interesting to see if we > can quantify that. I am not a wine developer, but observing this interesting thread from the outside point of view, it seems to me what you really need is a mechanism to specify "timeout" for each test not in terms of wall-clock time, but in terms of roughly how many floating-point operations are consumed by the test before it is decided the test is a failure. IOW, each timeout in seconds should effectively be multiplied by the integral of the time-variable load factor on the actual hardware that is running the VM divided by a constant factor corresponding to the speed of the machine. So for example, the timeout in seconds could be specified for a 1-GHz otherwise idle theoretical hardware, and adjusted appropriately on-the-fly to speed of the actual hardware and its time-variable load. If this is implemented correctly, once a test succeeds with a given timeout (specified for the theoretical hardware) on given hardware, it should never fail again due to load/computer speed factors on that or any other hardware with that same given timeout. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

March 25, 2014

Re: Wine test week 2 - nice apparent progress

by Jeremy White

>> Francois, do we have (or could we easily create) a mechanism to test >> that by constraining the number of VMs that run simultaneously? I know >> it would slow performance, but it would be interesting to see if we >> can quantify that. > Just two run in parallel. I wanted to ask Francois to bump that number > up not lower it. The testbot is basically unusable for hours during the > daily test run due to that. Ah. Okay. Yeah, I think there is a sense that we want the software to behave sensibly before we start throwing hardware at the problem. > >> Hardware is cheap; we can easily throw more testbots at the problem... > I got told repeatedly by well informed sources that that isn't needed. > Just sayin' Actually, we've got a new server specced out, and we're going to put it into production use next week. If that goes well, we'll likely plan a migration for WineHQ as well... Cheers, Jeremy

March 25, 2014