Re: [webkit-dev] Switching to new-run-webkit-tests
Update: Leopard Release, Gtk and Qt have been successfully transitioned. The Leopard Debug bot has a stray httpd process (without corresponding /tmp/WebKit/httpd.pid) and will require manual intervention: http://build.webkit.org/builders/Leopard%20Intel%20Debug%20%28Tests%29/builds/32086/steps/layout-test/logs/stdio If someone at Apple could give it a kick, I'd be most grateful. I'll work on the WebKit2 ports more tomorrow. I'll need some help with Windows eventually. -eric p.s. As previously noted, run-webkit-tests is calling new-run-webkit-tests with --child-processes=1. So the bots are running in very very slow mode (about as fast as ORWT was). We'll turn on parallel testing with new-run-webkit-tests once we've transitioned all ports. On Tue, Jul 5, 2011 at 10:53 PM, Eric Seidel e...@webkit.org wrote: Update: Snow Leopard - Successful transition. Leopard - Had to roll-back due to a bug in webkitdirs.pm which errors in both ORWT and NRWT, but causes NRWT to fail hard. https://bugs.webkit.org/show_bug.cgi?id=63973 Gtk - Bot seems hard-hung (unclear if NRWT related). Waiting for assistance from a maintainer. Qt - All tests were crashing before I moved to NRWT (http://build.webkit.org/builders/Qt%20Linux%20Release/builds/35024/steps/layout-test/logs/stdio) all tests still crash after moving to NRWT (http://build.webkit.org/builders/Qt%20Linux%20Release/builds/35032/steps/layout-test/logs/stdio). Waiting for the Qt guys to wake. Windows - Have not attempted transition, will likely need some help. https://bugs.webkit.org/show_bug.cgi?id=38756 WebKit2 - Working on remaining blockers, plan to switch over tonight or tomorrow. https://bugs.webkit.org/show_bug.cgi?id=56729 Thanks for your patience in this process. Please let me know if you see any issues you think we may have missed. We're still watching the bots and fixing issues as they appear. -eric On Tue, Jul 5, 2011 at 4:03 PM, Eric Seidel e...@webkit.org wrote: We've turned NRWT back on for the WebKit1 Snow Leopard bots. We believe we've solved the http-lock issue and will be monitoring the bots. -eric On Fri, Jul 1, 2011 at 5:54 PM, Adam Barth aba...@webkit.org wrote: Thanks for your patience with the disruptions on the tree today. The bots are having some trouble with the HTTP lock that don't manifest locally or on our test slave. I've turned NRWT back off while we try to sort that out. Thanks, Adam On Fri, Jul 1, 2011 at 12:49 AM, Adam Barth aba...@webkit.org wrote: Sorry, no switch over tonight. The WebKit2 build is too destroyed to have any confidence that we're doing things correctly and the Snow Leopard buildbot appears to have an errant HTTP server bound to port 8080. :( Adam On Thu, Jun 30, 2011 at 11:47 AM, Adam Barth aba...@webkit.org wrote: According to https://bugs.webkit.org/show_bug.cgi?id=34984, there are only two remaining blocking issues: 1) Teaching new-run-webkit-tests to understand the difference between WebProcess crashes and other sorts of crashes in WebKit2. 2) Fixing some issues with the Apple Windows port. Once we get (1) fixed (hopefully today), we're going to start moving (non-Windows) ports over to new-run-webkit-tests (hopefully tonight). I suspect more issues will crop up once we actually flip the switch. Please do not hesitate to contact Eric or myself (either via #webkit or via bugs.webkit.org). We'll try to respond to any issues that arise as quickly as possible. Thanks for your patience. Adam On Mon, Jun 27, 2011 at 4:26 PM, Xan Lopez x...@gnome.org wrote: On Tue, Jun 28, 2011 at 1:17 AM, Eric Seidel e...@webkit.org wrote: There appear to be 6 remaining blocking issues: https://bugs.webkit.org/showdependencytree.cgi?id=34984hide_resolved=1 We would like to hear from others who have tried new-run-webkit-tests, if they have issues which they believe should block migrating to NRWT. (If so, please file and block the master bug!) I can see the GTK+ port thing with Xvfb is there already, so not a lot to add. NWRT is more sensitive to slow tests than the old infrastructure, so we had to add a bunch of them to the expectations file; I don't think this is particularly bad. In any case with the Xvfb patch and my local expectations file things run beautifully and way faster than before, so looking great from our side! Xan Thanks. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Switching to new-run-webkit-tests
[Sending with the right address...] On Wed, Jul 6, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: Update: Leopard Release, Gtk and Qt have been successfully transitioned. What do we exactly consider successfully transitioned? The GTK+ bots were still failing, so I reverted to the old script. At the very least we know that we need to update our Skipped/expected results file when we switch, because NWRT is more sensitive to slow tests/timeouts and we need to flag a bunch of tests as such. I didn't know you were planning to transition already for us, that's why we didn't push those changes yet. Sorry for the misunderstanding! Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
No problem. I leave it in your hands to re-transition, since you're much more familiar with the platform than I. It was faling before the move, and failing again after. :) The bots have simply been red today. I'm happy to work with you to update the skipped lists. -eric On Wed, Jul 6, 2011 at 2:20 AM, Xan xan.lo...@gmail.com wrote: On Wed, Jul 6, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: Update: Leopard Release, Gtk and Qt have been successfully transitioned. What do we exactly consider successfully transitioned? The GTK+ bots were still failing, so I reverted to the old script. At the very least we know that we need to update our Skipped/expected results file when we switch, because NWRT is more sensitive to slow tests/timeouts and we need to flag a bunch of tests as such. I didn't know you were planning to transition already for us, that's why we didn't push those changes yet. Sorry for the misunderstanding! Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?
On Jul 5, 2011, at 4:51 PM, Dirk Pranke wrote: On Tue, Jul 5, 2011 at 3:46 PM, Ojan Vafai o...@chromium.org wrote: We could simplify the syntax somewhat to not require the = PASS at the end. We could also change the bug format to be actual links instead (e.g. webkit.org/b/12345 and crbug.com/12345). webkit.org/b/12345 : fast/canvas/canvastest.html You can also list multiple bug per line: webkit.org/b/12345 webkit.org/b/3 : fast/canvas/canvasttest.html That seem OK? I like the idea of using links for bugs. Then it's easy to look it up without having to manually translate it. You could even go nuts and include the http://. I'm not so much a fan of this change. It's more typing and I'm not sure if it makes anything much easier for the user (maybe viewing in a text editor that will automatically hyperlink the text, I guess). Using a bug URL should in theory require no typing, you just cut and paste it. Unfortunately the default display URL for bugs is longer than the format above (https://bugs.webkit.org/show_bug.cgi?id=12345 instead of http://webkit.org/b/12345) but I am sure we could fix that if we cared to. And yes, it's easier on the reader, because you can just cut paste the bug URL instead of having to convert BUGWK12345 into something usable, even if not using a text editor that highlights links. And you can paste it into IRC or an email and it is usable to your reader, again without having to translate. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
Xan and I found the issue regarding the timeouts, and Xan is trying NRWT again on the machine: https://bugs.webkit.org/show_bug.cgi?id=63983 On Wed, Jul 6, 2011 at 2:20 AM, Xan xan.lo...@gmail.com wrote: On Wed, Jul 6, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: Update: Leopard Release, Gtk and Qt have been successfully transitioned. What do we exactly consider successfully transitioned? The GTK+ bots were still failing, so I reverted to the old script. At the very least we know that we need to update our Skipped/expected results file when we switch, because NWRT is more sensitive to slow tests/timeouts and we need to flag a bunch of tests as such. I didn't know you were planning to transition already for us, that's why we didn't push those changes yet. Sorry for the misunderstanding! Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
On Jul 6, 2011, at 11:53 AM, Adam Roben wrote: Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. Two specific questions I have: 1) Are the ports that have switched to NRWT no longer using Skipped files? 2) Are the ports that have switched to NRWT now using test_expectations.txt files? But I'm interested in a more general overview, too. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
I'm not sure we've quite figured that out yet. NRWT supports both Skipped lists and test_expectations.txt, which is a more expressive (but also more complex) version of Skipped lists. IMHO, we should wait for the dust to settle on the transition before changing our practices. Adam On Wed, Jul 6, 2011 at 8:53 AM, Adam Roben aro...@apple.com wrote: Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On Jul 6, 2011, at 11:58 AM, Adam Barth wrote: I'm not sure we've quite figured that out yet. NRWT supports both Skipped lists and test_expectations.txt, which is a more expressive (but also more complex) version of Skipped lists. IMHO, we should wait for the dust to settle on the transition before changing our practices. OK. Then I have another question: What should I do to make the Leopard and SnowLeopard bots green, now that they have switched to NRWT? -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On Wed, Jul 6, 2011 at 9:00 AM, Adam Roben aro...@apple.com wrote: OK. Then I have another question: What should I do to make the Leopard and SnowLeopard bots green, now that they have switched to NRWT? Looking at http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r90458%20(31133)/results.html You can http/tests/cookies/third-party-cookie-relaxing.html and storage/domstorage/localstorage/storagetracker/storage-tracker-7-usage.html are real failures so you can add skip those, rebaseline, or revet changes that caused the failure. For flaky tests, you can add BUG# : http/tests/misc/favicon-loads-with-icon-loading-override.html = TEXT PASS in mac or mac-leopard test_expectations.txt Although flaky tests only make the bots orange. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Skipped vs. test_expectations.txt, WAS Switching to new-run-webkit-tests
We've intentionally left that decision up to the ports. Mac has a stop-gap test_expectations.txt file, which depending on the result of this discussion will likely be expanded, or removed: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/test_expectations.txt That exists solely to record tests which are flaky under NRWT but run normally under ORWT, but can easily be replaced with Skipped entries now that we've switched. Qt (as of 23 minutes ago) has a similar file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/qt/test_expectations.txt -eric On Wed, Jul 6, 2011 at 8:58 AM, Adam Roben aro...@apple.com wrote: On Jul 6, 2011, at 11:53 AM, Adam Roben wrote: Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. Two specific questions I have: 1) Are the ports that have switched to NRWT no longer using Skipped files? 2) Are the ports that have switched to NRWT now using test_expectations.txt files? But I'm interested in a more general overview, too. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On Wed, Jul 6, 2011 at 9:00 AM, Adam Roben aro...@apple.com wrote: On Jul 6, 2011, at 11:58 AM, Adam Barth wrote: I'm not sure we've quite figured that out yet. NRWT supports both Skipped lists and test_expectations.txt, which is a more expressive (but also more complex) version of Skipped lists. IMHO, we should wait for the dust to settle on the transition before changing our practices. OK. Then I have another question: What should I do to make the Leopard and SnowLeopard bots green, now that they have switched to NRWT? Looking at Leopard, there's one jscore-test issue and two run-webkit-test issues: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r90460%20(33799)/results.html One of the run-webkit-test issues seems to relate to -0. It's possible that's a test harness issue, but it seems more likely that it's a regression in JavaScriptCore. The other is some SVG foreign object issue, which I have less insight into. We can either fix the regressions, update the expected.txt files, or add the test to the Skipped list, as before. On SnowLeopard, there are also two failing tests, but I believe these tests are related to the NRWT transition: http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r90458%20(31133)/results.html The third-party-cookie-relaxing.html test probably needs to be changed because it depends on the persistent state of the cookie jar. Either Eric or I will dig into the test to figure out how to make it more robust. The storagetracker tests also have similar issues. They appear to be flaky with NRWT, which is https://bugs.webkit.org/show_bug.cgi?id=57799. These tests are also flaky under ORWT (but less so): https://bugs.webkit.org/show_bug.cgi?id=58835 https://bugs.webkit.org/show_bug.cgi?id=58836 We need to fix both issues, but they didn't seem like issues that should block the change to NRWT. That's a somewhat round-about way of not answering your question. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using Skipped vs. test_expectations.txt, WAS Switching to new-run-webkit-tests
Nm, Adam Barth already split the thread in a nicer name too. Folks can reply there. :) On Wed, Jul 6, 2011 at 9:12 AM, Eric Seidel e...@webkit.org wrote: We've intentionally left that decision up to the ports. Mac has a stop-gap test_expectations.txt file, which depending on the result of this discussion will likely be expanded, or removed: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/test_expectations.txt That exists solely to record tests which are flaky under NRWT but run normally under ORWT, but can easily be replaced with Skipped entries now that we've switched. Qt (as of 23 minutes ago) has a similar file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/qt/test_expectations.txt -eric On Wed, Jul 6, 2011 at 8:58 AM, Adam Roben aro...@apple.com wrote: On Jul 6, 2011, at 11:53 AM, Adam Roben wrote: Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. Two specific questions I have: 1) Are the ports that have switched to NRWT no longer using Skipped files? 2) Are the ports that have switched to NRWT now using test_expectations.txt files? But I'm interested in a more general overview, too. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On Wed, Jul 6, 2011 at 6:29 PM, Eric Seidel e...@webkit.org wrote: NRWT uses both! It will read in all the port's Skipped files, covert them to SKIP text_expectations, and add them to your test_expectations file. http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/webkit.py#L309 For better or worse, NRWT will error out, if you have duplicates in your test_expectations file, including duplicates between your test_expectations file and your Skipped lists. Right, this is what I meant in another email when I said you are not supposed to use both. Cannot really see a sane use case for this to be honest. When I transitioned I basically converted Skipped locally to the new format, got tons of duplicated errors, figured out what was going on and deleted then deleted Skipped. Maybe this is done so that you can leave Skipped as it is and start gradually adding stuff to the new file? Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
On Wed, Jul 6, 2011 at 10:18 AM, Xan Lopez x...@gnome.org wrote: On Wed, Jul 6, 2011 at 6:29 PM, Eric Seidel e...@webkit.org wrote: NRWT uses both! It will read in all the port's Skipped files, covert them to SKIP text_expectations, and add them to your test_expectations file. http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/webkit.py#L309 For better or worse, NRWT will error out, if you have duplicates in your test_expectations file, including duplicates between your test_expectations file and your Skipped lists. Right, this is what I meant in another email when I said you are not supposed to use both. Cannot really see a sane use case for this to be honest. When I transitioned I basically converted Skipped locally to the new format, got tons of duplicated errors, figured out what was going on and deleted then deleted Skipped. Maybe this is done so that you can leave Skipped as it is and start gradually adding stuff to the new file? This was done to make it possible to bring up NRWT on Mac over a year ago. :) I'm happy to look at moving to a different configuration now that the project has (mostly) moved to NRWT. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching to new-run-webkit-tests
On Wed, Jul 6, 2011 at 9:04 AM, Xan Lopez x...@gnome.org wrote: On Wed, Jul 6, 2011 at 5:58 PM, Adam Roben aro...@apple.com wrote: On Jul 6, 2011, at 11:53 AM, Adam Roben wrote: Now that more and more ports are switching to NRWT, it would be great for someone to explain what the best practices are for dealing with failing and flaky tests. Two specific questions I have: 1) Are the ports that have switched to NRWT no longer using Skipped files? 2) Are the ports that have switched to NRWT now using test_expectations.txt files? GTK+ still uses Skipped. NWRT understands both (although you cannot have both at the same time), but of course test_expectations.txt allows much more flexibility. But I'm interested in a more general overview, too. Same here. FWIW, the Chrome test_expectations.txt file has a lengthy introductory comment with some guidelines. I was meaning to stuff all that on a web page and remove it from the chrome test_expectations.txt file (since it's awfully wordy to duplicate in each expectations file, and I think slightly out of date to boot). I'll try to draft up something shortly this afternoon. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?
On Tue, Jul 5, 2011 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jul 5, 2011 at 5:40 PM, Dirk Pranke dpra...@chromium.org wrote: I keep hearing that the syntax is excessively complicated. It's a pretty simple syntax, but even you think that it is complicated, but in what way is it excessively so, given that we actively use all of the features it supports? I find having to type : and = and the ordering of tokens extremely annoying. Given no token can be repeated, why can't we just have a set of space-separated tokens? e.g. BUGCR88230 VISTA : fast/dom/dom-parse-serialize-display.html = PASS TIMEOUT can just be: BUGCR88230 VISTA fast/dom/dom-parse-serialize-display.html PASS TIMEOUT or any of the following (not exhaustive): BUGCR88230 VISTA PASS TIMEOUT fast/dom/dom-parse-serialize-display.html BUGCR88230 PASS TIMEOUT VISTA fast/dom/dom-parse-serialize-display.html PASS TIMEOUT BUGCR88230 VISTA fast/dom/dom-parse-serialize-display.html PASS TIMEOUT VISTA BUGCR88230 fast/dom/dom-parse-serialize-display.html Thanks for the (specific!) feedback :) I personally find your examples to be much harder to parse visually. Partially the advantage to putting the test in the middle of the line is that it makes it easy to separate the stuff on the left from the expectations on the right that actually describe what the result of the test is supposed to be. I grant that it can be unclear which side of the test certain expectations show up on (e.g., SLOW, SKIP). I personally also think that it's annoying to have to specify expectations if you are also skipping the test. One could move the SKIP to the right hand side, but it seems a bit weird to call SKIP an expected result, since the test isn't actually running. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does NRWT let you indicate that a test should fail with a particular failure diff?
On Wed, Jul 6, 2011 at 3:03 PM, Dirk Pranke dpra...@chromium.org wrote: I personally find your examples to be much harder to parse visually. Partially the advantage to putting the test in the middle of the line is that it makes it easy to separate the stuff on the left from the expectations on the right that actually describe what the result of the test is supposed to be. I'm okay with people using such a convention. What annoys me is the fact nrwt bails out early and doesn't run any tests when there is even a single line missing :, =, or BUG12345. In my opinion, all tokens but test path should be optional and when nrwt fails to parse a line, it should just ignore the line and still run the tests. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] parallel painting
On Mon, 2011-06-06 at 17:59 +0530, Monil Parmar wrote: How to use it for gtk launcher...I think it is for safari. A bit late for this answer, but for completeness sake: GtkLauncher is not a full browser, so it doesn't expose many features available in WebKitGTK+. You should use Epiphany or Midori preferably for trying these things. In any of these browsers you can get to the inspector by right-clicking anywhere on the page and selecting 'Inspect Element'. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inconsistency in logging approach
On Thu, 2011-06-23 at 22:26 +0200, Łukasz Ślachciak wrote: They warn user with messaage sth like: WEBKIT_DEBUG is not empty, but this is a release build. Notice that many log messages will only appear in a debug build. Of course to have logging working in GTK you need to turn off LOG_DISABLED macro in Assertions.h. FWIW, that's just because some libraries like libsoup have their own logging that we can enable even in release mode. All of WebKit's LOG() calls are disabled in release builds. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Is there special setup needed to run the WebKit2 tests?
old-run-webkit-tests -2 --debug produces: 107 test cases (1%) had incorrect layout 1 test case (1%) crashed 8 test cases (1%) Web process crashed 24 test cases (1%) had stderr output new-run-webkit-tests -2 --debug (which is what I'm trying to make work better) produces: Regressions: Unexpected text diff mismatch : (96) Regressions: Unexpected DumpRenderTree crashes : (7) (NRWT doesn't understand the difference between WebKitTestRunner/WebProcess and DumpRenderTree yet.) So at least NRWT fails the same as ORWT on my machine. But I was hoping to get closer to the 5 failures the the bots see. Any suggestions? http://trac.webkit.org/wiki/WebKit2 doesn't mention any special setup. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
