[chromium-dev] buildbot failure in Chromium on XP Tests, revision 36626

2010-01-20 Thread buildbot 
Automatically closing tree for "unit_tests" on "XP Tests"

http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16523

http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests

--=>  Automatically closing tree for "unit_tests" on "XP Tests"  <=--

Revision: 36626
Blame list: phajdan...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] [LTTF] Q1 Plan

2010-01-20 Thread Dimitri Glazkov 
Greetings, people of Chromium!

Last quarter, the Layout Test Task Force done some pretty good work. I
bragged about it in a separate email. Now it's time to grab the bull by the
horns and kick it up a notch. Isn't idiomatic English great?

This quarter, the LTTF is aiming right at the heart of the problem:
eliminating the need to continually roll WebKit DEPS, baking in layers upon
layers of regressions in the phyllo dough that is our test_expectations
file. To do that, we must move all of our layout test infrastructure, from
test_shell to test expectations to flakiness dashboard upstream.

Based on a few hallway/online/cross-continental conversations, our plan of
action consists of three efforts (drivers in parentheses):

   - Port test_shell into DumpRenderTree (DRT) upstream (Tokyo LTTF team +
   dglazkov + darin)
  - Take care of chromium dependencies: base, net, skia (src/skia, that
  is). How will they manifest themselves upstream to avoid breakage due to
  changes in chromium tree? (dglazkov, darin, tc)
   - Identify strategy for DRT and V8 coexistence: currently all of DRT is
  heavily JSC-dependent. We should either introduce script-independent
  abstractions or convert to NPAPI that we use downstream (dglazkov, darin,
  tc).
   - Figure out for inflight testing. How will we ensure that porting doesn't
  introduce new bugs? Need to come up with a way to have a workable DRT
  quickly, and a way to produce differential of layout test failures to
  quickly find porting bugs.
   - Upstream src/webkit/tools/test_shell to
  WebKitTools/DumpRenderTree/chromium.
  - Coordinate with harness upstreaming effort, so that both
  run-webkit-tests and the new DRT work well together while porting.
  - Determine how we will remove code downstream. We won't need
  DRT-specific code, but may still need test_shell as a
minimum-capabilities
  embedder of WebKit. Or we could go with a MiniBrowser-style project
  (open-source sample for WebKit Apple port) upstream.
  - Drive effort to completion. *Completion is*: DRT is ready to run
  layout tests on build.webkit.org, downstream cleaned up and ready to
  stop running layout tests on build.chromium.org.


   - Upstream test infrastructure (watch detailed plan and assignments
   develop at
   http://dev.chromium.org/developers/design-documents/upstreaminglayouttests).
   Steps include:
  - Move run_webkit_tests.py to live upstream
   - While DRT is being upstreamed, configure to run upstreamed
run_webkit_tests
  on the Chromium builders
  - Move test expectations upstream
   - Move ancilliary tools, like rebaseline.py and flakiness
  dashboard upstream
  - Modify run_webkit_tests to use the newly upstreamed DRT
  - Drive effort to completion. *Completion is*: build.webkit.org is
  running layout tests with no regressions from downstream,
  build.chromium.org no longer runs layout tests.


   - Continue fixing/deflakifying layout tests and improving the process for
   sustaining compatibility.
  - Fix chrome-specific failures that dramatically affect compatibility
  (bug triage -- which means *you*!)
  - Fix SVG/Skia bugs that cause layout test failures (Waterloo team)
  - Fix V8 bugs and develop ES5 features that affect layout tests (V8
  team)
   - Make V8 bindings more tolerant to IDL/JSC changes. Watch the effort as
  a bug tree:
  https://bugs.webkit.org/showdependencytree.cgi?id=32630&hide_resolved=0
   (japhet, kkanetkar)
   - Improve gardening tools and process (dglazkov)
  - Eliminate layout test flakiness (jparent, ojan, dglazkov)
   - Drive effort to completion. *Completion is*: <10 sustained layout test
  failures or flakes, bindings-related regressions/breaks are limited to
  custom code only, new process for keeping up for layout test
regressions is
  adopted by Webkit Gardeners.

As you can see, it's a bit different from "grab a test and fix it" approach
we took in Q4. We learn, right? :) Despite most tasks having a driver in one
form or another, we always welcome your contributions. Every little bit
counts.

