Upgrade to libxml 2.9.2 and libxslt 1.1.28

Upgrade to libxml 2.9.2 and libxslt 1.1.28

The previous version of libxml was released in 2008, so this is a large
jump.

One notable functionality change is that the parser no longer accepts

  <stuff xmlns:stream="a"xmlns="b">

(with no space between the end quote of "a" and the xmlns= attribute).

This seems correct to not accept, but could potentially cause some minor
compatibility differences. This is the change in
xmpp_login_handler_unittest.js.

A second difference is that the column number reported in error
conditions has changed in some cases. This causes some expected-error
LayoutTests to differ in textual output. These seem reasonable and
should hopefully not cause any major compatibility issues.

Blink suppressions at https://codereview.chromium.org/1181403003/ which
need to land first.

BUG=463958, 502468
Committed: https://crrev.com/8285ba172641308c6d4775cc38d637ceacb0422a
Cr-Commit-Position: refs/heads/master@{#335721}

[scottmg, 2015-06-18 03:35:46]

scottmg@chromium.org changed reviewers:
+ kelvinp@chromium.org, thestig@chromium.org

[scottmg, 2015-06-18 03:36:59]

scottmg@chromium.org changed reviewers:
+ dpranke@chromium.org

[scottmg, 2015-06-18 03:49:55]

dpranke: content/test/test_expectations.txt
kelvinp: remoting/webapp/base/js/xmpp_login_handler_unittest.js
thestig: general rough sanity check on the import

[Dirk Pranke, 2015-06-18 04:25:02]

//content/test change lgtm. 

The Blink side change does *not* need to land first; however, if you land the
Blink side change first, you don't need to change the //content/test file at
all.

[kelvinp, 2015-06-18 04:27:46]

kelvinp@chromium.org changed reviewers:
+ sergeyu@chromium.org

[kelvinp, 2015-06-18 04:27:49]

I don't think the change will break our unittest.
Sergeyu, do you think new change will cause breakage for our existing iqs that
we are sending?

[Dirk Pranke, 2015-06-18 15:39:25]

https://codereview.chromium.org/1193533007/diff/50001/content/test/test_expec...
File content/test/test_expectations.txt (right):

https://codereview.chromium.org/1193533007/diff/50001/content/test/test_expec...
content/test/test_expectations.txt:36: crbug.com/501659
fast/parser/xml-colon-entity.html [ Failure ]
Turns out you need to put these entries in //skia/skia_test_expectations.txt.

I was wrong in my note to Avi; this file is *only* used on the downstream (aka
"deps") bots
and entries here have no effect on the Blink waterfall; if you read the comments
above,
it's actually fairly clear about this, though the comment in step 1) is wrong,
the *_layout trybots
will not read this file.

[scottmg, 2015-06-18 17:26:02]

On 2015/06/18 04:25:02, Dirk Pranke wrote:
> //content/test change lgtm. 
> 
> The Blink side change does *not* need to land first; however, if you land the
> Blink side change first, you don't need to change the //content/test file at
> all.

OK, I sent the Blink one off, so I'll remove this change here. Thanks.

[Dirk Pranke, 2015-06-18 17:28:08]

On 2015/06/18 17:26:02, scottmg wrote:
> On 2015/06/18 04:25:02, Dirk Pranke wrote:
> > //content/test change lgtm. 
> > 
> > The Blink side change does *not* need to land first; however, if you land
the
> > Blink side change first, you don't need to change the //content/test file at
> > all.
> 
> OK, I sent the Blink one off, so I'll remove this change here. Thanks.

Actually, my earlier comment was wrong; you do need the //content/test change if

you want to worry about the (deps) bots being green until your blink-side change
rolls in.

Personally, I wouldn't worry about them, though, unless somebody complained to
me. I don't think most gardeners ever look at them.

[scottmg, 2015-06-18 17:30:54]

On 2015/06/18 04:27:49, kelvinp wrote:
> I don't think the change will break our unittest.
> Sergeyu, do you think new change will cause breakage for our existing iqs that
> we are sending?

FWIW, the space was lost at https://codereview.chromium.org/534853002 which
doesn't look like it was intentional.

[scottmg, 2015-06-18 17:33:40]

On 2015/06/18 17:28:08, Dirk Pranke wrote:
> On 2015/06/18 17:26:02, scottmg wrote:
> > On 2015/06/18 04:25:02, Dirk Pranke wrote:
> > > //content/test change lgtm. 
> > > 
> > > The Blink side change does *not* need to land first; however, if you land
> the
> > > Blink side change first, you don't need to change the //content/test file
at
> > > all.
> > 
> > OK, I sent the Blink one off, so I'll remove this change here. Thanks.
> 
> Actually, my earlier comment was wrong; you do need the //content/test change
if
> 
> you want to worry about the (deps) bots being green until your blink-side
change
> rolls in.
> 
> Personally, I wouldn't worry about them, though, unless somebody complained to
> me. I don't think most gardeners ever look at them.

Now I'm confused. :) I've CQ'd the blink side suppressions. I can wait until
that rolls to land this.

So should I put suppressions in //content/test/test_expectations.txt? Or
//skia/skia_test_expectations? Or both? Or neither?

[Dirk Pranke, 2015-06-18 18:55:42]

On 2015/06/18 17:33:40, scottmg wrote:
> On 2015/06/18 17:28:08, Dirk Pranke wrote:
> > On 2015/06/18 17:26:02, scottmg wrote:
> > > On 2015/06/18 04:25:02, Dirk Pranke wrote:
> > > > //content/test change lgtm. 
> > > > 
> > > > The Blink side change does *not* need to land first; however, if you
land
> > the
> > > > Blink side change first, you don't need to change the //content/test
file
> at
> > > > all.
> > > 
> > > OK, I sent the Blink one off, so I'll remove this change here. Thanks.
> > 
> > Actually, my earlier comment was wrong; you do need the //content/test
change
> if
> > 
> > you want to worry about the (deps) bots being green until your blink-side
> change
> > rolls in.
> > 
> > Personally, I wouldn't worry about them, though, unless somebody complained
to
> > me. I don't think most gardeners ever look at them.
> 
> Now I'm confused. :)

That's understandable :).

> I've CQ'd the blink side suppressions. I can wait until
> that rolls to land this.
> 
> So should I put suppressions in //content/test/test_expectations.txt? Or
> //skia/skia_test_expectations? Or both? Or neither?

If the Blink CL lands first, you have one of two choices:

1) don't change either the //content or the //skia files. The (deps) bots on 
the chromium.webkit waterfall will be red from the time your chrome-side
change lands until the time your blink-side change rolls into Chrome.

