I may perfectly repeat someones else question, but why in the world winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the patches arrives too late during partical day?
I think compiled EXEs should be released regardless of their generation date. No?
On Friday 06 Jan 2006 01:29, Saulius Krasuckas wrote:
I may perfectly repeat someones else question, but why in the world winetest-200YmmDD1000-paul-mingw.exe files aren't being generated if the patches arrives too late during partical day?
I think compiled EXEs should be released regardless of their generation date. No?
The current way it works was the concensus decision a little while back.
Personally, I'd prefer building winetest.exe as part of WRT (auto regression testing based on CVS commits). WRT builds winetest.exe anyway (in fact, all the DLLs and EXEs it can), but the results are not registered, so no one sees them.
However, dealing with asynchronous updates was thought both too difficult and not necessary so we have the synchronous once-a-day builds. I'm maintaining a separate cron-triggered build process, although it still uses a fair bit of WRT for this. This causes the occasional headaches, but its working pretty well now [*].
The winetest infrastructure was originally designed to work with once-a-day releases, although I'm not sure if that restriction is used within the code. Changing it to work with potentially more frequent releases might require no extra work, or a fair bit.
In favour of the status quo: it works, its simple, you have to wait (at most) one day [*] and there's no need to change any of the winetest/winrash/.. infrastructure.
In favour of change: faster turn-around (and would make my life a bit simpler :^)
Cheers,
Paul.
BTW, the timing of the builds is somewhat anachronistic. It was based on the time when Alexandre was over in California (IIRC), so it was a reasonable bet that he wasn't committing code at 10am GMT (2am PST; OK, maybe not that safe a bet). These days it isn't so clear-cut (committing code at 11am EST is possible ;-), so perhaps the time should be revised?
[*] (this is assuming wine hasn't "broken" the cross-compilation that MinGW provides, that is :-)
* On Fri, 6 Jan 2006, Paul Millar wrote:
- On Friday 06 Jan 2006 01:29, Saulius Krasuckas wrote:
I think compiled EXEs should be released regardless of their generation date. No?
Excuse me for my typos and logical mistakes, but..
Personally, I'd prefer building winetest.exe as part of WRT (auto regression testing based on CVS commits). WRT builds winetest.exe anyway (in fact, all the DLLs and EXEs it can), but the results are not registered, so no one sees them.
I didn't got it - when do the results get not registered? Or when it does?
However, dealing with asynchronous updates was thought both too difficult and not necessary so we have the synchronous once-a-day builds. I'm maintaining a separate cron-triggered build process,
Are its results public? :) What belongs to WRT and what does to your separate build process?
The winetest infrastructure was originally designed to work with once-a-day releases, although I'm not sure if that restriction is used within the code. Changing it to work with potentially more frequent releases might require no extra work, or a fair bit.
Paul, just to note, I am perfectly fine with a per-day releases. :)
In favour of the status quo: it works, its simple, you have to wait (at most) one day [*] and there's no need to change any of the winetest/winrash/.. infrastructure.
In favour of change: faster turn-around (and would make my life a bit simpler :^)
Well, I may not understand your reply correctly, but why then I see only 1 release during 2006 year at the of the page [2]:
[DIR] 200512271000/ 06-Jan-2006 04:05 - [DIR] 200601061000/ 06-Jan-2006 05:50 -
when WRT summary page [3] tells us there were several successful builds in this year already:
Thu Jan 5 17:29:03 Wed Jan 4 20:51:31 Wed Jan 4 15:00:50 Tue Jan 3 21:38:32 Tue Jan 3 14:38:04
Has that happend due to lack of running Winrash clients during this time? My Winrash stayed IDLE when I had launched it several times.
[2] http://test.winehq.org/data/ [3] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
Hi Saulius,
On Friday 06 Jan 2006 15:15, Saulius Krasuckas wrote:
- On Fri, 6 Jan 2006, Paul Millar wrote:
WRT builds winetest.exe anyway (in fact, all the DLLs and EXEs it can), but the results are not registered, so no one sees them.
I didn't got it - when do the results get not registered? Or when it does?
There are two distinct "registrations" here.
The first happens when winetest.exe is built. The build process registers the availability of a new winetest.exe by sending an HTTP GET to some end-point at test.winehq.org with the corresponding URL for downloading winetest.exe.
As far as I understand it, this GET triggers some machinery at winehq end that causes any future winerash to download the new winetest.exe and execute it. A simple HTTP-redirect should work, but I don't know if that's how it works.
The second "registration" is when winetest.exe registers its results to winehq, which then makes these results available on the test.winehq.org pages.
However, dealing with asynchronous updates was thought both too difficult and not necessary so we have the synchronous once-a-day builds. I'm maintaining a separate cron-triggered build process,
Are its results public? :)
Yes. Have a look at [4].
What belongs to WRT and what does to your separate build process?
The files that are wine-<type>-<date><time>.zip are from WRT. These are bundled executables and DLLs along with corresponding signatures.
Files that start "winetest-" are from the cron build process.
All these files have a "latest" (wine-dlls-latest, winetest-latest, ...) that are sym-links to whatever is the latest build. Downloading the "latest" should always work (although, thinking about it, using an HTTP redirect would be better).
A word of warning, though. To get WRT to work, I need to patch the wine tree slightly. The cron-built winetest doesn't include these patches as they seem to cause winetest.exe to crash under some (possibly all) circumstances. I started to try and merge these changes into wine, but other things came up and I ran out of time :^(
[snip!]
Well, I may not understand your reply correctly, but why then I see only 1 release during 2006 year at the of the page [2]:
[DIR] 200512271000/ 06-Jan-2006 04:05 - [DIR] 200601061000/ 06-Jan-2006 05:50 -
when WRT summary page [3] tells us there were several successful builds in this year already:
Thu Jan 5 17:29:03 Wed Jan 4 20:51:31 Wed Jan 4 15:00:50 Tue Jan 3 21:38:32 Tue Jan 3 14:38:04
Has that happend due to lack of running Winrash clients during this time? My Winrash stayed IDLE when I had launched it several times.
There's two reasons why certain days have no results: either nothing has changed or the build process is broken.
The former can happen even when there is code being committed (hence WRT activity) but these changes don't affect any of the tests. The build process checks this and if the current winetest.exe matches the previous one then it doesn't make the new winetest.exe available. This increases the likelihood of having greater number of testers running with the one winetest.exe, and so increase the value of their work (more tests with which to compare).
Sadly the later happens all too often. MinGW has a poor coverage of Windows API (well, poorer than Wine's tests anyway ;^) so when someone adds a new test, testing against some additional API, it often breaks the cross-compilation (in 2005 this happened 22 times).
Usually its pretty straightforward job to get MinGW working again (thanks to help from Stefan Leichter and Hans Leidekker) and rebuild, but it requires me to be near a computer with Internet access. Usually not a problem, but occasionally it causes delays -- hence there are some times where there's no winetest.exe.
The problem above (at the beginning of this year) was with a missing GUID in the compiler, which is now fixed.
Cheers,
Paul.
[2] http://test.winehq.org/data/ [3] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
Paul Millar wrote:
The problem above (at the beginning of this year) was with a missing GUID in the compiler, which is now fixed.
Could you tell me what GUID it was. I'm currently in the process of trying to get compilation of DLLs working again with MSVC and the winapi tools and noticed a specific issue with GUIDs. Maybe I can learn a bit here.
For instance the GUIDs IID_IAVIStreaming and CLSID_AVIFile used in avifil32.dll are put by wine in the uuid.lib/dll file but the two MS SDKs I tried do not seem to provide these exports in either uuid.lib nor vfw32.lib(avifil32.dll).
Rolf Kalbermatter
On Monday 09 Jan 2006 21:50, Rolf Kalbermatter wrote:
Paul Millar wrote:
The problem above (at the beginning of this year) was with a missing GUID in the compiler, which is now fixed.
Could you tell me what GUID it was.
Certainly, it was IID_IHttpNegotiate2, as defined by:
DEFINE_GUID(IID_IHttpNegotiate2,0x4f9f9fcb,0xe0f4,0x48eb,0xb7,0xab,0xfa,0x2e,0xa9,0x36,0x5c,0 xb4);
I'm currently in the process of trying to get compilation of DLLs working again with MSVC and the winapi tools and noticed a specific issue with GUIDs. Maybe I can learn a bit here.
If it helps any, I've tied together the current set of patches against MinGW's w32api. They are available from here:
http://www.astro.gla.ac.uk/users/paulm/Cross/mingw-w32api-patches-2006-01-09...
(BTW, Hans maintains RPMs of modified MinGW here: http://mirzam.it.vu.nl/mingw/ )
For instance the GUIDs IID_IAVIStreaming and CLSID_AVIFile used in avifil32.dll are put by wine in the uuid.lib/dll file but the two MS SDKs I tried do not seem to provide these exports in either uuid.lib nor vfw32.lib(avifil32.dll).
Sorry, can't help you with SDKs. Both are defined in avifil32.def in MinGW's w32api v3.3.
HTH,
Paul.
-
Paul Millar -
Rolf Kalbermatter -
Saulius Krasuckas