:DG<
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Vista Tests, revision 36632

2010-01-20 Thread buildbot 
Automatically closing tree for "unit_tests" on "Vista Tests"

http://build.chromium.org/buildbot/waterfall/builders/Vista%20Tests/builds/15332

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Vista%20Tests

--=>  Automatically closing tree for "unit_tests" on "Vista Tests"  <=--

Revision: 36629, 36630, 36631, 36632
Blame list: 
craig.schlen...@chromium.org,j...@chromium.org,phajdan...@chromium.org,thoma...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 36641

2010-01-20 Thread buildbot 
Automatically closing tree for "compile" on "Chromium XP"

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9782

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP

--=>  Automatically closing tree for "compile" on "Chromium XP"  <=--

Revision: 36639, 36640, 36641
Blame list: a...@chromium.org,kuch...@chromium.org,willc...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Chromium Builder (dbg), revision 36644

2010-01-20 Thread buildbot 
Automatically closing tree for "compile" on "Chromium Builder (dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Builder%20%28dbg%29

--=>  Automatically closing tree for "compile" on "Chromium Builder (dbg)"  <=--

Revision: 36644
Blame list: jor...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: buildbot failure in Chromium on Chromium Builder (dbg), revision 36644

2010-01-20 Thread Jeremy Orlow 
on it.  Sorry.

On Wed, Jan 20, 2010 at 10:52 AM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "compile" on "Chromium Builder (dbg)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Builder%20%28dbg%29/builds/15729
>
> Revision: 36644
> Blame list: jor...@chromium.org
>
>  Chromium Builder (dbg)
> Build 
> 15729
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
> compile
> failed
> stdio
>
> Changed by: *jor...@chromium.org*
> Changed at: *Wed 20 Jan 2010 10:50:07*
> Branch: *src*
> Revision: 
> *36644*
> Changed files:
>
>- *chrome/app/generated_resources.grd*
>- *chrome/browser/cookies_tree_model.cc*
>- *chrome/browser/cookies_tree_model.h*
>- *chrome/browser/gtk/options/cookies_view.cc*
>- *chrome/browser/gtk/options/cookies_view.h*
>- *chrome/browser/in_process_webkit/dom_storage_context.cc*
>- *chrome/browser/in_process_webkit/dom_storage_context.h*
>- *chrome/browser/views/options/cookies_view.cc*
>- *chrome/browser/views/options/cookies_view.h*
>- *chrome/chrome_browser.gypi*
>- *chrome/chrome_tests.gypi*
>
> Comments:
>
> Adds local storage nodes to cookie tree model and cookies view.
>
> BUG=none
> TEST=The show cookie dialog box should have a new node "local storage" when 
> appropriate. When selected, it should display details of local storage (name, 
> size on disk, last modified) in the details frame.
>
> Landing for Marcus
> Original CL: http://codereview.chromium.org/523139/show
>
> Review URL: http://codereview.chromium.org/546081
>
> Properties:
>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: WebKitApi (test_shell) and DevTools, JS debugging

2010-01-20 Thread vridosh 
Hi,

It seems I've already found an answer - JS debugger is viable under
test_shell after a small change:

Index: WebViewImpl.cpp
===
--- WebViewImpl.cpp (revision 53449)
+++ WebViewImpl.cpp (working copy)
@@ -234,7 +234,11 @@
 0));

 m_page->backForwardList()->setClient