2) change the //content file as part of your chrome-side change. All bots
will stay green. Once your blink-side change rolls into Chrome, you can then
delete the lines from //content.

You do not need to change the skia file if the blink change lands first.

[scottmg, 2015-06-18 19:57:15]

On 2015/06/18 18:55:42, Dirk Pranke wrote:
> On 2015/06/18 17:33:40, scottmg wrote:
> > On 2015/06/18 17:28:08, Dirk Pranke wrote:
> > > On 2015/06/18 17:26:02, scottmg wrote:
> > > > On 2015/06/18 04:25:02, Dirk Pranke wrote:
> > > > > //content/test change lgtm. 
> > > > > 
> > > > > The Blink side change does *not* need to land first; however, if you
> land
> > > the
> > > > > Blink side change first, you don't need to change the //content/test
> file
> > at
> > > > > all.
> > > > 
> > > > OK, I sent the Blink one off, so I'll remove this change here. Thanks.
> > > 
> > > Actually, my earlier comment was wrong; you do need the //content/test
> change
> > if
> > > 
> > > you want to worry about the (deps) bots being green until your blink-side
> > change
> > > rolls in.
> > > 
> > > Personally, I wouldn't worry about them, though, unless somebody
complained
> to
> > > me. I don't think most gardeners ever look at them.
> > 
> > Now I'm confused. :)
> 
> That's understandable :).
> 
> > I've CQ'd the blink side suppressions. I can wait until
> > that rolls to land this.
> > 
> > So should I put suppressions in //content/test/test_expectations.txt? Or
> > //skia/skia_test_expectations? Or both? Or neither?
> 
> If the Blink CL lands first, you have one of two choices:
> 
> 1) don't change either the //content or the //skia files. The (deps) bots on 
> the chromium.webkit waterfall will be red from the time your chrome-side
> change lands until the time your blink-side change rolls into Chrome.
> 
> 2) change the //content file as part of your chrome-side change. All bots
> will stay green. Once your blink-side change rolls into Chrome, you can then
> delete the lines from //content.
> 
> You do not need to change the skia file if the blink change lands first.

Got it. They're landed in blink now, so removed here, thanks.

[scottmg, 2015-06-18 21:03:52]

The CQ bit was checked by scottmg@chromium.org to run a CQ dry run

[scottmg, 2015-06-18 21:03:54]

The patchset sent to the CQ was uploaded after l-g-t-m from dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/1193533007/#ps60001
(title: "remove suppressions, have landed in blink now")

[commit-bot: I haz the power, 2015-06-18 21:05:24]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/60001

