Use the system provided harfbuzz on chromeos

Use the system provided harfbuzz on chromeos

It's part of the pango library we use already, so by using it, we avoid
a link time collission.

However, if you build just the browser on linux on ubuntu 12, we don't
have such an up to date pango available, so we need to be a bit smart
about whether or not to use the system harfbuzz.

This also allows for treating linker warnings as errors on chromeos

BUG=353127
R=jshin@chromium.org, thakis@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=259423

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=259530

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=259652

[Nico, 2014-03-18 15:12:12]

I don't understand the gyp bits. Shouldn't you get most of that from
build/common.gypi already?

https://codereview.chromium.org/203163003/diff/1/build/common.gypi
File build/common.gypi (left):

https://codereview.chromium.org/203163003/diff/1/build/common.gypi#oldcode2983
build/common.gypi:2983: ['os_posix==1 and chromeos==0', {
Mention that you're also turning on linker-warnings-as-errors in the cl
description.

https://codereview.chromium.org/203163003/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/203163003/diff/1/build/common.gypi#newcode744
build/common.gypi:744: # On ChromeOS, we use the system libharfbuzz-ng.
Probably better to answer "why?" than "what?" here

https://codereview.chromium.org/203163003/diff/1/build/linux/check_return_value
File build/linux/check_return_value (right):

https://codereview.chromium.org/203163003/diff/1/build/linux/check_return_val...
build/linux/check_return_value:9: if "$@"; then
Why not just

"$@"
echo $?

? Or

import subprocess
import sys
print subprocess.call(sys.argv[1:])

then it runs on windows too and can be in just build/

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
third_party/harfbuzz-ng/harfbuzz.gyp:13: 'sysroot%': '',
(Reading the variables upside-down)

…Oh, you're setting this to empty here? Huh?

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
third_party/harfbuzz-ng/harfbuzz.gyp:18: 'target_arch%': '<(target_arch)',
Don't you get this from common.gypi already?

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
third_party/harfbuzz-ng/harfbuzz.gyp:25: }],
Hm, looks like this block is in every file using pkg-config :-/ should probably
be shared somehow

[jochen (gone - plz use gerrit), 2014-03-18 15:39:37]

ptal

https://codereview.chromium.org/203163003/diff/1/build/common.gypi
File build/common.gypi (left):

https://codereview.chromium.org/203163003/diff/1/build/common.gypi#oldcode2983
build/common.gypi:2983: ['os_posix==1 and chromeos==0', {
On 2014/03/18 15:12:13, Nico (on GMT time Mar 15 - 24) wrote:
> Mention that you're also turning on linker-warnings-as-errors in the cl
> description.

Done.

https://codereview.chromium.org/203163003/diff/1/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/203163003/diff/1/build/common.gypi#newcode744
build/common.gypi:744: # On ChromeOS, we use the system libharfbuzz-ng.
On 2014/03/18 15:12:13, Nico (on GMT time Mar 15 - 24) wrote:
> Probably better to answer "why?" than "what?" here

Done.

https://codereview.chromium.org/203163003/diff/1/build/linux/check_return_value
File build/linux/check_return_value (right):

https://codereview.chromium.org/203163003/diff/1/build/linux/check_return_val...
build/linux/check_return_value:9: if "$@"; then
On 2014/03/18 15:12:13, Nico (on GMT time Mar 15 - 24) wrote:
> Why not just
> 
> "$@"
> echo $?
> 
> ? Or
> 
> import subprocess
> import sys
> print subprocess.call(sys.argv[1:])
> 
> then it runs on windows too and can be in just build/

Converted to python. I left the magic in to translate shell success to 1

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
third_party/harfbuzz-ng/harfbuzz.gyp:13: 'sysroot%': '',
On 2014/03/18 15:12:13, Nico (on GMT time Mar 15 - 24) wrote:
> (Reading the variables upside-down)
> 
> …Oh, you're setting this to empty here? Huh?

as discussed, i need to nest sysroot one level deeper in common.gypi

https://codereview.chromium.org/203163003/diff/1/third_party/harfbuzz-ng/harf...
third_party/harfbuzz-ng/harfbuzz.gyp:25: }],
On 2014/03/18 15:12:13, Nico (on GMT time Mar 15 - 24) wrote:
> Hm, looks like this block is in every file using pkg-config :-/ should
probably
> be shared somehow