(&m_backForwardListClientImpl);
-m_page->setGroupName(pageGroupName);
+
+char pageGroupNameCurr[100];
+static int i = 1;
+sprintf(pageGroupNameCurr, "default%d", i++);
+m_page->setGroupName(pageGroupNameCurr);
 }

 WebViewImpl::~WebViewImpl()

There is a short description:
When hitting a breakpoint, WebKit pauses all active DOM elements in
the current "Page group". Chrome uses only one page group for all
pages, that's why WebKit pauses all active DOM elements including
these one that belong to DevTools page. Ideally, I think it would be
better to provide an ability to set Page Group name through WebKit API
and set custom "Page group" name for DevTools page. As far as one of
WebKit API goals is to allow third-party developers to build their own
apps on it, do you think it will be useful to extend WebKit API in
this way?

Regards,
Vadim Ridosh

On Jan 18, 7:16 pm, vridosh  wrote:
> Hi,
>
> I'm going to start my project based on WebKit API and planning to use
> test_shell as a reference implementation. I also want to use DevTools
> to allow end-user to debug HTML and especially JavaScript.
>
> Could you please tell how viable is the JS debugger in test_shell/
> WebKit API?
>
> As far as I understand, in case of breakpoint V8 debugger stops the
> script execution on the whole process. That problem could be easy
> reproduced while running Chrome in single-process mode (AFAIR, this
> mode is obsolete for modern Chromium browser) - trying to pause script
> execution pauses all JS code, including DevTools JS code too, which
> causes "deadlock" - script couldn't be resumed anymore. As far as I
> understand, that's why Debugger tab was not available in test_shell in
> early Chromium builds. But when I tried to use current test_shell
> build, I was able to pause JS execution on breakpoint and then resume
> JS again. From the other hand, while staying on JS breakpoint not all
> parts of DevTools debugger works well - f.e. I couldn't execute JS in
> console. Also, as I got, pausing JS in any custom place (I mean, left
> button just above watch expressions and call stack) not implemented
> yet it all.
>
> So, the main question is - is it possible at all to make DevTools JS
> debugger in test_shell to work correctly?
>
> I'd appreciate any suggestions.
>
> Regards,
> Vadim Ridosh
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] can't download chrome installer when behind a squid proxy

2010-01-20 Thread Paweł Hajdan , Jr . 
I have a local squid proxy and on Windows machines using it the Chrome
installer never finishes (I can download the first, small .exe which
then initializes and tries to download the main installer). When not
using squid it works fine. When using other proxies like tinyproxy, it
also works fine. But for other reasons I have to use squid.

What's the best way to debug the issue? I can change the settings on
the proxy, capture network traffic, etc. But on the other hand other
.exes download fine, there's just a problem with downloading from
Google.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Moving mailing lists from @googlegroups.com to @chromium.org

2010-01-20 Thread John Abd-El-Malek 
This is a heads up that as part of moving all of our resources to
chromium.org (and vanity!), I'll be switching our mailing lists to be under
chromium.org today.  I will send an email when it's done, but for now you
may want to update your rules to be either googlegroups.com or
chromium.orgso that no emails are mislabelled.

Note that unfortunately there's no way to migrate the old messages.  So I
will subscribe the googlegroups.com lists to the chromium.org ones so that
googlegroups has all the emails.

Please bear with me through the move.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths

2010-01-20 Thread Benjamin Smedberg 
> 1) if there is a ':' in the URI, you split the URI into scheme and
> scheme-specific part.
>
>
No. The first check is "is this an absolute file path". That check is done
with platform-specific logic:

#if windows
if the path matches letter:\ or \\...
#else
if the path starts with a slash
#endif

Then we load it as an absolute file.

Otherwise we load it as a URL relative to file:///[pwd]

--BDS
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on XP Tests, revision 36652

2010-01-20 Thread buildbot 
Automatically closing tree for "unit_tests" on "XP Tests"