[Lei Zhang, 2015-06-18 23:04:23]

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
File third_party/libxml/README.chromium (left):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:15: Modifications:
Have you gone through to see if any of this is still relevant?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
File third_party/libxml/README.chromium (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:3: Version:
b02a167af3d2a47c155bce123820cbb5fa19dc9c
Same comment as libxml. Can we pull a release instead of a git commit?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
File third_party/libxslt/README.chromium (left):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:54: To import a new snapshot of libxslt:
This section is no longer relevant?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
File third_party/libxslt/README.chromium (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:3: Version:
d20a5ab03c195870e3d27b14965d1ed6f3ae0aed
Can we use a release from ftp://xmlsoft.org/libxslt/ rather than libxslt ToT, or
do we need ToT?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:15: - Delete tests/, doc/.
How about third_party/libxslt/python ? Ditto for libxml.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/lib...
File third_party/libxslt/libxslt.gyp (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/lib...
third_party/libxslt/libxslt.gyp:109: 'msvs_disabled_warnings': [
Do you need this in BUILD.gn as well?

[commit-bot: I haz the power, 2015-06-18 23:23:02]

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

[commit-bot: I haz the power, 2015-06-18 23:23:04]

Dry run: This issue passed the CQ dry run.

[scottmg, 2015-06-19 18:24:08]

Patchset #8 (id:70001) has been deleted

[scottmg, 2015-06-19 18:35:54]

scottmg@chromium.org changed reviewers:
+ cevans@chromium.org, jschuh@chromium.org

[scottmg, 2015-06-19 18:35:59]

Thanks!

I switched to libxml2.9.2 and libxslt1.1.28. But I think now looking at the age
of that version of libxslt and the fixes since then
https://git.gnome.org/browse/libxslt/log/ I'm going to switch back to HEAD on
that one. Any objections? I guess I'll tryjob this at least to see if it works
at numbered versions.

+cevans/jschuh for a couple questions on ancient patches

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
File third_party/libxml/README.chromium (left):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:15: Modifications:
On 2015/06/18 23:04:23, Lei Zhang wrote:
> Have you gone through to see if any of this is still relevant?

I didn't go through any of the ones that had associated upstream changes on the
assumption that they'll be rolled in. Others inline.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:29: - Add helper classes in
chromium/libxml_utils.cc and chromium/include/libxml/libxml_utils.h.
These were kept unmodified, readded a note.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:30: - Add a tweak to limit problems caused by
excessive strings and buffers.
+cevans,+jschuh, this was https://chromiumcodereview.appspot.com/10458051 . Is
something like that still necessary? It seems like the renderer limit should
cover this, but do we need lower limits here for some reason?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:32: if treated as a generic xmlNode object.
+cevans again: I don't understand what this one was for. It's:
https://chromiumcodereview.appspot.com/10824157 Probably unnecessary now?

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:33: - Fix pretty harmless use-after-free in
generate-id function.
This looks like it's been subsumed or reimplemented upstream. (it's actually
part of libxslt, not libxml)

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:39: - Prevent snprintf from being defined as
_snprintf on VS 2015.
These three were me, and I believe they're unnecessary after the merge. I will
update later if not, as none were urgent.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:50: - Apply the patches in patches/ and fix
any problems.
This didn't end up being done reliably, so I don't want to encourage this.

Now that I've added myself to owners here I will be requiring the patches to be
upstream (at least posted somewhere if not merged) so we don't have this mess of
.patches to deal with.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:52: - On a Linux system,
I restored/fixed/updated this.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
File third_party/libxml/README.chromium (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxml/READ...
third_party/libxml/README.chromium:3: Version:
b02a167af3d2a47c155bce123820cbb5fa19dc9c
On 2015/06/18 23:04:22, Lei Zhang wrote:
> Same comment as libxml. Can we pull a release instead of a git commit?

I didn't see much upside as the release process seemed pretty cursory, and it's
already 8 months old. But doesn't matter much I guess, switched to 2.9.2.
Unfortunately it doesn't work on Windows, so had to add a patch from upstream to
get configure to run.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
File third_party/libxslt/README.chromium (left):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:54: To import a new snapshot of libxslt:
On 2015/06/18 23:04:22, Lei Zhang wrote:
> This section is no longer relevant?

Done.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
File third_party/libxslt/README.chromium (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:3: Version:
d20a5ab03c195870e3d27b14965d1ed6f3ae0aed
On 2015/06/18 23:04:22, Lei Zhang wrote:
> Can we use a release from ftp://xmlsoft.org/libxslt/ rather than libxslt ToT,
or
> do we need ToT?

Done.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:15: - Delete tests/, doc/.
On 2015/06/18 23:04:22, Lei Zhang wrote:
> How about third_party/libxslt/python ? Ditto for libxml.

Done.

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/lib...
File third_party/libxslt/libxslt.gyp (right):

https://codereview.chromium.org/1193533007/diff/60001/third_party/libxslt/lib...
third_party/libxslt/libxslt.gyp:109: 'msvs_disabled_warnings': [
On 2015/06/18 23:04:23, Lei Zhang wrote:
> Do you need this in BUILD.gn as well?

Done.

[scottmg, 2015-06-19 18:44:11]

On 2015/06/19 18:35:59, scottmg wrote:
> Thanks!
> 
> I switched to libxml2.9.2 and libxslt1.1.28. But I think now looking at the
age
> of that version of libxslt and the fixes since then
> https://git.gnome.org/browse/libxslt/log/ I'm going to switch back to HEAD on
> that one. Any objections? I guess I'll tryjob this at least to see if it works
> at numbered versions.

OTOH, all our security patches appear to be upstream in 1.1.28, so maybe I'll
just leave it alone there if things work.

[scottmg, 2015-06-19 18:46:07]

https://codereview.chromium.org/1193533007/diff/80001/third_party/libxslt/REA...
File third_party/libxslt/README.chromium (left):

https://codereview.chromium.org/1193533007/diff/80001/third_party/libxslt/REA...
third_party/libxslt/README.chromium:51: 6) A change to pattern.c to better
handle an error condition parsing a broken
+cevans again this is https://chromiumcodereview.appspot.com/10830177. 

This is the only one not upstream. The surrounding code has changed a bit, but
the early return doesn't appear to be there. Should this change be
upstreamed/reapplied?

[Lei Zhang, 2015-06-19 19:22:49]

On 2015/06/19 18:44:11, scottmg wrote:
> On 2015/06/19 18:35:59, scottmg wrote:
> > Thanks!
> > 
> > I switched to libxml2.9.2 and libxslt1.1.28. But I think now looking at the
> age
> > of that version of libxslt and the fixes since then
> > https://git.gnome.org/browse/libxslt/log/ I'm going to switch back to HEAD
on
> > that one. Any objections? I guess I'll tryjob this at least to see if it
works
> > at numbered versions.
> 
> OTOH, all our security patches appear to be upstream in 1.1.28, so maybe I'll
> just leave it alone there if things work.

On release version vs. ToT. It's sort of like running Chrome stable vs Canary.
Do you really need ToT, or can you live with the last release and be in the same
boat as Linux distros? Your call.

Ubuntu is still shipping 1.1.28 with some patches. The one patch that seems
relevant is
https://git.gnome.org/browse/libxslt/commit/?id=ae49d7a73b043bccb7631e7d9577b...

Really, libxslt needs to make another release, as 1.1.28 is 2.5 years old.

[scottmg, 2015-06-19 19:40:38]

On 2015/06/19 19:22:49, Lei Zhang wrote:
> On 2015/06/19 18:44:11, scottmg wrote:
> > On 2015/06/19 18:35:59, scottmg wrote:
> > > Thanks!
> > > 
> > > I switched to libxml2.9.2 and libxslt1.1.28. But I think now looking at
the
> > age
> > > of that version of libxslt and the fixes since then
> > > https://git.gnome.org/browse/libxslt/log/ I'm going to switch back to HEAD
> on
> > > that one. Any objections? I guess I'll tryjob this at least to see if it
> works
> > > at numbered versions.
> > 
> > OTOH, all our security patches appear to be upstream in 1.1.28, so maybe
I'll
> > just leave it alone there if things work.
> 
> On release version vs. ToT. It's sort of like running Chrome stable vs Canary.
> Do you really need ToT, or can you live with the last release and be in the
same
> boat as Linux distros? Your call.

Yup, I just don't see any visible stabilization process, so release and ToT seem
basically equivalent to me, other than presumably most changes were made for a
reason so maybe ToT is better.

Anyway, I'm going to stick with released versions to get things
much-closer-to-tot, and then we can either move closer or pull in important
changes, hopefully fairly easily.

> 
> Ubuntu is still shipping 1.1.28 with some patches. The one patch that seems
> relevant is
>
https://git.gnome.org/browse/libxslt/commit/?id=ae49d7a73b043bccb7631e7d9577b...

That seems plausible. I don't see any others in
http://launchpadlibrarian.net/146921936/libxslt_1.1.28-1ubuntu1_1.1.28-2.diff.gz
that seem important. I'm not going to patch that one in since I don't really
understand it and the version we're shipping with right now has that function
being registered.

> 
> Really, libxslt needs to make another release, as 1.1.28 is 2.5 years old.

[Lei Zhang, 2015-06-19 22:27:32]

On 2015/06/19 19:40:38, scottmg wrote:
> Yup, I just don't see any visible stabilization process, so release and ToT
seem
> basically equivalent to me, other than presumably most changes were made for a
> reason so maybe ToT is better.
> 
> Anyway, I'm going to stick with released versions to get things
> much-closer-to-tot, and then we can either move closer or pull in important
> changes, hopefully fairly easily.

SGTM, but I'm not an owner here. So I'm just going to cross my fingers and hope
this lands safely.

[scottmg, 2015-06-19 22:33:59]

On 2015/06/19 22:27:32, Lei Zhang wrote:
> On 2015/06/19 19:40:38, scottmg wrote:
> > Yup, I just don't see any visible stabilization process, so release and ToT
> seem
> > basically equivalent to me, other than presumably most changes were made for
a
> > reason so maybe ToT is better.
> > 
> > Anyway, I'm going to stick with released versions to get things
> > much-closer-to-tot, and then we can either move closer or pull in important
> > changes, hopefully fairly easily.
> 
> SGTM, but I'm not an owner here. So I'm just going to cross my fingers and
hope
> this lands safely.

OK, thanks for scrutinizing anyway. I'm sheriffing today, so I might as well
"land and iterate" today.

[scottmg, 2015-06-19 23:07:40]

The CQ bit was checked by scottmg@chromium.org

[scottmg, 2015-06-19 23:07:42]

The patchset sent to the CQ was uploaded after l-g-t-m from dpranke@chromium.org
Link to the patchset: https://codereview.chromium.org/1193533007/#ps100001
(title: "GetFileAttributesA")

[commit-bot: I haz the power, 2015-06-19 23:08:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/100001

[scottmg, 2015-06-19 23:17:13]

sergeyu or kelvinp: could you stamp the space addition in
remoting/webapp/base/js/xmpp_login_handler_unittest.js? thanks.

[commit-bot: I haz the power, 2015-06-19 23:23:16]

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

[commit-bot: I haz the power, 2015-06-19 23:23:19]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Sergey Ulanov, 2015-06-19 23:42:11]

lgtm

[scottmg, 2015-06-19 23:48:44]

Oh bother. It looks like we do need some more recent patches for these
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/6....

git mv third_party/libxml third_party/libfml

I guess I'll try to figure out if it's only a patch-or-two, or whether we're
just better to pull to ToT for both.

[scottmg, 2015-06-22 23:29:55]

OK, it looks like I just misconfigured (no ICU) for those failures, so I've
updated the config/instructions and am going to try again to land. But sticking
with (mostly) stock latest release of the two libraries for now.

[scottmg, 2015-06-22 23:30:18]

The CQ bit was checked by scottmg@chromium.org

[scottmg, 2015-06-22 23:30:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
dpranke@chromium.org, sergeyu@chromium.org
Link to the patchset: https://codereview.chromium.org/1193533007/#ps120001
(title: "no iconv")

[commit-bot: I haz the power, 2015-06-22 23:30:46]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/120001

[commit-bot: I haz the power, 2015-06-22 23:54:25]

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

[commit-bot: I haz the power, 2015-06-22 23:54:28]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[scottmg, 2015-06-23 01:46:08]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-06-23 01:46:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/120001

[commit-bot: I haz the power, 2015-06-23 02:14:52]

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

[commit-bot: I haz the power, 2015-06-23 02:14:55]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[scottmg, 2015-06-23 03:57:01]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-06-23 03:57:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/120001

[commit-bot: I haz the power, 2015-06-23 04:17:48]

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

[commit-bot: I haz the power, 2015-06-23 04:17:51]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[scottmg, 2015-06-23 16:11:03]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-06-23 16:13:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/120001

[commit-bot: I haz the power, 2015-06-23 16:45:07]

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

[commit-bot: I haz the power, 2015-06-23 16:45:11]

Try jobs failed on following builders:
  chromeos_daisy_chromium_compile_only_ng on tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[scottmg, 2015-06-23 18:18:56]

The CQ bit was checked by scottmg@chromium.org

[commit-bot: I haz the power, 2015-06-23 18:21:39]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1193533007/120001

[commit-bot: I haz the power, 2015-06-23 19:00:20]

Committed patchset #12 (id:120001)

[commit-bot: I haz the power, 2015-06-23 19:01:19]

Patchset 12 (id:??) landed as
https://crrev.com/8285ba172641308c6d4775cc38d637ceacb0422a
Cr-Commit-Position: refs/heads/master@{#335721}