yes, but that looks like a separate project.

there's also a bunch of gyp files that define the variable pkg-config but invoke
pkg-config directly...

[Nico, 2014-03-18 15:48:55]

lgtm since android doesn't have pkg-config anyway

(I'm sure we have the problem I'm hinting at below in many places :-( )

https://codereview.chromium.org/203163003/diff/40001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/203163003/diff/40001/build/common.gypi#newcod...
build/common.gypi:234: }],
Does this block need to move one level deeper too? Else the target_arch in
harfbuzz might be different than the one here…

[jochen (gone - plz use gerrit), 2014-03-18 18:07:01]

I think I'll update the patch to be a bit more magic and automatically decide
what library to use

[jungshik at Google, 2014-03-18 19:05:29]

Thanks for the CL. 

This one has to wait until harfbuzz on Chrome OS is updated to a recent one. I
marked as such in the bug.

https://codereview.chromium.org/203163003/diff/60001/third_party/harfbuzz-ng/...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/60001/third_party/harfbuzz-ng/...
third_party/harfbuzz-ng/harfbuzz.gyp:155: # Check for presence of harfbuzz-icu
library, use it if present.
On Chrome OS, the current plan is NOT to use harfbuzz-icu because we don't use
'system icu' on Chrome OS.

[jochen (gone - plz use gerrit), 2014-03-18 19:22:07]

On 2014/03/18 19:05:29, Jungshik Shin wrote:
> Thanks for the CL. 
> 
> This one has to wait until harfbuzz on Chrome OS is updated to a recent one. I
> marked as such in the bug.
> 
>
https://codereview.chromium.org/203163003/diff/60001/third_party/harfbuzz-ng/...
> File third_party/harfbuzz-ng/harfbuzz.gyp (right):
> 
>
https://codereview.chromium.org/203163003/diff/60001/third_party/harfbuzz-ng/...
> third_party/harfbuzz-ng/harfbuzz.gyp:155: # Check for presence of harfbuzz-icu
> library, use it if present.
> On Chrome OS, the current plan is NOT to use harfbuzz-icu because we don't use
> 'system icu' on Chrome OS.

done

[Inactive, 2014-03-18 20:28:42]

FYI, I get the following linking errors with this patch on my Ubuntu 13.10
Desktop:
http://pastebin.com/3p959Ees

[jungshik at Google, 2014-03-18 20:32:09]

On 2014/03/18 20:28:42, Chris Dumez wrote:
> FYI, I get the following linking errors with this patch on my Ubuntu 13.10
> Desktop:
> http://pastebin.com/3p959Ees

Does the patch set 4 work?

[davve, 2014-03-19 08:26:22]

On 2014/03/18 20:32:09, Jungshik Shin wrote:
> On 2014/03/18 20:28:42, Chris Dumez wrote:
> > FYI, I get the following linking errors with this patch on my Ubuntu 13.10
> > Desktop:
> > http://pastebin.com/3p959Ees
> 
> Does the patch set 4 work?

I got the exact same errors as Chris with tip of patch (but on Debian) and patch
set 4 solved it.

[Nico, 2014-03-19 09:52:52]

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
Oh hmm, does that mean we have to bundle pangoft2? We probably don't want to use
system harfbuzz in shipping chrome for security reasons etc.

[jochen (gone - plz use gerrit), 2014-03-19 10:36:52]

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> Oh hmm, does that mean we have to bundle pangoft2? We probably don't want to
use
> system harfbuzz in shipping chrome for security reasons etc.

We can add a check that for buildtype=Official and chromeos==0, we don't use
system harfbuzz

