Move networking_private to src/extensions

Move networking_private to src/extensions

The major re-factoring for this has been done, this is mostly just
moving the files, with a small addition to ExtensionsBrowserClient.

For extensions/browser/api/networking_private/DEPS:
TBR=jamescook@chromium.org
BUG=363776
Committed: https://crrev.com/d194dd136f180afc02c930b7a0fbab406671d89c
Cr-Commit-Position: refs/heads/master@{#313537}

[stevenjb, 2015-01-23 23:09:14]

stevenjb@chromium.org changed reviewers:
+ derat@chromium.org, jamescook@chromium.org, mef@chromium.org,
sheretov@chromium.org, zentaro@chromium.org

[stevenjb, 2015-01-23 23:09:15]

derat@ or jamescook@ - can you take a look at extensions_browser_client.h and
related changes? Then I will ask an extensions@ owner for a rubber stamp.

mef@ ptal the networking_private changes

zentaro@, sheretov@ - FYI

[Daniel Erat, 2015-01-23 23:24:29]

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
is this approach already used for non-chrome-os elsewhere?

https://codereview.chromium.org/870163002/diff/1/extensions/browser/extension...
File extensions/browser/extensions_browser_client.h (right):

https://codereview.chromium.org/870163002/diff/1/extensions/browser/extension...
extensions/browser/extensions_browser_client.h:91: // Returns a consistent
unqiue Id hash for |context|.
nit: s/unqiue/unique/ (super-nit: s/Id/ID/)

[stevenjb, 2015-01-23 23:57:57]

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
On 2015/01/23 23:24:29, Daniel Erat wrote:
> is this approach already used for non-chrome-os elsewhere?

Currently "GetUserIdHash" is a chromeos specific concept. We could wrap the
entire method inside #if defined(OS_CHROMEOS).

However, if you look at ProfileHelper::GetUserIdHashFromProfile(), this is the
"legacy" behavior, and seems sufficient for hypothetical non-chromeos usage.

That said, if making this call chromeos specific seems better, I am OK with
that.

[Daniel Erat, 2015-01-24 02:14:03]

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/1/chrome/browser/extensions/ch...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
On 2015/01/23 23:57:57, stevenjb wrote:
> On 2015/01/23 23:24:29, Daniel Erat wrote:
> > is this approach already used for non-chrome-os elsewhere?
> 
> Currently "GetUserIdHash" is a chromeos specific concept. We could wrap the
> entire method inside #if defined(OS_CHROMEOS).
> 
> However, if you look at ProfileHelper::GetUserIdHashFromProfile(), this is the
> "legacy" behavior, and seems sufficient for hypothetical non-chromeos usage.
> 
> That said, if making this call chromeos specific seems better, I am OK with
> that.

i don't have strong opinions about this / don't know if there will be issues due
to the non-chrome-os implementation. i'm fine with this if james is. :-)

[James Cook, 2015-01-24 03:59:25]

Do you need to move the permissions stuff from
//chrome/common/extensions/api/_api_features.json to
//extensions/common/api/_api_features.json?  Stuff for permissions too?

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
File chrome/browser/extensions/browser_context_keyed_service_factories.cc
(right):

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
chrome/browser/extensions/browser_context_keyed_service_factories.cc:125:
extensions::NetworkingPrivateEventRouterFactory::GetInstance();
This should probably be registered in the //extensions/browser version of
browser_context_keyed_service_factories.cc to make it available in app_shell and
below.

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
I don't like this. Isn't the Chrome OS version depending on the path part
looking something like a hash?  (Doesn't the cryptohome path have something
hash-y in it? u-12345abcdef or similar?)  I think this code means on Windows/Mac
that the UserIdHash will be "Default" or "James", which could leak information
if the calling code expects something obfuscated. I would either NOTREACHED() or
return "" or an error string.

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/exten...
File extensions/browser/extensions_browser_client.h (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/exten...
extensions/browser/extensions_browser_client.h:91: // Returns a consistent
unqiue Id hash for |context|.
nit: unqiue -> unique... and maybe give a bit more detail on what this is. This
returns a stable (cross session) hash of the current user ID for a browser
context?

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/test_...
File extensions/browser/test_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/test_...
extensions/browser/test_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
I would just return the empty string, or maybe a known fixed hash. If tests need
something fancier, they can subclass this class.

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
File extensions/shell/browser/shell_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
extensions/shell/browser/shell_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
app_shell on Brillo doesn't have a real logged-in user, so not really a
cryptohome, so this may not be very hash-y. It might just end up as "user". Is
that OK, or would you prefer returning a known fixed string?

[stevenjb, 2015-01-26 20:36:19]

Thanks, PTAL

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
File chrome/browser/extensions/browser_context_keyed_service_factories.cc
(right):

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
chrome/browser/extensions/browser_context_keyed_service_factories.cc:125:
extensions::NetworkingPrivateEventRouterFactory::GetInstance();
On 2015/01/24 03:59:24, James Cook wrote:
> This should probably be registered in the //extensions/browser version of
> browser_context_keyed_service_factories.cc to make it available in app_shell
and
> below.

Done.

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
On 2015/01/24 03:59:24, James Cook wrote:
> I don't like this. Isn't the Chrome OS version depending on the path part
> looking something like a hash?  (Doesn't the cryptohome path have something
> hash-y in it? u-12345abcdef or similar?)  I think this code means on
Windows/Mac
> that the UserIdHash will be "Default" or "James", which could leak information
> if the calling code expects something obfuscated. I would either NOTREACHED()
or
> return "" or an error string.

I'm going to go ahead and make this method Chrome OS only so that nobody
accidentally uses it on another platform.

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/exten...
File extensions/browser/extensions_browser_client.h (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/exten...
extensions/browser/extensions_browser_client.h:91: // Returns a consistent
unqiue Id hash for |context|.
On 2015/01/24 03:59:24, James Cook wrote:
> nit: unqiue -> unique... and maybe give a bit more detail on what this is.
This
> returns a stable (cross session) hash of the current user ID for a browser
> context?

I copied and rephrased the comment from profile_helper.h, which may not be much
more clear but it's at least consistent.

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/test_...
File extensions/browser/test_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/browser/test_...
extensions/browser/test_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
On 2015/01/24 03:59:24, James Cook wrote:
> I would just return the empty string, or maybe a known fixed hash. If tests
need
> something fancier, they can subclass this class.

Done.

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
File extensions/shell/browser/shell_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
extensions/shell/browser/shell_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
On 2015/01/24 03:59:24, James Cook wrote:
> app_shell on Brillo doesn't have a real logged-in user, so not really a
> cryptohome, so this may not be very hash-y. It might just end up as "user". Is
> that OK, or would you prefer returning a known fixed string?

Returning an empty string. If that ends up causing problems down the road we can
fix it for real at that point.

[stevenjb, 2015-01-26 21:06:03]

stevenjb@chromium.org changed reviewers:
+ asargent@chromium.org, skuhne@google.com

[stevenjb, 2015-01-26 21:06:04]

+asargent@ for */extensions/* owner

+skuhne@ for chrome_browser_main_extra_parts_profiles.cc owner

[James Cook, 2015-01-26 21:20:55]

LGTM with a nit and a question.

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
File chrome/browser/extensions/chrome_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/chrome/browser/extension...
chrome/browser/extensions/chrome_extensions_browser_client.cc:109: return
context->GetPath().BaseName().value();
On 2015/01/26 20:36:19, stevenjb wrote:
> On 2015/01/24 03:59:24, James Cook wrote:
> > I don't like this. Isn't the Chrome OS version depending on the path part
> > looking something like a hash?  (Doesn't the cryptohome path have something
> > hash-y in it? u-12345abcdef or similar?)  I think this code means on
> Windows/Mac
> > that the UserIdHash will be "Default" or "James", which could leak
information
> > if the calling code expects something obfuscated. I would either
NOTREACHED()
> or
> > return "" or an error string.
> 
> I'm going to go ahead and make this method Chrome OS only so that nobody
> accidentally uses it on another platform.

Sounds good.

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
File extensions/shell/browser/shell_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
extensions/shell/browser/shell_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
On 2015/01/26 20:36:19, stevenjb wrote:
> On 2015/01/24 03:59:24, James Cook wrote:
> > app_shell on Brillo doesn't have a real logged-in user, so not really a
> > cryptohome, so this may not be very hash-y. It might just end up as "user".
Is
> > that OK, or would you prefer returning a known fixed string?
> 
> Returning an empty string. If that ends up causing problems down the road we
can
> fix it for real at that point.

I'm nervous that this might cause a hard-to-interpret app_shell bug sometime
down the road. I'm having a hard time figuring out what this ID is used for.

Do you know if this function is called just by starting up chrome/app_shell? If
it won't spam, maybe it should also have a NOTIMPLEMENTED()?

https://codereview.chromium.org/870163002/diff/80001/extensions/browser/brows...
File extensions/browser/browser_context_keyed_service_factories.cc (right):

https://codereview.chromium.org/870163002/diff/80001/extensions/browser/brows...
extensions/browser/browser_context_keyed_service_factories.cc:49:
extensions::NetworkingPrivateEventRouterFactory::GetInstance();
nit: no "extensions::" needed

[James Cook, 2015-01-26 21:29:07]

Oh, a couple ideas on testing -- it would be nice to move the tests as well in a
second CL.

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
File
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc
(right):

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc:10:
#include "chrome/browser/extensions/extension_apitest.h"
Oh, since this only depends on extension_apitest.h, could this test be moved
into //extensions and use extensions/browser/api_unittest.h?  It could be a
follow-on CL, this one is big enough.

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
File
chrome/browser/extensions/api/networking_private/networking_private_service_client_apitest.cc
(right):

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
chrome/browser/extensions/api/networking_private/networking_private_service_client_apitest.cc:9:
#include "chrome/browser/browser_process.h"
This doesn't look used, so I wonder if this test could move into //extensions as
well.

[Mr4D (OOO till 08-26), 2015-01-27 00:40:32]

skuhne@chromium.org changed reviewers:
+ skuhne@chromium.org

[Mr4D (OOO till 08-26), 2015-01-27 00:40:33]

lgtm for chrome_browser_main_extra_parts_profiles.cc

[stevenjb, 2015-01-27 01:39:38]

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
File extensions/shell/browser/shell_extensions_browser_client.cc (right):

https://codereview.chromium.org/870163002/diff/40001/extensions/shell/browser...
extensions/shell/browser/shell_extensions_browser_client.cc:77: return
context->GetPath().BaseName().value();
On 2015/01/26 21:20:55, James Cook wrote:
> On 2015/01/26 20:36:19, stevenjb wrote:
> > On 2015/01/24 03:59:24, James Cook wrote:
> > > app_shell on Brillo doesn't have a real logged-in user, so not really a
> > > cryptohome, so this may not be very hash-y. It might just end up as
"user".
> Is
> > > that OK, or would you prefer returning a known fixed string?
> > 
> > Returning an empty string. If that ends up causing problems down the road we
> can
> > fix it for real at that point.
> 
> I'm nervous that this might cause a hard-to-interpret app_shell bug sometime
> down the road. I'm having a hard time figuring out what this ID is used for.
> 
> Do you know if this function is called just by starting up chrome/app_shell?
If
> it won't spam, maybe it should also have a NOTIMPLEMENTED()?

This is only called from the networkingPrivate API to ensure that
networkingPrivate is called for the correct (i.e. primary) user.

I'll change this to call chromeos::LoginState::Get()->primary_user_hash() which
is what networkingPrivate expects, with a TODO to change this if we ever support
multi profile in app_shell.

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
File
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc
(right):

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc:10:
#include "chrome/browser/extensions/extension_apitest.h"
On 2015/01/26 21:29:07, James Cook wrote:
> Oh, since this only depends on extension_apitest.h, could this test be moved
> into //extensions and use extensions/browser/api_unittest.h?  It could be a
> follow-on CL, this one is big enough.

Yes, my intention was to move all of the tests to a follow on. When I started
this there didn't seem to be a lot of test support in /extensions. That may be
better now? Regardless it seemed worthy of a separate CL.

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
File
chrome/browser/extensions/api/networking_private/networking_private_service_client_apitest.cc
(right):

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
chrome/browser/extensions/api/networking_private/networking_private_service_client_apitest.cc:9:
#include "chrome/browser/browser_process.h"
On 2015/01/26 21:29:07, James Cook wrote:
> This doesn't look used, so I wonder if this test could move into //extensions
as
> well.

Yes, I believe this could be moved also, if there is a reasonable replacement
for ExtensionApiTest.

https://codereview.chromium.org/870163002/diff/80001/extensions/browser/brows...
File extensions/browser/browser_context_keyed_service_factories.cc (right):

https://codereview.chromium.org/870163002/diff/80001/extensions/browser/brows...
extensions/browser/browser_context_keyed_service_factories.cc:49:
extensions::NetworkingPrivateEventRouterFactory::GetInstance();
On 2015/01/26 21:20:55, James Cook wrote:
> nit: no "extensions::" needed

Done.

[James Cook, 2015-01-27 03:42:20]

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
File
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc
(right):

https://codereview.chromium.org/870163002/diff/80001/chrome/browser/extension...
chrome/browser/extensions/api/networking_private/networking_private_apitest.cc:10:
#include "chrome/browser/extensions/extension_apitest.h"
On 2015/01/27 01:39:38, stevenjb wrote:
> On 2015/01/26 21:29:07, James Cook wrote:
> > Oh, since this only depends on extension_apitest.h, could this test be moved
> > into //extensions and use extensions/browser/api_unittest.h?  It could be a
> > follow-on CL, this one is big enough.
> 
> Yes, my intention was to move all of the tests to a follow on. When I started
> this there didn't seem to be a lot of test support in /extensions. That may be
> better now? Regardless it seemed worthy of a separate CL.

Test support has gotten much better, thanks to yoz@.
//extensions/extensions_tests.gyp has all the tests runs in extensions_unittests
and extensions_browsertests.  You can probably convert to ShellApiTest. More
unit-test-y items can be converted to ApiUnitTest or ExtensionsTest.

[asargent_no_longer_on_chrome, 2015-01-27 18:31:00]

lgtm w/ one inline question and one meta question:

It looks like after this CL there will still be a few leftover files in these
directories:

chrome/browser/extensions/api/networking_private/
chrome/common/extensions/api/networking_private/

Is the intention that these will be moved out in a subsequent CL? Or do they
have code that has remaining dependencies to other stuff in chrome/? (And if so,
would it make sense to add those concepts to ExtensionsBrowserClient
eventually?)

https://codereview.chromium.org/870163002/diff/100001/extensions/common/permi...
File extensions/common/permissions/extensions_api_permissions.cc (right):

https://codereview.chromium.org/870163002/diff/100001/extensions/common/permi...
extensions/common/permissions/extensions_api_permissions.cc:74:
APIPermissionInfo::kFlagCannotBeOptional,
Is there any reason why this permission cannot be optional? In general we'd
prefer that all permissions be available optionally whenever possible. (I
realize this is the way it was before; just wondering if there was a good reason
or it was just cargo culting other code)

[mef, 2015-01-27 18:51:21]

networking_private lgtm

https://codereview.chromium.org/870163002/diff/100001/extensions/extensions.gyp
File extensions/extensions.gyp (right):

https://codereview.chromium.org/870163002/diff/100001/extensions/extensions.g...
extensions/extensions.gyp:883: ['OS=="win" or OS=="mac"', {
nit: spaces around == (also below).

[stevenjb, 2015-01-27 19:24:52]

The code remaining in src/chrome implements the Verify* methods.

These methods were (somewhat painstakingly) extracted from the rest of the
networkingPrivate implementation specifically so separate the Verify*
implementations (which we will be deprecating and do not want to propagate
outside of Chrome) from the rest of the implementation (which we want available
to other applications, e.g. AppShell).

When these methods are fully deprecated, we will remove that code and those
directories.

https://codereview.chromium.org/870163002/diff/100001/extensions/common/permi...
File extensions/common/permissions/extensions_api_permissions.cc (right):

https://codereview.chromium.org/870163002/diff/100001/extensions/common/permi...
extensions/common/permissions/extensions_api_permissions.cc:74:
APIPermissionInfo::kFlagCannotBeOptional,
On 2015/01/27 18:31:00, Antony Sargent wrote:
> Is there any reason why this permission cannot be optional? In general we'd
> prefer that all permissions be available optionally whenever possible. (I
> realize this is the way it was before; just wondering if there was a good
reason
> or it was just cargo culting other code)

I think this is OK for now. This is a private API and it is highly unlikely that
something using this API wouldn't be badly broken without it.

That said, we can certainly discuss this separately and consider changing to
granting permissions on demand in the future. For the public networking APIs we
are working on that definitely seems like a better approach.

https://codereview.chromium.org/870163002/diff/100001/extensions/extensions.gyp
File extensions/extensions.gyp (right):

https://codereview.chromium.org/870163002/diff/100001/extensions/extensions.g...
extensions/extensions.gyp:883: ['OS=="win" or OS=="mac"', {
On 2015/01/27 18:51:21, mef wrote:
> nit: spaces around == (also below).

Done.

[stevenjb, 2015-01-27 20:16:06]

The CQ bit was checked by stevenjb@chromium.org

[commit-bot: I haz the power, 2015-01-27 20:17:03]

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

[commit-bot: I haz the power, 2015-01-27 20:26:03]

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

[commit-bot: I haz the power, 2015-01-27 20:26:04]

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

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

[stevenjb, 2015-01-28 01:05:14]

The CQ bit was checked by stevenjb@chromium.org

[commit-bot: I haz the power, 2015-01-28 01:06:05]

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

[commit-bot: I haz the power, 2015-01-28 01:13:10]

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

[commit-bot: I haz the power, 2015-01-28 01:13:12]

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

[stevenjb, 2015-01-28 17:24:17]

The CQ bit was checked by stevenjb@chromium.org

[commit-bot: I haz the power, 2015-01-28 17:25:33]

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

[commit-bot: I haz the power, 2015-01-28 17:30:37]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-01-28 17:32:09]

Patchset 10 (id:??) landed as
https://crrev.com/d194dd136f180afc02c930b7a0fbab406671d89c
Cr-Commit-Position: refs/heads/master@{#313537}

[Nikita (slow), 2015-01-29 15:37:18]

nkostylev@chromium.org changed reviewers:
+ nkostylev@chromium.org

[Nikita (slow), 2015-01-29 15:37:19]

FYI, some variation of chrome os gn dbg build is failing.
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...

This is not the CQ trybot just one of the configurations.

[chromium-reviews, 2015-01-29 16:19:20]

Filed https://code.google.com/p/chromium/issues/detail?id=453451 to track

extensions_browsertests is failing to link

Maybe it's missing a dependency on ONC.

I'll take a quick look

On Thu, Jan 29, 2015 at 7:37 AM, <nkostylev@chromium.org> wrote:

> FYI, some variation of chrome os gn dbg build is failing.
> http://build.chromium.org/p/tryserver.chromium.linux/
> builders/linux_chromium_gn_chromeos_dbg/builds/141/steps/
> compile/logs/stdio
>
> This is not the CQ trybot just one of the configurations.
>
> https://codereview.chromium.org/870163002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.