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 adam@tpetaccia.com'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
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 adam@tpetaccia.com'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.
On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens paul.vriens.wine@gmail.com 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
Dan Kegel wrote:
On Tue, Aug 19, 2008 at 1:35 AM, Paul Vriens paul.vriens.wine@gmail.com 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.
-
Dan Kegel -
Paul Vriens