[Nico, 2014-03-19 10:39:29]

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
On 2014/03/19 10:36:53, jochen wrote:
> On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> > Oh hmm, does that mean we have to bundle pangoft2? We probably don't want to
> use
> > system harfbuzz in shipping chrome for security reasons etc.
> 
> We can add a check that for buildtype=Official and chromeos==0, we don't use
> system harfbuzz

But then the official builder still gets the warning, no? And is subtly
different from a developer build. And it still uses system harfbuzz via pangoft,
hence me asking if we need to bundle that ourselves, linked against our
harfbuzz. (Probably best to ask whoever security person did the harfbuzz
review.)

[jochen (gone - plz use gerrit), 2014-03-19 10:42:28]

On 2014/03/19 10:39:29, Nico (on GMT time Mar 15 - 24) wrote:
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> File third_party/harfbuzz-ng/harfbuzz.gyp (right):
> 
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
> On 2014/03/19 10:36:53, jochen wrote:
> > On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> > > Oh hmm, does that mean we have to bundle pangoft2? We probably don't want
to
> > use
> > > system harfbuzz in shipping chrome for security reasons etc.
> > 
> > We can add a check that for buildtype=Official and chromeos==0, we don't use
> > system harfbuzz
> 
> But then the official builder still gets the warning, no? And is subtly

I'd make it just fail instead of silently ignoring it.

Official builders run ubuntu 12, so they don't use system harfbuzz with this
patch.

> different from a developer build. And it still uses system harfbuzz via
pangoft,
> hence me asking if we need to bundle that ourselves, linked against our
> harfbuzz. (Probably best to ask whoever security person did the harfbuzz
> review.)

[Nico, 2014-03-19 10:51:07]

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
On 2014/03/19 10:39:30, Nico (on GMT time Mar 15 - 24) wrote:
> On 2014/03/19 10:36:53, jochen wrote:
> > On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> > > Oh hmm, does that mean we have to bundle pangoft2? We probably don't want
to
> > use
> > > system harfbuzz in shipping chrome for security reasons etc.
> > 
> > We can add a check that for buildtype=Official and chromeos==0, we don't use
> > system harfbuzz
> 
> But then the official builder still gets the warning, no? And is subtly
> different from a developer build. And it still uses system harfbuzz via
pangoft,
> hence me asking if we need to bundle that ourselves, linked against our
> harfbuzz. (Probably best to ask whoever security person did the harfbuzz
> review.)

Ah, right. So we might need to bundle pangoft when we upgrade the builder
version, and we'll get a compile error if we don't do that. (If I got this
right, maybe file a bug on someone harfbuzzy to do this work at some point in
the next 1-2 years.)

[jochen (gone - plz use gerrit), 2014-03-19 14:47:40]

On 2014/03/19 10:51:07, Nico (on GMT time Mar 15 - 24) wrote:
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> File third_party/harfbuzz-ng/harfbuzz.gyp (right):
> 
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
> On 2014/03/19 10:39:30, Nico (on GMT time Mar 15 - 24) wrote:
> > On 2014/03/19 10:36:53, jochen wrote:
> > > On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> > > > Oh hmm, does that mean we have to bundle pangoft2? We probably don't
want
> to
> > > use
> > > > system harfbuzz in shipping chrome for security reasons etc.
> > > 
> > > We can add a check that for buildtype=Official and chromeos==0, we don't
use
> > > system harfbuzz
> > 
> > But then the official builder still gets the warning, no? And is subtly
> > different from a developer build. And it still uses system harfbuzz via
> pangoft,
> > hence me asking if we need to bundle that ourselves, linked against our
> > harfbuzz. (Probably best to ask whoever security person did the harfbuzz
> > review.)
> 
> Ah, right. So we might need to bundle pangoft when we upgrade the builder
> version, and we'll get a compile error if we don't do that. (If I got this
> right, maybe file a bug on someone harfbuzzy to do this work at some point in
> the next 1-2 years.)

