[webkit-dev] svn.webkit.org vs buildbots problem
Hi, it seems something strange happens near svn.webkit.org server, because the following buildbots continually fail during the svn buildstep: - http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100 Could you check this problem? PS.: I haven't seen any svn problem from here, a complete checkout took only 5 minutes ( with svn version 1.7.14 (r1542130) ) Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] svn.webkit.org vs buildbots problem
The later error messages are saying to run svn cleanup since one of the svn operations timed out. It could have been a spurious problem with svn.webkit.org, so I think the bot owner(s) should run cleanup and see if the timeouts keep happening. -Bill On Jan 27, 2014, at 6:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, it seems something strange happens near svn.webkit.org server, because the following buildbots continually fail during the svn buildstep: - http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100 Could you check this problem? PS.: I haven't seen any svn problem from here, a complete checkout took only 5 minutes ( with svn version 1.7.14 (r1542130) ) Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] svn.webkit.org vs buildbots problem
Just check the log of the Mac bots. They clobber the repository and try a fresh checkout which fail with timeout again and again, so it must be a real problem near the svn server or client side. --- http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29/builds/354/steps/svn/logs/stdio svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted After this error message buildbot triggers rm -rf: update failed, clobbering and trying again rm -rf /Volumes/Data/slave/mavericks-release-perf-tests/build ... And then tries a fresh checkout which fails with timeout: ... A build/PerformanceTests/Dromaeo/resources/dromaeo/web/tests/sunspider-string-unpack-code.html command timed out: 1200 seconds without output, killing pid 2348 --- Ossy On 01/27/2014 04:40 PM, William Siegrist wrote: The later error messages are saying to run svn cleanup since one of the svn operations timed out. It could have been a spurious problem with svn.webkit.org, so I think the bot owner(s) should run cleanup and see if the timeouts keep happening. -Bill On Jan 27, 2014, at 6:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, it seems something strange happens near svn.webkit.org server, because the following buildbots continually fail during the svn buildstep: - http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100 Could you check this problem? PS.: I haven't seen any svn problem from here, a complete checkout took only 5 minutes ( with svn version 1.7.14 (r1542130) ) Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] svn.webkit.org vs buildbots problem
Oh, you expected me to scroll down the page. :) Shree, please investigate. -Bill On Jan 27, 2014, at 7:52 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Just check the log of the Mac bots. They clobber the repository and try a fresh checkout which fail with timeout again and again, so it must be a real problem near the svn server or client side. --- http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29/builds/354/steps/svn/logs/stdio svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted After this error message buildbot triggers rm -rf: update failed, clobbering and trying again rm -rf /Volumes/Data/slave/mavericks-release-perf-tests/build ... And then tries a fresh checkout which fails with timeout: ... A build/PerformanceTests/Dromaeo/resources/dromaeo/web/tests/sunspider-string-unpack-code.html command timed out: 1200 seconds without output, killing pid 2348 --- Ossy On 01/27/2014 04:40 PM, William Siegrist wrote: The later error messages are saying to run svn cleanup since one of the svn operations timed out. It could have been a spurious problem with svn.webkit.org, so I think the bot owner(s) should run cleanup and see if the timeouts keep happening. -Bill On Jan 27, 2014, at 6:03 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, it seems something strange happens near svn.webkit.org server, because the following buildbots continually fail during the svn buildstep: - http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20%28Perf%29?numbuilds=100 - http://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK1%20%28Tests%29?numbuilds=100 - http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2?numbuilds=100 Could you check this problem? PS.: I haven't seen any svn problem from here, a complete checkout took only 5 minutes ( with svn version 1.7.14 (r1542130) ) Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs
I dislike this change now that's been rolled out. The lack of email notices before confirmed that my patch was OK and I was able to do something else while waiting for review. Now I have to continually revisit the bug page checking to see if more bots have completed and that my patch is good. I think at least the person who submitted the patch should be notified when there's been an error. On Jan 17, 2014, at 4:27 PM, Alexey Proskuryakov a...@webkit.org wrote: This has been implemented, and one unintended consequence is that this noticeably affects how quickly one can iterate on time sensitive patches. It's a huge waste of time that you are no longer informed when a build fails on EWS. This seriously delays urgent work, as you only start working on fixes when you happen to manually poll, or even worse, when a reviewer tells you about build breakage. It's good to not spam everyone, however patch author should be notified by EWS immediately I think. Some ideas: - e-mail; - IRC; - browser notifications when bug page is open. The latter might be best, as it also gives some control over whether to get pinged - keep the bug open if you care, close it if it's not urgent, and you cannot afford distraction now. I filed https://bugs.webkit.org/show_bug.cgi?id=127203 about this. - WBR, Alexey Proskuryakov 16 янв. 2014 г., в 15:09, Ryosuke Niwa rn...@webkit.org написал(а): Okay, let's remove the python paths but keep the style error messages until we can improve the EWS infrastructure. - R. Niwa On Thu, Jan 16, 2014 at 9:41 AM, Timothy Hatcher timo...@apple.com wrote: On Jan 16, 2014, at 2:28 AM, Alexey Proskuryakov a...@webkit.org wrote: 15 янв. 2014 г., в 23:02, Ryosuke Niwa rn...@webkit.org написал(а): I think that it's good to try not dumping build failures into comments right away, and to see what happens. As for not showing style bot failures, it seems almost certain that this will make them substantially more annoying to work with. Can you describe the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? The workflow is to click on the bubble to see the style errors. e.g. https://webkit-queues.appspot.com/results/6544662978363392 Seems like that would require everyone to manually match errors to code lines indeed, so I object against making this change for style checker warnings. - WBR, Alexey Proskuryakov Yeah, seeing the style warnings as a comment (which also causes them to show up in the patch review) is helpful. I was just complaining about the python path spew it also includes. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] GTK+ EWS bot lagging behind
Hello, there are currently 93 patches in the GTK+ EWS patch queue, is it stuck? If it’s not, I think it’s completely unreasable to expect committers to wait for 93 patches to be processed before landing. (This lead to a problem this weekend where I removed code from WebCore that was used by GTK+ WebKit and I couldn’t tell because the patch was never processed!) - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Merging back the jsCStack branch
Hello WebKitters, The JavaScriptCore team is planning on merging back our temporary development branch (at http://trac.webkit.org/browser/branches/jsCStack) that we’ve been working on for the past couple of months. The primary features that this branch will bring to trunk are: (1) JavaScript code in JavaScriptCore now runs exclusively on the C stack. Previously JavaScriptCore made use of the C stack only for calls into its C++ runtime, and it used a separate custom stack data structure for execution of compiled JavaScript code. Now it’s all C stack all the time. This work was primarily in support of the next feature... (2) More FTL goodness. The FTL already existed in trunk, but the most recent bleeding edge work has been done on the branch since that work depended on the other C-stack-related work. It will still be behind #ifdefs, and it won’t be compiled by default. The plan is to merge back early tomorrow morning so that if there are any major issues they won’t cause any significant impact. I’ll be available via IRC and email to help with any problems. Let me know if this plan doesn’t work for you. Thanks! -Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK+ EWS bot lagging behind
On Mon, Jan 27, 2014 at 5:55 PM, Anders Carlsson ander...@apple.com wrote: Hello, there are currently 93 patches in the GTK+ EWS patch queue, is it stuck? If it’s not, I think it’s completely unreasable to expect committers to wait for 93 patches to be processed before landing. (This lead to a problem this weekend where I removed code from WebCore that was used by GTK+ WebKit and I couldn’t tell because the patch was never processed!) It just looks like the bot is wedged. I'll try to run a local EWS until it's unwedged. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
