Patchwatcher status: offline
My house is being rewired, so Patchwatcher is offline for a day.
Patchwatcher status
Patchwatcher is down for the moment - I mistakenly tried using proprietary nvidia drivers, forgetting that my nvidia card is too old to be supported, and don't have time this morning to recover. I'll fix it tonight.
patchwatcher status: online but no email
Patchwatcher is now working well enough to depend on, I think, but doesn't send email yet. You should see your patch appear at http://kegel.com/wine/patchwatcher/results under a minute after you post, and if your patch is simple, test results should show up about ten minutes later. (Long patch series take longer, since patchwatcher runs the test suite after each patch in the series.) Today's changes (from http://code.google.com/p/winezeug/source/list ): - Update the dashboard immediately upon receiving patches. - Added qmgr timeout and winhttp:notification.c to blacklist. Full blacklist at http://winezeug.googlecode.com/svn/trunk/patchwatcher/blacklist.txt Please fix your tests so I don't have to blacklist them. (The d3d tests should start passing once I move to the latest nvidia drivers, so don't worry about them.)
Re: patchwatcher status: online but no email
On Thu, 2008-11-06 at 08:32 -0800, Dan Kegel wrote: You should see your patch appear at http://kegel.com/wine/patchwatcher/results Very nice! One suggestion that I have is changing the background color of the row on hover so you can easily match the result on the RHS to the Subject, right now that is a bit difficult to do visually on a wide-screen monitor. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: patchwatcher status: online but no email
On Thu, Nov 6, 2008 at 9:07 AM, Dimi Paun [EMAIL PROTECTED] wrote: One suggestion that I have is changing the background color of the row on hover so you can easily match the result on the RHS to the Subject, right now that is a bit difficult to do visually on a wide-screen monitor. Would you settle for static alternating colors? I'm kind of anti hover highlight.
Re: patchwatcher status: online but no email
On Thu, 2008-11-06 at 09:29 -0800, Dan Kegel wrote: Would you settle for static alternating colors? I'm kind of anti hover highlight. IIRC there was a recent study claiming that alternating row colors are not all that useful in practice, the on-hover has the advantage of focusing your attention only on the row that you care about. But if you have a problem with that, static colors would be a step forward (and AFAIAC it would be fine). -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
patchwatcher status: still coming up (ouch)
The new patchwatcher is sort of up; I'm focusing on things like getting the load balancing and blacklist right before I even think about email output. You can look at the results at http://kegel.com/wine/patchwatcher/results2/ but they will probably not be very reliable for a few more days. (And if anybody wonders why the heck I'm looking at this at 4AM, it's because my 5 year old climbed into our bed upside-down a few minutes ago and kicked me out in his sleep. Those little legs can do a lot of damage when they're aimed at your head :-)
patchwatcher status: still offline
Let me know if these updates get annoying. I'm bringing up a three-node patchwatcher cluster (master plus two build slaves), and updating http://winezeug.googlecode.com/svn/trunk/patchwatcher/readme.txt as I go. It's coming along ok, but it'll probably be another few days before it's up. - Dan
Re: Patchwatcher status
On Thu, 4 Sep 2008 09:45:52 -0700 Dan Kegel [EMAIL PROTECTED] wrote: The new machine has a fairly modern nvidia card, so more of the tests are actually run. Where can I find the spec of the new machine ? Are you using the closed source driver ? I want to see the full system spec hardware and software please. By the way thank you for your hard work.
patchwatcher status: offline
I'm taking the patchwatcher machines down to upgrade them to Intrepid Ibex this weekend. Incidentally, a jaguar plowed through the corner of our garage here at home. For a short while it was a 2.1 car garage :-) I may be somewhat distracted until that's dealt with somehow. - Dan
patchwatcher status
Both old and new patchwatcher: - fixed the displayed time of patches on the results web page. New patchwatcher: - for some reason it wasn't looking for all the errors the old one did. Fixed. - for some reason I had forgotten to have it actually watch for new commits in git. Fixed. - Better at logging errors during 'make depend' etc.
patchwatcher status: ready for volunteers to get working on bsd/solaris/mac
Blacklisted wininet:http.c because it relies on winehq.org being up and serving php properly :-) Fixed enough problems with the new patchwatcher that it seems to be running tests properly. You can see the new patchwatcher's results at http://kegel.com/wine/patchwatcher/results2/ The results should agree with the original patchwatcher, http://kegel.com/wine/patchwatcher/results/ Now I just have to get the email and web reporting smoothed out, then I can consider turning the old one off and turning on the new one's email notifications. Then it should be pretty easy to add new slave build machines to speed up the build or add new slave types (e.g. windows, valgrind, macosx, bsd, solaris). Now is a good time for bsd / macosx / solaris enthusiasts to jump in and get patchwatcher running on their favorite OS or compiler. Patches gladly accepted. If alternate platforms or compilers are working well and are worth integrating into the main patchwatcher instance, I'll do it. The code's all in svn at http://code.google.com/p/winezeug/source/browse/#svn/trunk/patchwatcher as usual. The new patchwatcher is described in readme.txt. Have fun! - Dan
Patchwatcher status
I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. I'm slowly bringing up a second patchwatcher using the newly refactored code. I even wrote some documentation on how to set up a patchwatcher instance: http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/readme.txt I don't really recommend anybody (but Rob) try to do this until we finish working out the bugs, though.
Re: Patchwatcher status
On Sunday 26 October 2008 23:00:51 Dan Kegel wrote: I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. Samba has a socket wrapper library that fakes network access. It's not going to work on Wine the way Samba did it (I tried and failed), but I'd be interested in implementing something similar for Wine. Ideally, it'd be compatible to Samba so I can use it for testing, but there's no reason the internet tests can't use that as well. The issue here is that we need to do some pre-setup on the environment we run in, ideally in a way that works on Windows as well. This seems to be hard, so I might be overengineering things. If you think something that for now only runs on Wine would be useful, I can give that a shot. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status
Dan Kegel wrote: I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. I'm slowly bringing up a second patchwatcher using the newly refactored code. I even wrote some documentation on how to set up a patchwatcher instance: http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/readme.txt I don't really recommend anybody (but Rob) try to do this until we finish working out the bugs, though. Dan: +1, unless the test case specifically is to test Internet connectivity. James McKenzie
Re: Patchwatcher status
Kai wrote: Dan Kegel [EMAIL PROTECTED] wrote: I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. Samba has a socket wrapper library that fakes network access... I was thinking of something cruder: an option that causes all hostname-to-IP-address resolution to resolve to 127.0.0.1, and then make that the default when running conformance tests. It would break lots of tests, so we would have to mark them todo_wine at the same time, or something.
Re: Patchwatcher status
From: Dan Kegel [EMAIL PROTECTED] wrote: I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. If a test fails due to missing internet access that's a bug in the test. The test should be skipped in such a case, and many tests already behave that way. Do you have a list of broken tests? -- Dmitry.
Re: Patchwatcher status
On Sun, Oct 26, 2008 at 8:56 PM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: I'm running into http://bugs.winehq.org/show_bug.cgi?id=15716 more and more often. We really need to set up mock servers so test cases don't need to rely on the public internet. If a test fails due to missing internet access that's a bug in the test. The test should be skipped in such a case, and many tests already behave that way. Do you have a list of broken tests? No, but it will be easy to generate once we have an option to cause all name resolution to return 127.0.0.1.
Patchwatcher status
The blacklist has grown a bit, adding d3d8:visual.c winhttp:Timeout...Killing.child wldap32:parse.c wldap32/tests/__test__ Rob has been busy helping get the distributed patchwatcher scripts working. He has a msvc9 build slave coming along nicely(!). I've ordered a second computer to use as a second build slave, and am considering how to get the latency of valgrind runs low enough to be useful. (I think I've going to add a filter to the alarm.c I pass as WINETEST_WRAPPER, and use that to select which part of the test suite each build slave should run. That way I can have five build slaves each doing a fifth of the test suite in parallel.) It's not quite trivial to get this all going, so no idea when it'll be online. - Dan
patchwatcher status
The most pressing issue for patchwatcher is to finish the refactoring into libpatchwatcher.sh and wine-slave.sh. I made a tiny bit of progress there today by applying some typo fixes Rob sent me, and adding the missing timeout enforcement that was already in the monolithic patchwatcher. (Checked in to svn if anyone cares, but not yet useful.) I also added winhttp/tests/__test__ to the blacklist, since it's failed now for three unrelated patches. - Dan
Patchwatcher status: added urlmon:protocol.c and urlmon:url.c to blacklist
These tests failed randomly for a few people: urlmon:url.c:2125: Test succeeded inside todo block: unexpected OnProgress_CONNECTING urlmon:url.c:2129: Test failed: expected OnProgress_SENDINGREQUEST urlmon:url.c:2131: Test failed: expected OnResponse urlmon:protocol.c:1597: Test failed: Read failed: 0001 (0 bytes) urlmon:protocol.c:365: Test failed: expected ReportData urlmon:protocol.c:1598: Test failed: Read failed: 800a (0 bytes) so I've added urlmon:url.c and urlmon:protocol.c to the patchwatcher blacklist, All of the tests that currently touch the real internet probably need to be changed to touch a mock internet if we want to have reliable tests.
Patchwatcher status
Patchwatcher is almost recovered from its move to the new machine. I expect to turn email notifications back on tomorrow. The old machine could only just barely keep up with the patch flow. The new machine is two or so times faster, so it's much, much better at catching up when a patch flood hits it. The new machine has a fairly modern nvidia card, so more of the tests are actually run. To-do list: 1. Figure out what card I need to buy to avoid these: overlay.c:218: Tests skipped: Failed to initialize ddraw overlay.c:89: Tests skipped: Failed to create an overlay - assuming not supported sysparams.c:2313: Tests skipped: Setting depth 24 failed(ret = -2) visual.c:7453: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:8456: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test visual.c:8595: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8595: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:9690: Tests skipped: Sanity check returned an incorrect color(00552200), can't assure the correctness of the tests, skipping 2. Install corefonts to avoid these: font.c:1163: Tests skipped: Arial is not installed font.c:1473: Tests skipped: Arial is not installed font.c:1653: Tests skipped: Arial Black is not installed font.c:1653: Tests skipped: Symbol is not installed 3. Figure out what's causing these: font.c:1879: Tests skipped: Font DejaVu Sans doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Lohit Gujarati doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Lohit Hindi doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Lohit Punjabi doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Lohit Tamil doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Mallige doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Purisa doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font UnBatang doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font UnDotum doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font Vemana2000 doesn't contain 'x', skipping the test font.c:1879: Tests skipped: Font utkal doesn't contain 'x', skipping the test 4. Get the mailing list parser to handle multiple overlapping patch series so it doesn't get stuck when somebody sends a partial one. 5. Bring up my new refactored patchwatcher script. 6. Add multiple worker machines. 7. Bring up valgrind support. 8. Figure out why I have to blacklist the following tests: comctl32:tooltips.c ddraw:visual.c dsound:ds3d.c kernel32:thread.c riched20:editor.c user32:input.c user32:msg.c user32:win.c wininet:http.c 9. Figure out why winmm_test.exe.so wave.c always hangs on my new test machine.
Re: Patchwatcher status
On Fri, Sep 5, 2008 at 2:45 AM, Dan Kegel [EMAIL PROTECTED] wrote: Patchwatcher is almost recovered from its move to the new machine. I expect to turn email notifications back on tomorrow. The old machine could only just barely keep up with the patch flow. The new machine is two or so times faster, so it's much, much better at catching up when a patch flood hits it. The new machine has a fairly modern nvidia card, so more of the tests are actually run. To-do list: 9. Figure out why winmm_test.exe.so wave.c always hangs on my new test machine. I get this too, it should work after doing a `git diff 3995627de20^ dlls/winealsa.drv | patch -Rp1` and recompiling winealsa.drv http://bugs.winehq.org/show_bug.cgi?id=15030
Re: Patchwatcher status
Dan Kegel wrote: Patchwatcher is almost recovered from its move to the new machine. I expect to turn email notifications back on tomorrow. Hi Dan, Are there any changes compared to the email notification a week ago? I've received several emails about a failure with my patches but it turns out they were marked as ignore or Patch already in git.. I'm not sure I should be receiving email about them? -- Cheers, Paul.
Re: Patchwatcher status
On Thu, Sep 4, 2008 at 10:39 AM, Paul Vriens [EMAIL PROTECTED] wrote: Are there any changes compared to the email notification a week ago? I've received several emails about a failure with my patches but it turns out they were marked as ignore or Patch already in git.. I'm not sure I should be receiving email about them? That needs fixing still. (Forgot to put that on the to-do list.)
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 23:58:17 Scott Ritchie wrote: James Hawkins wrote: On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet [EMAIL PROTECTED] wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch. Is your reply sent to wine-patches? Any replies to a patch should be sent to wine-devel unless you're sending another patch. Shouldn't wine-patches have it's reply-to field set to wine-devel then? It has. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I've got to agree with James on that one. Replies to patches should contain a patch or be to wine-devel. Patchwatcher helps to remind people on a policy here. This will also help people who forgot to attach a patch to their email, so I think it's a good idea to not ignore emails without patches. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Kai Blin [EMAIL PROTECTED] writes: On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I've got to agree with James on that one. Replies to patches should contain a patch or be to wine-devel. Patchwatcher helps to remind people on a policy here. This will also help people who forgot to attach a patch to their email, so I think it's a good idea to not ignore emails without patches. Even better patchwatcher should watch for replies on wine-devel, and link the reply to the patch and mark the patch as needing further action on the submitter's part. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Alexandre Julliard wrote: Kai Blin [EMAIL PROTECTED] writes: On Monday 25 August 2008 00:06:29 Henri Verbeet wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I've got to agree with James on that one. Replies to patches should contain a patch or be to wine-devel. Patchwatcher helps to remind people on a policy here. This will also help people who forgot to attach a patch to their email, so I think it's a good idea to not ignore emails without patches. Even better patchwatcher should watch for replies on wine-devel, and link the reply to the patch and mark the patch as needing further action on the submitter's part. Nice way of blocking a patch ;-). -- Cheers, Paul.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. and mark the patch as needing further action on the submitter's part. Even if the message says Great job!? - Dan
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Dan Kegel [EMAIL PROTECTED] writes: On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. and mark the patch as needing further action on the submitter's part. Even if the message says Great job!? Sure, that's not the usual case. In most cases when a patch gets a reply it's because it will need changes. There could of course be a way for a submitter to mark the patch as still valid, but the first action should be to take the patch off the list of committable patches. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. and mark the patch as needing further action on the submitter's part. Even if the message says Great job!? Sure, that's not the usual case. In most cases when a patch gets a reply it's because it will need changes. There could of course be a way for a submitter to mark the patch as still valid, but the first action should be to take the patch off the list of committable patches. Perhaps replies meant to approve of a patch could include a special textual directive to indicate that patchwatcher shouldn't block the patch. Something like: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. -Ken
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. and mark the patch as needing further action on the submitter's part. Even if the message says Great job!? Sure, that's not the usual case. In most cases when a patch gets a reply it's because it will need changes. There could of course be a way for a submitter to mark the patch as still valid, but the first action should be to take the patch off the list of committable patches. Perhaps replies meant to approve of a patch could include a special textual directive to indicate that patchwatcher shouldn't block the patch. Something like: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. -- James Hawkins
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 2:46 PM, James Hawkins [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 1:08 PM, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: On Mon, Aug 25, 2008 at 8:47 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: patchwatcher should watch for replies on wine-devel, and link the reply to the patch Yes. The other similar patchwatching systems I found do this, and ours should, too. and mark the patch as needing further action on the submitter's part. Even if the message says Great job!? Sure, that's not the usual case. In most cases when a patch gets a reply it's because it will need changes. There could of course be a way for a submitter to mark the patch as still valid, but the first action should be to take the patch off the list of committable patches. Perhaps replies meant to approve of a patch could include a special textual directive to indicate that patchwatcher shouldn't block the patch. Something like: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. -- James Hawkins It might be useful if the patch emails themselves contained the patchwatcher documentation. If the mail server could append some instructions onto the patch email we could add some simple directions on how to reply to the patch with an ack etc. Chris
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 20:46:51 James Hawkins wrote: On Mon, Aug 25, 2008 at 1:11 PM, Ken Thomases [EMAIL PROTECTED] wrote: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. Dunno, I find myself replying to patches that fix bugs I worked on myself or that were in my code with things like good catch. I agree with Alexandre that cases like that are seldom enough that we can probably ignore them. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 2:05 PM, Kai Blin [EMAIL PROTECTED] wrote: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. Dunno, I find myself replying to patches that fix bugs I worked on myself or that were in my code with things like good catch. I agree with Alexandre that cases like that are seldom enough that we can probably ignore them. Around where I work, LGTM (looks good to me) is the reply that denotes approval. And then there's the Apache convention of +1. Anyway, I'll recognize one or more of those if and when I get around to adding a wine-devel listener. Might be a couple weeks. - Dan
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Monday 25 August 2008 23:20:40 Dan Kegel wrote: Around where I work, LGTM (looks good to me) is the reply that denotes approval. And then there's the Apache convention of +1. Anyway, I'll recognize one or more of those if and when I get around to adding a wine-devel listener. Might be a couple weeks. Hm, it's getting harder and harder to keep up with this in buildbot. :) Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
James Hawkins wrote: On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet [EMAIL PROTECTED] wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch. Is your reply sent to wine-patches? Any replies to a patch should be sent to wine-devel unless you're sending another patch. Shouldn't wine-patches have it's reply-to field set to wine-devel then? Thanks, Scott Ritchie
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Mon, Aug 25, 2008 at 4:58 PM, Scott Ritchie [EMAIL PROTECTED] wrote: James Hawkins wrote: On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet [EMAIL PROTECTED] wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch. Is your reply sent to wine-patches? Any replies to a patch should be sent to wine-devel unless you're sending another patch. Shouldn't wine-patches have it's reply-to field set to wine-devel then? It is, but for some reason wine-patches is CC'ed instead of the patch sender when you reply-all. -- James Hawkins
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Dan Kegel wrote: On Mon, Aug 25, 2008 at 2:05 PM, Kai Blin [EMAIL PROTECTED] wrote: #patchwatcher approve Such a directive would only be recognized if it's alone on a line. The usual positive reply is 'ACK'. I believe it would be simplest to grep the reply message for ACK to see if a reply is positive. Dunno, I find myself replying to patches that fix bugs I worked on myself or that were in my code with things like good catch. I agree with Alexandre that cases like that are seldom enough that we can probably ignore them. Around where I work, LGTM (looks good to me) is the reply that denotes approval. And then there's the Apache convention of +1. Anyway, I'll recognize one or more of those if and when I get around to adding a wine-devel listener. Might be a couple weeks. Dan: Thank you for adding this. James McKenzie
Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Patchwatcher now regenerates configure and makefiles after each patch, so it can handle patches that change configure.ac. I have enabled email notification to authors of patches that don't build. The script now forwards patches that pass all tests to the mailing list http://groups.google.com/group/wine-patches-filtered so potentially Alexandre could start looking only at that list (though it probably only has two nines of reliability at this point, as patchwatcher doesn't handle every case yet, e.g. it doesn't handle partial resends of patch series).
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Sun, Aug 24, 2008 at 9:38 AM, Dan Kegel [EMAIL PROTECTED] wrote: The script now forwards patches that pass all tests to the mailing list http://groups.google.com/group/wine-patches-filtered so potentially Alexandre could start looking only at that list Hmm. At the moment, patchwatcher will forward parts of a patch series even if some of the series fails; it should probably only forward a patch series if there are no failures in any of its members.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
2008/8/24 Dan Kegel [EMAIL PROTECTED]: On Sun, Aug 24, 2008 at 9:38 AM, Dan Kegel [EMAIL PROTECTED] wrote: The script now forwards patches that pass all tests to the mailing list http://groups.google.com/group/wine-patches-filtered so potentially Alexandre could start looking only at that list Hmm. At the moment, patchwatcher will forward parts of a patch series even if some of the series fails; it should probably only forward a patch series if there are no failures in any of its members. Depends, often if a patch in a series fails the earlier patches can still be applied. Also, that a patch is part of a series doesn't necessarily mean it depends on the previous patches, sending patches as a series is just the easiest thing to do when you've got multiple patches.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch.
Re: Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
On Sun, Aug 24, 2008 at 5:06 PM, Henri Verbeet [EMAIL PROTECTED] wrote: Something else... I sometimes reply to patches, and right now that seems to cause patchwatcher to complain that my mail doesn't contain a patch. Would it be possible to do something about that? I suppose patchwatcher could ignore replies without patch. Is your reply sent to wine-patches? Any replies to a patch should be sent to wine-devel unless you're sending another patch. -- James Hawkins
Patchwatcher status
I think I fixed the charset munging, so patches of non-english stretches of code should work now. That was the last big source of false failure reports, so I'm going to enable email notification to people whose patches fail. I'll probably clear the results page tonight to get rid of all the bogus failure notices caused by the charset conversion bug.
Re: Patchwatcher status
Dan Kegel wrote:
Patchwatcher falsely complained that
[2/17] richedit: Removed assumption about the order of rtf indent
didn't apply because the regexp I used to detect
the end of a patch series falsely matched the
first patch in a series of 1x patches. Here's the fix:
--- patchwatcher.sh (revision 150)
+++ patchwatcher.sh (working copy)
@@ -283,7 +283,7 @@
cat $PATCHES/$NEXT.log
fi
# Use a regexp with a back reference to detect last patch in
a series and break out
-if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt !
egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt
+if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt !
egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt
then
echo In middle of patch series, not wiping tree
NEXT=`expr $NEXT + 1`
And it falsely complained that various of [EMAIL PROTECTED]'s
patches failed because it didn't handle the case of multiple
patch series sent by the same author back to back and mixed
together by email delays. Here's a fix:
--- get-patches.pl (revision 150)
+++ get-patches.pl (working copy)
@@ -147,7 +147,7 @@
$series_num_patches = $num_patches;
}
-if ($series_sender ne $sender) {
+if ($series_sender ne $sender || $series_num_patches != $num_patches) {
#print Ignoring series for now, will try later; sender
$sender, num_patches $num_patches, subject
.$header-get('Subject').\n;
# can't handle multiple series at once just yet, let it sit
return;
That still won't handle the case of two patch series of the same length
being sent back to back by the same author, but that's
ambiguous enough that even humans might be confused,
so it should tide us over until I rewrite the patch series
detector to handle incomplete series better.
I'm on vacation so I can't apply these patches to the running instance,
I'll do it on tuesday.
- Dan
Hi Dan,
Looks like there is something (else?) wrong with checking the patch series.
None of the last patch series (by Juan, James, Rob, Stefan to name a
few) are shown on the results page.
Cheers,
Paul.
Re: Patchwatcher status
On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens [EMAIL PROTECTED] wrote: Looks like there is something (else?) wrong with checking the patch series. None of the last patch series (by Juan, James, Rob, Stefan to name a few) are shown on the results page. Thanks for pointing that out. It got confused by some of the debris from the earlier bug, and was waiting for an imaginary patch to round out a series. This is a known problem: if somebody sends a incomplete patch series, series processing gets stuck while patchwatcher waits for the rest of the series to show up. The real fix will be to make get-patches.pl smarter, and handle several overlapping patch series. Until then, I'll try adding a timeout (say, if a patch is older than two days, I'll discard it). - Dan p.s. Rather than unswizzling the patches mixed up by the patch series bug, I just moved the old results to http://kegel.com/wine/patchwatcher/results.old/ and started over. Sorry, I probably should have been more graceful about that. We probably need to split up results by git revision or month, or it'll get unwieldy. Month, probably, to match the mailing list archives? So there's probably at least one more disruption coming. p.p.s. I fixed one more little bug just now: patches created by svn should now be recognized as needing -p0. - Dan
Re: Patchwatcher status
Dan Kegel wrote: On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens [EMAIL PROTECTED] wrote: Looks like there is something (else?) wrong with checking the patch series. None of the last patch series (by Juan, James, Rob, Stefan to name a few) are shown on the results page. Thanks for pointing that out. It got confused by some of the debris from the earlier bug, and was waiting for an imaginary patch to round out a series. This is a known problem: if somebody sends a incomplete patch series, series processing gets stuck while patchwatcher waits for the rest of the series to show up. The real fix will be to make get-patches.pl smarter, and handle several overlapping patch series. Until then, I'll try adding a timeout (say, if a patch is older than two days, I'll discard it). - Dan p.s. Rather than unswizzling the patches mixed up by the patch series bug, I just moved the old results to http://kegel.com/wine/patchwatcher/results.old/ and started over. Sorry, I probably should have been more graceful about that. We probably need to split up results by git revision or month, or it'll get unwieldy. Month, probably, to match the mailing list archives? So there's probably at least one more disruption coming. p.p.s. I fixed one more little bug just now: patches created by svn should now be recognized as needing -p0. - Dan Hi Dan, The patch series are now on the results page but every patch/test fails with these same message d3d9:device.c:829: Test failed: Screen height is 1024 Cheers, Paul.
Patchwatcher status
Patchwatcher falsely complained that
[2/17] richedit: Removed assumption about the order of rtf indent
didn't apply because the regexp I used to detect
the end of a patch series falsely matched the
first patch in a series of 1x patches. Here's the fix:
--- patchwatcher.sh (revision 150)
+++ patchwatcher.sh (working copy)
@@ -283,7 +283,7 @@
cat $PATCHES/$NEXT.log
fi
# Use a regexp with a back reference to detect last patch in
a series and break out
-if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt !
egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt
+if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt !
egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt
then
echo In middle of patch series, not wiping tree
NEXT=`expr $NEXT + 1`
And it falsely complained that various of [EMAIL PROTECTED]'s
patches failed because it didn't handle the case of multiple
patch series sent by the same author back to back and mixed
together by email delays. Here's a fix:
--- get-patches.pl (revision 150)
+++ get-patches.pl (working copy)
@@ -147,7 +147,7 @@
$series_num_patches = $num_patches;
}
-if ($series_sender ne $sender) {
+if ($series_sender ne $sender || $series_num_patches != $num_patches) {
#print Ignoring series for now, will try later; sender
$sender, num_patches $num_patches, subject
.$header-get('Subject').\n;
# can't handle multiple series at once just yet, let it sit
return;
That still won't handle the case of two patch series of the same length
being sent back to back by the same author, but that's
ambiguous enough that even humans might be confused,
so it should tide us over until I rewrite the patch series
detector to handle incomplete series better.
I'm on vacation so I can't apply these patches to the running instance,
I'll do it on tuesday.
- Dan
Re: Patchwatcher status
On Thursday 14 August 2008 16:38:40 Dan Kegel wrote: What to do, what to do... how about this: are there any python users on the list who would be willing to help adapt buildbot to our needs? I've subscribed to the buildbot list as well, and I'll start looking over the code once I figured out which VCS to install to get the latest greatest buildbot code. I wish people out there could just agree on which VCS is best and use git. ;) If I get the api docs right, the best option seems to be to subclass their mailwatcher to trigger the try --diff. The hardest part will be getting the patch series logic to work or possibly keeping track of the regression tests. On the plus side, it should be possible to run buildslave instances on win32, so perhaps there's a decent way to build and run the tests on win32 native right away as well. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: Patchwatcher status
Have you considered using some of the tools out there for automated builds and looking to integrate patchwatcher to extend them to suit your purpose. A number of the features you suggest below are most likely already implemented within existing automated builds. I currently use buildbot at work for managing builds, and it looks like that it could handle many of your tasks if patchwatcher could be integrated into it. On Wed, Aug 13, 2008 at 10:42:18AM -0700, Dan Kegel wrote: Next steps: - add timeout to handle hanging tests (every day or two I have to kill some test or other). There's no portable way to do this from wine/test.h that works in Win9x, so I'll probably set WINETEST_WRAPPER to run the tests via a wrapper that implements the timeout. Buildbot supports configuable timeouts. - distribute across multiple machines by splitting into master (which watches the patch stream) and slaves (which execute tests). I will probably use http and ftp for this so the slaves can be remote. Also has master slave architecture, and they are also looking to support load balancing in the future. - support multiple architectures (anybody want to run the slaves on MacOSX for me?) Uses python for communications, so only the individual steps need to be cross platform, think configure, make depend and make. - improve the web page to have error counts and perhaps separate links to the build and test logs That's seems more project specific than buildbot, but who knows, it might be implementable in a generic way to suit buildbot. - merge the chroot support (though this will need porting to run on MacOSX) Would have to be added as a custom step - add valgrind as the next step after running tests Supports individual steps - improve the web page generator to show current status (e.g. show the results from make test before starting valgrind) Generates separate logs for each step website is: http://buildbot.net/trac -- Darragh Nothing is foolproof to a sufficiently talented fool.
RE: Patchwatcher status
Patchwatcher is online and giving reasonably good feedback on the patch stream. The bug that caused every patch to be marked 'failed tests' is fixed, and the blacklist is expanded enough that false regressions seem to be rare. You mentioned sporadic test failures in the d3d9:visual and ddraw:visual tests earlier, but I did not have time to look at it back then. Can you send me logs of the failures and successes? I am afraid that the d3d9 failure is a driver bug; I don't know yet what is up with the ddraw test failure
Re: Patchwatcher status
On Thu, Aug 14, 2008 at 2:49 AM, Darragh Bailey [EMAIL PROTECTED] wrote: I currently use buildbot at work for managing builds, and it looks like that it could handle many of your tasks if patchwatcher could be integrated into it. Good idea. Even Mozilla, home of http://www.mozilla.org/tinderbox.html, uses it for everything but SeaMonkey: https://wiki.mozilla.org/Buildbot It looks like buildbot has a new feature (try --diff) that does almost what we want. It doesn't handle patch series, so we would have to concatenate patch series into one big patch to fit for now. They even have mailwatcher thingies, but they're for watching commit messages rather than potential patches. So we'd have to clone and mutate one of those a bit and hook it into try --diff (well, we could keep using my mailwatcher, but that wouldn't be the buildbot way). Also, its timeout is a coarse-grained one, but we also need a timeout for individual tests. That's ok, it's not hard to add into runtests. On the downside, they don't seem to have anything like the report page I have, so we'd need to add that to buildbot. What to do, what to do... how about this: are there any python users on the list who would be willing to help adapt buildbot to our needs? I don't think I can handle it alone, I'm pretty busy. Maybe I should focus on getting valgrind hooked into my existing patchwatcher while somebody else looks at buildbot. I'll join the buildbot mailing list and chat with those guys a bit to see where they think the patchwatcher functionality could fit in. - Dan
Re: Patchwatcher status
On Thu, Aug 14, 2008 at 7:37 AM, Stefan Dösinger [EMAIL PROTECTED] wrote: You mentioned sporadic test failures in the d3d9:visual and ddraw:visual tests earlier, but I did not have time to look at it back then. Can you send me logs of the failures and successes? I am afraid that the d3d9 failure is a driver bug; I don't know yet what is up with the ddraw test failure Sure, I just replied in another thread about that. See also http://bugs.winehq.org/show_bug.cgi?id=10221
Patchwatcher status
Patchwatcher is online and giving reasonably good feedback on the patch stream. The bug that caused every patch to be marked 'failed tests' is fixed, and the blacklist is expanded enough that false regressions seem to be rare. There are still bugs: 1. the dashboard shows no status column for http://kegel.com/wine/patchwatcher/results/32.txt even though http://kegel.com/wine/patchwatcher/results/32.log exists and shows that there was some strange problem in applying the patch. 2. The most recent patch shows up as 'queued' but the link to the patch doesn't work. Results are at http://kegel.com/wine/patchwatcher/results/ and source code is at http://winezeug.googlecode.com Next steps: - add timeout to handle hanging tests (every day or two I have to kill some test or other). There's no portable way to do this from wine/test.h that works in Win9x, so I'll probably set WINETEST_WRAPPER to run the tests via a wrapper that implements the timeout. - distribute across multiple machines by splitting into master (which watches the patch stream) and slaves (which execute tests). I will probably use http and ftp for this so the slaves can be remote. - support multiple architectures (anybody want to run the slaves on MacOSX for me?) - improve the web page to have error counts and perhaps separate links to the build and test logs - merge the chroot support (though this will need porting to run on MacOSX) - add valgrind as the next step after running tests - improve the web page generator to show current status (e.g. show the results from make test before starting valgrind)