I guess jshin@ has this all covered :)

updated the patch

[jungshik at Google, 2014-03-20 00:37:36]

On 2014/03/19 14:47:40, jochen wrote:
> On 2014/03/19 10:51:07, Nico (on GMT time Mar 15 - 24) wrote:
> >
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> > File third_party/harfbuzz-ng/harfbuzz.gyp (right):
> > 
> >
>
https://codereview.chromium.org/203163003/diff/90001/third_party/harfbuzz-ng/...
> > third_party/harfbuzz-ng/harfbuzz.gyp:25: # anyways.
> > On 2014/03/19 10:39:30, Nico (on GMT time Mar 15 - 24) wrote:
> > > On 2014/03/19 10:36:53, jochen wrote:
> > > > On 2014/03/19 09:52:52, Nico (on GMT time Mar 15 - 24) wrote:
> > > > > Oh hmm, does that mean we have to bundle pangoft2? We probably don't
> want
> > to
> > > > use
> > > > > system harfbuzz in shipping chrome for security reasons etc.
> > > > 
> > > > We can add a check that for buildtype=Official and chromeos==0, we don't
> use
> > > > system harfbuzz
> > > 
> > > But then the official builder still gets the warning, no? And is subtly
> > > different from a developer build. And it still uses system harfbuzz via
> > pangoft,
> > > hence me asking if we need to bundle that ourselves, linked against our
> > > harfbuzz. (Probably best to ask whoever security person did the harfbuzz
> > > review.)
> > 
> > Ah, right. So we might need to bundle pangoft when we upgrade the builder
> > version, and we'll get a compile error if we don't do that. (If I got this
> > right, maybe file a bug on someone harfbuzzy to do this work at some point
in
> > the next 1-2 years.)
> 
> I guess jshin@ has this all covered :)

After asking David to try patch set 4, I came to realize that as well. For
Chrome on Linux, I've just filed http://crbug.com/354278
Bundling pangoft might be a rather 'big' undertaking (I hope not). If Chrome's
native UI will share the shaping/layout engine with Blink in 1-2 years, we may
not need to do this. 

On ChromeOS, everything should be in order once I upgrade harfbuzz to 0.9.26
(after layout failure is taken care of). 


> 
> updated the patch

[jungshik at Google, 2014-03-20 21:21:43]

LGTM with what's below (pango version).

https://codereview.chromium.org/203163003/diff/130001/third_party/harfbuzz-ng...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/130001/third_party/harfbuzz-ng...
third_party/harfbuzz-ng/harfbuzz.gyp:29: 'use_system_harfbuzz': '<!(python
../../build/check_return_value.py <(pkg-config) --atleast-version=1.32.4
pangoft2)',
According to
http://ftp.gnome.org/pub/GNOME/sources/pango/1.31/pango-1.31.0.news, pango
1.31.0 is the earliest with an external harfbuzz-ng. So, why don't you change
that to 1.31.0?

[jochen (gone - plz use gerrit), 2014-03-21 09:54:51]

https://codereview.chromium.org/203163003/diff/130001/third_party/harfbuzz-ng...
File third_party/harfbuzz-ng/harfbuzz.gyp (right):

https://codereview.chromium.org/203163003/diff/130001/third_party/harfbuzz-ng...
third_party/harfbuzz-ng/harfbuzz.gyp:29: 'use_system_harfbuzz': '<!(python
../../build/check_return_value.py <(pkg-config) --atleast-version=1.32.4
pangoft2)',
On 2014/03/20 21:21:44, Jungshik Shin wrote:
> According to
> http://ftp.gnome.org/pub/GNOME/sources/pango/1.31/pango-1.31.0.news, pango
> 1.31.0 is the earliest with an external harfbuzz-ng. So, why don't you change
> that to 1.31.0? 

Done.

[jochen (gone - plz use gerrit), 2014-03-25 18:39:39]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-25 18:40:13]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/150001