http://build.chromium.org/buildbot/waterfall/builders/XP%20Tests/builds/16535

http://build.chromium.org/buildbot/waterfall/waterfall?builder=XP%20Tests

--=>  Automatically closing tree for "unit_tests" on "XP Tests"  <=--

Revision: 36651, 36652
Blame list: jor...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: Moving mailing lists from @googlegroups.com to @chromium.org

2010-01-20 Thread John Abd-El-Malek 
Just to explain to everyone the steps that I will follow.  For each mailing
list, I will:

1) create a corresponding list on chromium.org with the same members
2) subscribe the old list to the new list so that the archives can be
searched in one place
4) disable posting to the old list (only group managers can post)
3) send an email to the old list telling everyone that it's now disabled and
that they must now post to the new list


On Wed, Jan 20, 2010 at 11:08 AM, John Abd-El-Malek wrote:

> This is a heads up that as part of moving all of our resources to
> chromium.org (and vanity!), I'll be switching our mailing lists to be
> under chromium.org today.  I will send an email when it's done, but for
> now you may want to update your rules to be either googlegroups.com or
> chromium.org so that no emails are mislabelled.
>
> Note that unfortunately there's no way to migrate the old messages.  So I
> will subscribe the googlegroups.com lists to the chromium.org ones so that
> googlegroups has all the emails.
>
> Please bear with me through the move.
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] can't download chrome installer when behind a squid proxy

2010-01-20 Thread Eric Roman 
On Wed, Jan 20, 2010 at 10:57 AM, Paweł Hajdan, Jr.
 wrote:
> I have a local squid proxy and on Windows machines using it the Chrome
> installer never finishes (I can download the first, small .exe which
> then initializes and tries to download the main installer). When not
> using squid it works fine. When using other proxies like tinyproxy, it
> also works fine. But for other reasons I have to use squid.
>
> What's the best way to debug the issue? I can change the settings on
> the proxy, capture network traffic, etc. But on the other hand other
> .exes download fine, there's just a problem with downloading from
> Google.

Omaha doesn't support manual authentication for proxies, so if your
squid proxy is requiring a username/password that could be the
problem.

A good way to debug is to capture the traffic with wireshark and see
what requests the installer issued.

>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Modules XP (dbg), revision 36693

2010-01-20 Thread buildbot 
Automatically closing tree for "net_unittests" on "Modules XP (dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/21889

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29

--=>  Automatically closing tree for "net_unittests" on "Modules XP (dbg)"  <=--

Revision: 36692, 36693
Blame list: c...@chromium.org,e...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Webkit Builder (dbg), revision 36699

2010-01-20 Thread buildbot 
Automatically closing tree for "compile" on "Webkit Builder (dbg)"

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Builder%20%28dbg%29/builds/22831

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Builder%20%28dbg%29

--=>  Automatically closing tree for "compile" on "Webkit Builder (dbg)"  <=--

Revision: 36698, 36699
Blame list: dpra...@chromium.org,fin...@chromium.org

Buildbot waterfall: http://build.chromium.org/

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Perf (1), revision 36702

2010-01-20 Thread buildbot 
Automatically closing tree for "compile" on "Linux Perf (1)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf%20%281%29/builds/5173

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf%20%281%29

--=>  Automatically closing tree for "compile" on "Linux Perf (1)"  <=--

Revision: 36697, 36698, 36699, 36702
Blame list: 
c...@chromium.org,dpra...@chromium.org,fin...@chromium.org,kka...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Chromium-dev switched to @chromium.org

2010-01-20 Thread John Abd-El-Malek 
Hello,

The chromium-dev mailing list has now been switched to
chromium-...@chromium.org.  Please update your filters and address book
accordingly.

Existing members have been subscribed, with the exception of users who don't
permit managers to add them to a group.  You can visit the new group at
http://groups.google.com/a/chromium.org/group/chromium-dev.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36724

2010-01-20 Thread buildbot 
Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2488

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29

