[webkit-dev] GTK+ release bots are missing results
For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. I'm not sure what the issue is, but the results upload output looks quite sane: http://build.webkit.org/builders/GTK Linux 32-bit Release/builds/8174/steps/MasterShellCommand/logs/stdio It's pretty tough to debug failures on the release bot at the moment. -- Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ release bots are missing results
On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote: For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. I'm not sure what the issue is, but the results upload output looks quite sane: http://build.webkit.org/builders/GTK Linux 32-bit Release/builds/8174/steps/MasterShellCommand/logs/stdio It's pretty tough to debug failures on the release bot at the moment. Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was never made on those bots? -Adam 1. http://article.gmane.org/gmane.os.opendarwin.webkit.devel/14798___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ release bots are missing results
On Dec 1, 2010, at 8:56 AM, Adam Roben wrote: On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote: For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was never made on those bots? Yes, its a umask problem. Gustavo, can you recheck the umask changes you made on gtk-linux-slave-1 and gtk-linux-slave-4? Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ release bots are missing results
On Wed, 2010-12-01 at 09:15 -0800, William Siegrist wrote: On Dec 1, 2010, at 8:56 AM, Adam Roben wrote: On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote: For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was never made on those bots? Yes, its a umask problem. Gustavo, can you recheck the umask changes you made on gtk-linux-slave-1 and gtk-linux-slave-4? Damn, yeah, I made the change but I was not aware the configuration files were actually handled by a centralized configuration system that later restored the configuration file to its original form =/. The centralized configuration system has been taught about the new settings now, and the slaves restarted. Sorry for the mess. Thanks, -- 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] GTK+ release bots are missing results
On Dec 1, 2010, at 10:04 AM, Gustavo Noronha Silva wrote: On Wed, 2010-12-01 at 09:15 -0800, William Siegrist wrote: On Dec 1, 2010, at 8:56 AM, Adam Roben wrote: On Dec 1, 2010, at 11:54 AM, Martin Robinson wrote: For some weeks now the GTK+ release bots have been missing results. When you try to click on any result in results.html, there's an error page. Perhaps the umask change that Bill Siegrist requested a month or so ago [1] was never made on those bots? Yes, its a umask problem. Gustavo, can you recheck the umask changes you made on gtk-linux-slave-1 and gtk-linux-slave-4? Damn, yeah, I made the change but I was not aware the configuration files were actually handled by a centralized configuration system that later restored the configuration file to its original form =/. The centralized configuration system has been taught about the new settings now, and the slaves restarted. Sorry for the mess. Thanks, the permissions of the server have been fixed as well. Let me know if you find any more broken links. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK+ release bots are missing results
On Wed, Dec 1, 2010 at 7:19 PM, William Siegrist wsiegr...@apple.com wrote: On Dec 1, 2010, at 10:04 AM, Gustavo Noronha Silva wrote: Damn, yeah, I made the change but I was not aware the configuration files were actually handled by a centralized configuration system that later restored the configuration file to its original form =/. The centralized configuration system has been taught about the new settings now, and the slaves restarted. Sorry for the mess. Thanks, the permissions of the server have been fixed as well. Let me know if you find any more broken links. Awesome! Things seem to be working now. Thank you for the quick response! Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] minor feature added to new-run-webkit-tests
If you don't ever run new-run-webkit-tests, you can stop reading. If you do, then it might interest you to know that by popular demand (okay, two people), I have added a line that prints the actual command line used to invoke DumpRenderTree as part of the config output, e.g.: $ new-run-webkit-tests -n --print config,default --platform chromium-mac fast/html/keygen.html Defaulting to one child - see https://bugs.webkit.org/show_bug.cgi?id=38553 Using port 'chromium-mac' Placing test results in /Volumes/Src/src/c.wdev/src/webkit/Release/layout-test-results Using Release build Pixel tests enabled Regular timeout: 6000, slow test timeout: 3 Running one TestShell Command line: /Volumes/Src/src/c.wdev/src/xcodebuild/Release/TestShell.app/Contents/MacOS/TestShell --pixel-tests=/Volumes/Src/src/c.wdev/src/webkit/Release/layout-test-results/png_result0.png --layout-tests Worker model: threads $ I have also added the '-n' / '--dry-run' flag, which does everything new-run-webkit-tests normally does except actually run the tests. You can use this to quickly check the configuration info as above, or to sanity check that your build is okay, your test_expectations are okay, etc. I hope this is helpful, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] minor feature added to new-run-webkit-tests
I've wanted this many times. Looks great. On Wed, Dec 1, 2010 at 4:31 PM, Dirk Pranke dpra...@chromium.org wrote: If you don't ever run new-run-webkit-tests, you can stop reading. If you do, then it might interest you to know that by popular demand (okay, two people), I have added a line that prints the actual command line used to invoke DumpRenderTree as part of the config output, e.g.: $ new-run-webkit-tests -n --print config,default --platform chromium-mac fast/html/keygen.html Defaulting to one child - see https://bugs.webkit.org/show_bug.cgi?id=38553 Using port 'chromium-mac' Placing test results in /Volumes/Src/src/c.wdev/src/webkit/Release/layout-test-results Using Release build Pixel tests enabled Regular timeout: 6000, slow test timeout: 3 Running one TestShell Command line: /Volumes/Src/src/c.wdev/src/xcodebuild/Release/TestShell.app/Contents/MacOS/TestShell --pixel-tests=/Volumes/Src/src/c.wdev/src/webkit/Release/layout-test-results/png_result0.png --layout-tests Worker model: threads $ I have also added the '-n' / '--dry-run' flag, which does everything new-run-webkit-tests normally does except actually run the tests. You can use this to quickly check the configuration info as above, or to sanity check that your build is okay, your test_expectations are okay, etc. I hope this is helpful, -- Dirk ___ 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
Re: [webkit-dev] Why are the mock implementations in WebCore/platform?
It seems reasonable to keep mock objects that act solely as the back end to platform/ classes in platform/. I believe Sam was commenting specifically on mock objects that know about things outside platform/. The specific example given was not (afaict) a client interfance. I think it's reasonable to segregate all the mock objects, since their dependencies in general are not limited to platform/, and it doesn't seem great to scatter them around the tree. Refactoring some of the mock objects to reduce dependencies is another possibility, but probably more complicated. It would be good to fix the layering in the meantime as Sam suggested. - Maciej On Nov 26, 2010, at 11:20 AM, Adam Barth wrote: Originally, I thought it made sense to mock out pieces of the platform abstraction that didn't exist in all ports (e.g., GPS sensors). I'm not sure why you'd want to mock out a client interface. Can't you just implement the client interface in DRT? Adam On Fri, Nov 26, 2010 at 10:33 AM, Sam Weinig sam.wei...@gmail.com wrote: Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is not supposed to know about classes outside of WebCore/platform in WebCore (such as DeviceOrientationController) and this seems to be perpetuating the laying violation. Perhaps a top-level WebCore/mock/ would be preferable. - Sam ___ 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