[commit-bot: I haz the power, 2014-03-25 18:40:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 18:40:37]

Failed to apply patch for build/check_return_value.py:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  A         build/check_return_value.py
  Copied tools/telemetry/find_dependencies -> build/check_return_value.py
  patching file build/check_return_value.py
  Hunk #1 FAILED at 3.
  1 out of 1 hunk FAILED -- saving rejects to file
build/check_return_value.py.rej

Patch:   NR  tools/telemetry/find_dependencies->build/check_return_value.py
Index: build/check_return_value.py
diff --git a/tools/telemetry/find_dependencies b/build/check_return_value.py
similarity index 50%
copy from tools/telemetry/find_dependencies
copy to build/check_return_value.py
index
298c93d3f37e6df81c9d358b8a0476488af56534..6f0daec3a751bdf4f043274f1196193929b5dd4b
100755
--- a/tools/telemetry/find_dependencies
+++ b/build/check_return_value.py
@@ -3,8 +3,13 @@
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
-from telemetry.util import find_dependencies
+"""This program wraps an arbitrary command and prints "1" if the command ran
+successfully."""
 
+import subprocess
+import sys
 
-if __name__ == '__main__':
-  find_dependencies.main()
+if not subprocess.call(sys.argv[1:]):
+  print 1
+else:
+  print 0

[jochen (gone - plz use gerrit), 2014-03-25 18:50:56]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-25 18:55:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/210001

[commit-bot: I haz the power, 2014-03-25 19:03:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 19:03:22]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_compile_dbg

[jochen (gone - plz use gerrit), 2014-03-25 20:01:29]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-25 20:02:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/210001

[commit-bot: I haz the power, 2014-03-25 21:37:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-25 21:37:59]

Retried try job too often on win_rel for step(s) net_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[jochen (gone - plz use gerrit), 2014-03-25 21:41:32]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-25 21:42:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/210001

[commit-bot: I haz the power, 2014-03-26 00:47:31]

Change committed as 259423

[erikchen, 2014-03-26 01:37:12]

A revert of this CL has been created in
https://codereview.chromium.org/211473008/ by erikchen@chromium.org.

The reason for reverting is: Revert as speculative cause for build failure.

http://build.chromium.org/p/chromium.chromiumos/builders/ChromiumOS%20%28dais....

[jochen (gone - plz use gerrit), 2014-03-26 08:05:33]

Committed patchset #11 manually as r259530 (presubmit successful).

[jochen (gone - plz use gerrit), 2014-03-26 09:30:30]

A revert of this CL has been created in
https://codereview.chromium.org/212313003/ by jochen@chromium.org.

The reason for reverting is: chromeos doesn't have hb-icu.h.

[jochen (gone - plz use gerrit), 2014-03-26 12:16:43]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-26 12:16:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/550001

[commit-bot: I haz the power, 2014-03-26 12:37:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-26 12:37:38]

Retried try job too often on win_rel for step(s) base_unittests, browser_tests,
interactive_ui_tests, net_unittests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[jochen (gone - plz use gerrit), 2014-03-26 12:41:24]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-26 12:41:33]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/550001

[commit-bot: I haz the power, 2014-03-26 12:51:12]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-26 12:51:13]

Try jobs failed on following builders:
  tryserver.chromium on win_chromium_compile_dbg

[jochen (gone - plz use gerrit), 2014-03-26 15:07:31]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-26 15:07:39]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/790001

[commit-bot: I haz the power, 2014-03-26 15:30:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-26 15:30:39]

Retried try job too often on ios_dbg_simulator for step(s) base_unittests,
compile, components_unittests, content_unittests, crypto_unittests,
net_unittests, sql_unittests, ui_unittests, url_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=ios_dbg_si...

[jochen (gone - plz use gerrit), 2014-03-26 17:11:21]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2014-03-26 17:13:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/203163003/790001

[commit-bot: I haz the power, 2014-03-26 19:10:06]

Change committed as 259652