Re: [webkit-dev] When are patches added to EWS Queue?
Hi Brian, We had an issue with the EWS today when the machine ran out of disk. I'm in the process of bringing up a new machine with 10x the disk space. There's nothing you need to do. Everything should get rolling shortly. Adam On Tue, Dec 7, 2010 at 7:20 PM, Brian Weinstein wrote: > I uploaded a patch a couple of hours ago (uplodaded > https://bugs.webkit.org/attachment.cgi?id=75850&action=edit to bug > https://bugs.webkit.org/show_bug.cgi?id=50586). However, after those couple > of hours, it doesn't even look like it has been queued in the EWS system (a > couple of bots EWS bots are idle, and the bubbles don't have numbers on them > to indicate where the patch is in the queue). > > Is there something I can do to add my patch to the queue? Do I need to > re-upload it? > > Thanks, > Brian Weinstein > ___ > 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] When are patches added to EWS Queue?
I uploaded a patch a couple of hours ago (uplodaded https://bugs.webkit.org/attachment.cgi?id=75850&action=edit to bug https://bugs.webkit.org/show_bug.cgi?id=50586). However, after those couple of hours, it doesn't even look like it has been queued in the EWS system (a couple of bots EWS bots are idle, and the bubbles don't have numbers on them to indicate where the patch is in the queue). Is there something I can do to add my patch to the queue? Do I need to re-upload it? Thanks, Brian Weinstein ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
Thanks for the reminder about NO_MMAP. I just tried it out, and things appeared to be slower with it, so it doesn't seem to be a good idea. I'll contact the maintainer about providing fat 32/64-bit binaries by default. The resulting .dmg is 8.5MB (vs. 4.5MB for the i386-only one), so I think the bloat concerns are minimal. Mihai On Tue, Dec 7, 2010 at 4:26 PM, Evan Martin wrote: > It seems from the bug Mihai linked to that the Git+OS X maintainer > thought the only benefit of a 64-bit binary was being able to handle > larger files, but in fact the real benefit is that the increased > address space of a 64-bit binary lets you mmap larger regions. So it > seems reasonable you could convince the maintainer. > > But really, large mmap regions is mostly working around the fact that > Mihai was experiencing mmap taking 40ms. Git Master Shawn Pearce said > to me: "Try compiling Git with make NO_MMAP=1 and tell me how you like > it. Git comes with a "replacement" mmap() implementation that does > malloc()+read(). This was primarily meant for Win32 cases, but might > be useful on Mac OS X." In the old thread on the Git list about OS X > performance that Mihai linked to in his blog post, Linus Torvalds > seemed to indicate that he only expected mmap to have performance > comparable to read on Linux, not on other platforms. > > So I'd maybe suggest trying that as well and then telling the Git+OS X > maintainer which combination of settings is the best. :) > > On Tue, Dec 7, 2010 at 4:14 PM, Eric Seidel wrote: >> Can we evangelize the code.google.com project? >> >> On Dec 7, 2010 4:04 PM, "Mihai Parparita" wrote: >>> After complaining to a Linux-using friend for the n-th time that "git >>> status" was much slower on my Snow Leopard machine than on his Linux >>> box, I decided to look into why this is. As it turns out, most people >>> get git binaries from http://code.google.com/p/git-osx-installer/, >>> which are 32-bit. Switching to 64-bit binaries made git status go from >>> 6.58s to 2.50s (mainly because this does fewer mmaps). >>> >>> You can download a 64-bit binary installer from >>> >>> https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg, >>> or you can build it yourself (more details at >>> >>> http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html). >>> >>> Mihai >>> ___ >>> 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
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
It seems from the bug Mihai linked to that the Git+OS X maintainer thought the only benefit of a 64-bit binary was being able to handle larger files, but in fact the real benefit is that the increased address space of a 64-bit binary lets you mmap larger regions. So it seems reasonable you could convince the maintainer. But really, large mmap regions is mostly working around the fact that Mihai was experiencing mmap taking 40ms. Git Master Shawn Pearce said to me: "Try compiling Git with make NO_MMAP=1 and tell me how you like it. Git comes with a "replacement" mmap() implementation that does malloc()+read(). This was primarily meant for Win32 cases, but might be useful on Mac OS X." In the old thread on the Git list about OS X performance that Mihai linked to in his blog post, Linus Torvalds seemed to indicate that he only expected mmap to have performance comparable to read on Linux, not on other platforms. So I'd maybe suggest trying that as well and then telling the Git+OS X maintainer which combination of settings is the best. :) On Tue, Dec 7, 2010 at 4:14 PM, Eric Seidel wrote: > Can we evangelize the code.google.com project? > > On Dec 7, 2010 4:04 PM, "Mihai Parparita" wrote: >> After complaining to a Linux-using friend for the n-th time that "git >> status" was much slower on my Snow Leopard machine than on his Linux >> box, I decided to look into why this is. As it turns out, most people >> get git binaries from http://code.google.com/p/git-osx-installer/, >> which are 32-bit. Switching to 64-bit binaries made git status go from >> 6.58s to 2.50s (mainly because this does fewer mmaps). >> >> You can download a 64-bit binary installer from >> >> https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg, >> or you can build it yourself (more details at >> >> http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html). >> >> Mihai >> ___ >> 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
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
Can we evangelize the code.google.com project? On Dec 7, 2010 4:04 PM, "Mihai Parparita" wrote: > After complaining to a Linux-using friend for the n-th time that "git > status" was much slower on my Snow Leopard machine than on his Linux > box, I decided to look into why this is. As it turns out, most people > get git binaries from http://code.google.com/p/git-osx-installer/, > which are 32-bit. Switching to 64-bit binaries made git status go from > 6.58s to 2.50s (mainly because this does fewer mmaps). > > You can download a 64-bit binary installer from > https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg , > or you can build it yourself (more details at > http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html ). > > Mihai > ___ > 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] Tip: Use 64-bit git binaries on Mac OS X
After complaining to a Linux-using friend for the n-th time that "git status" was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg, or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html). Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
Hi all, Since this would require a lot of rebaselines anyways, can we also add some enhancements to DRT? I propose to an option to dump as text with images. In many editing tests, we don't need render tree dumps because we care more about how DOM looks like before and after editing operations. However, we also need to verify that selection and caret are rendered properly on multiple occasions, and the only way to do this right now is to use a pixel test. But even then, dumping render tree is not helpful and almost harmful because it doesn't tell us how selection / caret are rendered (this can never be tested by comparing text) and hides some important information about DOM and makes us rebaseline tests whenever there's slight change (that we don't care) in the render tree. James (jamesr) and I talked about this on IRC, and he said this feature will also be useful for repaint tests and canvas tests. We can implement this feature by adding dumpAsTextWithImage to layoutTestController, which forces DRT to dump as text but also outputs the png image. For repainting tests, we can also add dumpRepaintRects to output more information about painting. - Ryosuke On Mon, Dec 6, 2010 at 12:30 PM, David Hyatt wrote: > RenderTreeAsTetxt has a large number of hacks in it that have been put in > over time to keep the dumps from changing too dramatically. Some of these > include: > > (1) Table cells dump incorrect dimensions and positions. > (2) Text nodes dump an incorrect bounding box position. > (3) RenderInlines don't dump their position at all. > (4) The root layer incorporates overflow when it shouldn't. > (5) The root element has a RenderLayer when there has been no need for it > to have a RenderLayer for years. It only has one in order to not change all > the layout tests. > > In addition there is information not being captured that would be useful to > include in the dump. Examples of this include: > > (1) Layout and visual overflow for elements. Right now we're completely > dependent on repaint tests to catch changes in visual overflow. > (2) scrollOrigin for the ScrollView and for overflow sections. > (3) intrinsic padding of table cells. > (4) Transforms and relative positioning offsets > > I'm sure people may have other ideas about things to include in the > geometry dumps that aren't there right now, so send me your suggestions. > > What I'd like to do is have a rebaselining day (probably after the holidays > in January) where we just shut the tree down and all the ports rebaseline to > the new format (with the hacks removed and any changes we want to make > added). > > What do people think of this idea? How can we make sure that a > rebaselining like this goes smoothly? > > dave > (hy...@apple.com) > > > > ___ > 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 do both DOMWindow and Document objects hold SecurityOrigin objects?
At the time when we introduced DOMWindow::securityOrigin, there was a situation where we needed to know the security origin of something but the document wasn't available. Hopefully that reason has disappeared and we can remove DOMWindow::securityOrigin. Adam On Tue, Dec 7, 2010 at 12:16 PM, Sam Weinig wrote: > It is for historical reasons that both have an origin. The idea was that we > were going to move the DOMWindow to be owned by the Document, and when that > was done, remove the DOMWindow's origin. I seem to remember there being a > theoretical time when the two could differ, but looking > at DocumentWriter::begin() now, it seems like we always set both to the same > value. I still think the re-factor to make Document own DOMWindow would > make this much clearer. > -Sam > On Tue, Dec 7, 2010 at 11:53 AM, Darin Adler wrote: >> >> Why does both a DOMWindow and a Document hold a securityOrigin? Is there a >> way we can get rid of one or the other? Are the two equivalent, or is there >> a difference? Is there a time when it’s correct to do >> frame->domWindow()->securityOrigin() and incorrect to do >> frame->document()->securityOrigin(), or vice versa? >> >> -- Darin >> >> ___ >> 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
Re: [webkit-dev] Better approach for JavaScript bindings, especially for the DOM window object
This sounds like a good approach. Historically, we've tried to keep as many of the security checks in the bindings themselves because they might not be applicable for bindings to other languages, such as Objective C. In some cases, like javascript URLs, the API surface in the bindings was too huge, so we moved the security check into WebCore, where a nice choke-pointed existed. I definitely support making the bindings layer as thin as possible. In my ideal world, everything in the bindings would be auto-generated from the IDL, making it harder to introduce correctness or security bugs in the bindings layer (which has a very large "surface area" exposed to web content). I'd be more than happy to review any patches in this area. Adam On Tue, Dec 7, 2010 at 11:25 AM, Darin Adler wrote: > Hi folks. > > I recently noticed that far too much of the logic for the DOM window object > is in the JavaScript bindings rather than in the DOM implementation of the > window object itself. I also see efforts to make a “generic” binding that is > currently used mostly for V8 only but seems intended for later use by JSC. > > I think we’re going about this the wrong way. The general rule for the DOM is > to do the work in the DOM classes rather than in the binding. The job of the > binding is to extract the arguments and call through to the DOM. This is how > we should be doing it. > > Let me give an example. When setting the location attribute of the DOM > window, the binding should extract the active frame and first frame, convert > the value of the attribute to a string, and then call through to the > DOMWindow object. The security logic should be in the DOMWindow.h/cpp file, > not in the binding. > > I know this is a departure from what was in JSDOMWindowCustom.cpp; but that > historic code is not a good template to base future code on. We should desist > in making a cross-JavaScript-engine binding layer for code that doesn’t > belong in the binding layer at all. > > I’m working on a patch for setLocation and then I’ll move on to open and > showModalDialog. > > Once we have done enough of this work, we should be able to remove a lot of > unneeded code from files like BindingSecurity.h, BindingSecurityBase.h, > BindingSecurityBase.cpp, BindingLocation.h, BindingFrame.h, > BindingDOMWindow.h, GenericBinding.h, JSDOMWindowBase.h, and > JSDOMWindowBase.cpp. > > We really don’t want to spread security responsibilities into the bindings. > What the bindings need to do is communicate the scripting context when > calling in the DOM. The DOM can implement security rules and such in a way > that’s independent of the bindings. > > Let me know what you think. > > -- Darin > > ___ > 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] style-queue
I've killed the machine in question. It's out of disk space. The bots on that machine (style-bot, sherriff-bot, cr-linux-ews) will be down until tomorrow. -eric On Tue, Dec 7, 2010 at 11:33 AM, Darin Adler wrote: > On Dec 7, 2010, at 11:09 AM, Eric Seidel wrote: > > > Sorry about the recent noise from the style queue. Its git repo got > corrupted. Adam and I are working on getting to the machine and resetting > its git repo. > > Is there a way to stop the noise in the meantime? I’ve received many more > email messages from bugs I’m cc’d on since you sent this 20 minutes ago. > >-- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why do both DOMWindow and Document objects hold SecurityOrigin objects?
It is for historical reasons that both have an origin. The idea was that we were going to move the DOMWindow to be owned by the Document, and when that was done, remove the DOMWindow's origin. I seem to remember there being a theoretical time when the two could differ, but looking at DocumentWriter::begin() now, it seems like we always set both to the same value. I still think the re-factor to make Document own DOMWindow would make this much clearer. -Sam On Tue, Dec 7, 2010 at 11:53 AM, Darin Adler wrote: > Why does both a DOMWindow and a Document hold a securityOrigin? Is there a > way we can get rid of one or the other? Are the two equivalent, or is there > a difference? Is there a time when it’s correct to do > frame->domWindow()->securityOrigin() and incorrect to do > frame->document()->securityOrigin(), or vice versa? > >-- Darin > > ___ > 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] Why do both DOMWindow and Document objects hold SecurityOrigin objects?
Why does both a DOMWindow and a Document hold a securityOrigin? Is there a way we can get rid of one or the other? Are the two equivalent, or is there a difference? Is there a time when it’s correct to do frame->domWindow()->securityOrigin() and incorrect to do frame->document()->securityOrigin(), or vice versa? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] style-queue
On Dec 7, 2010, at 11:09 AM, Eric Seidel wrote: > Sorry about the recent noise from the style queue. Its git repo got > corrupted. Adam and I are working on getting to the machine and resetting its > git repo. Is there a way to stop the noise in the meantime? I’ve received many more email messages from bugs I’m cc’d on since you sent this 20 minutes ago. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Better approach for JavaScript bindings, especially for the DOM window object
Hi folks. I recently noticed that far too much of the logic for the DOM window object is in the JavaScript bindings rather than in the DOM implementation of the window object itself. I also see efforts to make a “generic” binding that is currently used mostly for V8 only but seems intended for later use by JSC. I think we’re going about this the wrong way. The general rule for the DOM is to do the work in the DOM classes rather than in the binding. The job of the binding is to extract the arguments and call through to the DOM. This is how we should be doing it. Let me give an example. When setting the location attribute of the DOM window, the binding should extract the active frame and first frame, convert the value of the attribute to a string, and then call through to the DOMWindow object. The security logic should be in the DOMWindow.h/cpp file, not in the binding. I know this is a departure from what was in JSDOMWindowCustom.cpp; but that historic code is not a good template to base future code on. We should desist in making a cross-JavaScript-engine binding layer for code that doesn’t belong in the binding layer at all. I’m working on a patch for setLocation and then I’ll move on to open and showModalDialog. Once we have done enough of this work, we should be able to remove a lot of unneeded code from files like BindingSecurity.h, BindingSecurityBase.h, BindingSecurityBase.cpp, BindingLocation.h, BindingFrame.h, BindingDOMWindow.h, GenericBinding.h, JSDOMWindowBase.h, and JSDOMWindowBase.cpp. We really don’t want to spread security responsibilities into the bindings. What the bindings need to do is communicate the scripting context when calling in the DOM. The DOM can implement security rules and such in a way that’s independent of the bindings. Let me know what you think. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch rebaseline problem
Okay, I can look into it after lunch. Sorry for not noticing this before the upgrade. -Bill On Dec 7, 2010, at 11:07 AM, Eric Seidel wrote: > We just have to re-write the relevant buildbot.py code. It's not that hard, > just has to be done. This is probably why the sherriff-bot has been down, > since it depended on that code. > > On Tue, Dec 7, 2010 at 10:58 AM, William Siegrist wrote: > Assuming the xmlrpc was just used to read data about builds/changes/slaves, > the JSON interface should be used instead. If there's something missing from > JSON that the XMLRPC interface had, please let me know. > > Thanks, > -Bill > > > > > On Dec 7, 2010, at 10:49 AM, William Siegrist wrote: > > > The XMLRPC service was removed from buildbot in the latest version (which > > we needed for security fixes). I'm looking into what we can do to replace > > it. Can someone outline what the tools use it for? > > > > -Bill > > > > On Dec 7, 2010, at 10:29 AM, Ryosuke Niwa wrote: > > > >> Isn't this a problem with http://build.webkit.org/? > >> http://build.webkit.org/xmlrpc is 404 on my browser. > >> > >> - Ryosuke > >> > >> On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes wrote: > >> I see the same issue when running 'webkit-patch failure-reason'. Here's > >> the traceback: > >> > >> Traceback (most recent call last): > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > >> line 70, in > >> main() > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > >> line 65, in main > >> WebKitPatch(__file__).main() > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > >> line 308, in main > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > >> line 117, in check_arguments_and_execute > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > >> line 287, in execute > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > >> line 227, in _explain_failures_for_builder > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > >> line 141, in build_for_revision > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > >> line 86, in build > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > >> line 70, in _fetch_build > >> File > >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > >> line 353, in _fetch_xmlrpc_build_dictionary > >> File > >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > >> line 1199, in __call__ > >> return self.__send(self.__name, args) > >> File > >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > >> line 1489, in __request > >> verbose=self.__verbose > >> File > >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > >> line 1243, in request > >> headers > >> xmlrpclib.ProtocolError: >> Not Found> > >> > >> > >> On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: > >> > >>> It would be helpful to see more of the stack trace, but I bet it's > >>> trying to access some URL that doesn't exist, probably on > >>> build.webkit.org. > >>> > >>> Adam > >>> > >>> > >>> On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro > >>> wrote: > > Hi, > > does anyone know anything about this issue executing rebaseline? > > xmlrpclib.ProtocolError: Not Found> > > br > > > ___ > 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 > >> 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@l
[webkit-dev] style-queue
Sorry about the recent noise from the style queue. It's git repo got corrupted. Adam and I are working on getting to the machine and resetting it's git repo. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch rebaseline problem
We just have to re-write the relevant buildbot.py code. It's not that hard, just has to be done. This is probably why the sherriff-bot has been down, since it depended on that code. On Tue, Dec 7, 2010 at 10:58 AM, William Siegrist wrote: > Assuming the xmlrpc was just used to read data about builds/changes/slaves, > the JSON interface should be used instead. If there's something missing from > JSON that the XMLRPC interface had, please let me know. > > Thanks, > -Bill > > > > > On Dec 7, 2010, at 10:49 AM, William Siegrist wrote: > > > The XMLRPC service was removed from buildbot in the latest version (which > we needed for security fixes). I'm looking into what we can do to replace > it. Can someone outline what the tools use it for? > > > > -Bill > > > > On Dec 7, 2010, at 10:29 AM, Ryosuke Niwa wrote: > > > >> Isn't this a problem with http://build.webkit.org/? > http://build.webkit.org/xmlrpc is 404 on my browser. > >> > >> - Ryosuke > >> > >> On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes wrote: > >> I see the same issue when running 'webkit-patch failure-reason'. Here's > the traceback: > >> > >> Traceback (most recent call last): > >> File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 70, in > >> main() > >> File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 65, in main > >> WebKitPatch(__file__).main() > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 308, in main > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 117, in check_arguments_and_execute > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 287, in execute > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 227, in _explain_failures_for_builder > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 141, in build_for_revision > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 86, in build > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 70, in _fetch_build > >> File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 353, in _fetch_xmlrpc_build_dictionary > >> File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1199, in __call__ > >> return self.__send(self.__name, args) > >> File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1489, in __request > >> verbose=self.__verbose > >> File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1243, in request > >> headers > >> xmlrpclib.ProtocolError: 404 Not Found> > >> > >> > >> On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: > >> > >>> It would be helpful to see more of the stack trace, but I bet it's > >>> trying to access some URL that doesn't exist, probably on > >>> build.webkit.org. > >>> > >>> Adam > >>> > >>> > >>> On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro < > a...@igalia.com> wrote: > > Hi, > > does anyone know anything about this issue executing rebaseline? > > xmlrpclib.ProtocolError: 404 Not Found> > > br > > > ___ > 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 > >> 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 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch rebaseline problem
Assuming the xmlrpc was just used to read data about builds/changes/slaves, the JSON interface should be used instead. If there's something missing from JSON that the XMLRPC interface had, please let me know. Thanks, -Bill On Dec 7, 2010, at 10:49 AM, William Siegrist wrote: > The XMLRPC service was removed from buildbot in the latest version (which we > needed for security fixes). I'm looking into what we can do to replace it. > Can someone outline what the tools use it for? > > -Bill > > On Dec 7, 2010, at 10:29 AM, Ryosuke Niwa wrote: > >> Isn't this a problem with http://build.webkit.org/? >> http://build.webkit.org/xmlrpc is 404 on my browser. >> >> - Ryosuke >> >> On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes wrote: >> I see the same issue when running 'webkit-patch failure-reason'. Here's the >> traceback: >> >> Traceback (most recent call last): >> File >> "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", >> line 70, in >> main() >> File >> "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", >> line 65, in main >> WebKitPatch(__file__).main() >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", >> line 308, in main >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", >> line 117, in check_arguments_and_execute >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", >> line 287, in execute >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", >> line 227, in _explain_failures_for_builder >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", >> line 141, in build_for_revision >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", >> line 86, in build >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", >> line 70, in _fetch_build >> File >> "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", >> line 353, in _fetch_xmlrpc_build_dictionary >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", >> line 1199, in __call__ >> return self.__send(self.__name, args) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", >> line 1489, in __request >> verbose=self.__verbose >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", >> line 1243, in request >> headers >> xmlrpclib.ProtocolError: > Found> >> >> >> On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: >> >>> It would be helpful to see more of the stack trace, but I bet it's >>> trying to access some URL that doesn't exist, probably on >>> build.webkit.org. >>> >>> Adam >>> >>> >>> On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro >>> wrote: Hi, does anyone know anything about this issue executing rebaseline? xmlrpclib.ProtocolError: >>> Not Found> br ___ 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 >> 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
Re: [webkit-dev] webkit-patch rebaseline problem
The XMLRPC service was removed from buildbot in the latest version (which we needed for security fixes). I'm looking into what we can do to replace it. Can someone outline what the tools use it for? -Bill On Dec 7, 2010, at 10:29 AM, Ryosuke Niwa wrote: > Isn't this a problem with http://build.webkit.org/? > http://build.webkit.org/xmlrpc is 404 on my browser. > > - Ryosuke > > On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes wrote: > I see the same issue when running 'webkit-patch failure-reason'. Here's the > traceback: > > Traceback (most recent call last): > File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 70, in >main() > File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 65, in main >WebKitPatch(__file__).main() > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 308, in main > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 117, in check_arguments_and_execute > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 287, in execute > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 227, in _explain_failures_for_builder > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 141, in build_for_revision > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 86, in build > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 70, in _fetch_build > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 353, in _fetch_xmlrpc_build_dictionary > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1199, in __call__ >return self.__send(self.__name, args) > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1489, in __request >verbose=self.__verbose > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1243, in request >headers > xmlrpclib.ProtocolError: Found> > > > On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: > > > It would be helpful to see more of the stack trace, but I bet it's > > trying to access some URL that doesn't exist, probably on > > build.webkit.org. > > > > Adam > > > > > > On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro > > wrote: > >> > >> Hi, > >> > >> does anyone know anything about this issue executing rebaseline? > >> > >> xmlrpclib.ProtocolError: >> Not Found> > >> > >> br > >> > >> > >> ___ > >> 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 > 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] webkit-patch rebaseline problem
Isn't this a problem with http://build.webkit.org/? http://build.webkit.org/xmlrpc is 404 on my browser. - Ryosuke On Tue, Dec 7, 2010 at 10:19 AM, Andy Estes wrote: > I see the same issue when running 'webkit-patch failure-reason'. Here's the > traceback: > > Traceback (most recent call last): > File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 70, in >main() > File > "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", > line 65, in main >WebKitPatch(__file__).main() > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 308, in main > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", > line 117, in check_arguments_and_execute > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 287, in execute > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", > line 227, in _explain_failures_for_builder > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 141, in build_for_revision > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 86, in build > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 70, in _fetch_build > File > "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", > line 353, in _fetch_xmlrpc_build_dictionary > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1199, in __call__ >return self.__send(self.__name, args) > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1489, in __request >verbose=self.__verbose > File > "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", > line 1243, in request >headers > xmlrpclib.ProtocolError: Not Found> > > > On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: > > > It would be helpful to see more of the stack trace, but I bet it's > > trying to access some URL that doesn't exist, probably on > > build.webkit.org. > > > > Adam > > > > > > On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro > wrote: > >> > >> Hi, > >> > >> does anyone know anything about this issue executing rebaseline? > >> > >> xmlrpclib.ProtocolError: 404 Not Found> > >> > >> br > >> > >> > >> ___ > >> 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 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch rebaseline problem
I see the same issue when running 'webkit-patch failure-reason'. Here's the traceback: Traceback (most recent call last): File "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", line 70, in main() File "/Volumes/Data/Users/aestes/Code/Safari/OpenSource/WebKitTools/Scripts/webkit-patch", line 65, in main WebKitPatch(__file__).main() File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", line 308, in main File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/multicommandtool.py", line 117, in check_arguments_and_execute File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", line 287, in execute File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/tool/commands/queries.py", line 227, in _explain_failures_for_builder File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", line 141, in build_for_revision File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", line 86, in build File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", line 70, in _fetch_build File "/Volumes/Data/Users/aestes/Code/Safari.local/OpenSource/WebKitTools/Scripts/webkitpy/common/net/buildbot.py", line 353, in _fetch_xmlrpc_build_dictionary File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", line 1199, in __call__ return self.__send(self.__name, args) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", line 1489, in __request verbose=self.__verbose File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/xmlrpclib.py", line 1243, in request headers xmlrpclib.ProtocolError: On Dec 7, 2010, at 9:59 AM, Adam Barth wrote: > It would be helpful to see more of the stack trace, but I bet it's > trying to access some URL that doesn't exist, probably on > build.webkit.org. > > Adam > > > On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro > wrote: >> >> Hi, >> >> does anyone know anything about this issue executing rebaseline? >> >> xmlrpclib.ProtocolError: > Found> >> >> br >> >> >> ___ >> 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
Re: [webkit-dev] webkit-patch rebaseline problem
It would be helpful to see more of the stack trace, but I bet it's trying to access some URL that doesn't exist, probably on build.webkit.org. Adam On Tue, Dec 7, 2010 at 1:20 AM, Alejandro Garcia Castro wrote: > > Hi, > > does anyone know anything about this issue executing rebaseline? > > xmlrpclib.ProtocolError: Found> > > br > > > ___ > 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] webkit-patch rebaseline problem
Hi, does anyone know anything about this issue executing rebaseline? xmlrpclib.ProtocolError: br ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