--=>  Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"  
<=--

Revision: 36663, 36664, 3, 36667, 36668, 36669, 36670, 36671, 36675, 36676, 
36677, 36679, 36681, 36682, 36683, 36684, 36686, 36687, 36688, 36689, 36691, 
36692, 36693, 36695, 36696, 36697, 36698, 36699, 36702, 36703, 36704, 36706, 
36707, 36708, 36709, 36710, 36711, 36715, 36716, 36718, 36719, 36720, 36721, 
36722, 36723, 36724
Blame list: 
a...@chromium.org,apatr...@chromium.org,c...@chromium.org,cmas...@google.com,c...@chromium.org,dpra...@chromium.org,est...@chromium.org,e...@chromium.org,fin...@chromium.org,hc...@chromium.org,jcam...@chromium.org,jhawk...@chromium.org,kka...@chromium.org,kuch...@chromium.org,micha...@chromium.org,mpcompl...@chromium.org,osh...@chromium.org,pinker...@chromium.org,s...@chromium.org,tha...@chromium.org,xiy...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Re: Moving mailing lists from @googlegroups.com to @chromium.org

2010-01-20 Thread John Abd-El-Malek 
Note: I've converted chromium-bugs, chromium-checkins, chromium-dev, and
chomium-os-checkins.  I'll convert the rest tomorrow.

It seems that there are some issues with groups and I've emailed the team
before I convert any more lists.  People who were not receiving email before
might start receiving them.  Everyone on chromium-dev also is marked for
moderation without a reason.  Trying to fix both of these issues.

On Wed, Jan 20, 2010 at 1:14 PM, John Abd-El-Malek  wrote:

> Just to explain to everyone the steps that I will follow.  For each mailing
> list, I will:
>
> 1) create a corresponding list on chromium.org with the same members
> 2) subscribe the old list to the new list so that the archives can be
> searched in one place
> 4) disable posting to the old list (only group managers can post)
> 3) send an email to the old list telling everyone that it's now disabled
> and that they must now post to the new list
>
>
> On Wed, Jan 20, 2010 at 11:08 AM, John Abd-El-Malek wrote:
>
>> This is a heads up that as part of moving all of our resources to
>> chromium.org (and vanity!), I'll be switching our mailing lists to be
>> under chromium.org today.  I will send an email when it's done, but for
>> now you may want to update your rules to be either googlegroups.com or
>> chromium.org so that no emails are mislabelled.
>>
>> Note that unfortunately there's no way to migrate the old messages.  So I
>> will subscribe the googlegroups.com lists to the chromium.org ones so
>> that googlegroups has all the emails.
>>
>> Please bear with me through the move.
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] can't download chrome installer when behind a squid proxy

2010-01-20 Thread Paweł Hajdan , Jr . 
On Wed, Jan 20, 2010 at 22:38, Eric Roman  wrote:
> Omaha doesn't support manual authentication for proxies, so if your
> squid proxy is requiring a username/password that could be the
> problem.

Yes, I know about this problem (it's documented in the help message
linked when the installer finishes unsuccessfully). However, the proxy
is transparent... maybe that's causing some problems?

> A good way to debug is to capture the traffic with wireshark and see
> what requests the installer issued.

The problematic one is
http://cache.pack.google.com/edgedl/chrome/install/195.38/chrome_installer.exe

Squid tells me in the logs that the request was successful, not
cached, direct. But the Windows machine I tried this on does not
receive the file.

There are some previous requests that look like trying to get the most
recent version number. It looks like they finish successfully.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Webkit, revision 36741

2010-01-20 Thread buildbot 
Automatically closing tree for "update" on "Webkit"

http://build.chromium.org/buildbot/waterfall/builders/Webkit/builds/17270

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit

--=>  Automatically closing tree for "update" on "Webkit"  <=--

Revision: 36741
Blame list: dpra...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev