Following recommendation by vapier to take discussion back to bug. 

What generates chromite/config/config_dump.json?

What does `"manifest": "official.xml",` mean?

I thought what's missing is `"useflags": [ "chrome-internal" ],`  rather than `"useflags": [ "-chrome-internal" ],` 

It seems that the internal board configs are correctly generated [1] with official_chrome [2] (i.e. "chrome_internal" [3]).

Where is the issue?

[1]: https://cs.corp.google.com/chromeos_public/chromite/config/chromeos_config.py?g=0&l=1620

[2]: https://cs.corp.google.com/chromeos_public/chromite/config/chromeos_config.py?g=0&l=1093

[3]: https://cs.corp.google.com/chromeos_public/chromite/lib/constants.py?type=cs&q=USE_CHROME_INTERNAL+p:chromeos_public&g=0&l=503

Discussion on CL mentioned in #1 is at https://chrome-internal-review.googlesource.com/c/chromeos/overlays/overlay-eve-private/+/659672.

Adding a few more people who might help.

Answering from #1:

chromeos_config defines out build configurations. chromeos_config_unittest --update will regenerate the assorted artifact files like config_dump.json.

I don't understand how `"manifest": "official.xml",` entered the conversation, but it's one of the settings generally required for internal builds.

Looking at config_dump.json: eve-tot-chrome-pfq-informational does not have useflags: "-chrome_internal". eve-tot-chromium-pfq-informational, on the other hand, *does*.

I ran a fresh generate to make sure this wasn't from someone checking in a bad config, but that did not fix the issue.

Poring through the settings upstream, it does look like it should be generated the right way around, so nothing obvious to tweak there.

That sounds correct.

eve-tot-pfq-informational is intended to build ChromeOS (internal) and eve-tot-chromium-pfq-informational is intended to build ChromiumOS (external).

So why does the step AndroidMetadata fails with:

The following REQUIRED_USE flag constraints are unsatisfied:
    build_native_assistant? ( chrome_internal )

?

Does that step uses different configs? Is there an ordering issue?

Oh. OK, disregard all that. The "-" is not an indicator of an option, it's a subtraction sign. That is all WAI. config_dump.json has the correct values.

(quality of life improvement: make those use '!' instead of '-' to indicate that it should not be present)

> (quality of life improvement: make those use '!' instead of '-' to indicate that it should not be present)

sounds like bikeshedding.  the syntax here is for portage/emerge and it uses - not ! to disable options.

This directly led to me misunderstanding the flags, since the same line if interpreted as a shell option means the precise opposite of what it means here. Ambiguity is bad.

I have no idea what you mean by "shell option". bash/sh don't use ! for shell options (set/shopt).

if you were to take that USE syntax and set it in your environment before running emerge, the syntax is exactly the same.

Please let's get back to the real issue: 

Adding a few more people who modified android_stages.py recently: +nya@ +linben@

Is the AndroidMetadata stage missing something to guarantee the use of the official chrome_internal when it's in the USE flags?

For example, in the simplechrome stage we extend the arguments of chrome-sdk by adding "--internal" when we find the "chrome_internal" USE flag. https://cs.corp.google.com/chromeos_public/chromite/cbuildbot/stages/chrome_stages.py?q=USE_CHROME_INTERNAL+p:chromeos_public&dr=C&l=323

+davidriley@ and +bhthompson@ if they have some ideas.

FWIW, AndroidMetadata just happens to be the first thing that causes Portage to try to map through all the dependencies for the build, so if the configuration is broken we fail here first, so this is unlikely something AndroidMetadata is doing wrong, and more like something is wrong with the build itself.

But the build seems to be correctly configured. Looking at config_dump.json, the "eve-tot-chromium-pfq-informational" [1] has a 

"useflags": [
  "-chrome_internal"
], 


while "eve-tot-chrome-pfq-informational" doesn't.


[1]: https://cs.corp.google.com/chromeos_public/chromite/config/config_dump.json?g=0&maxsize=9934696&l=23424

The requirement for chrome_internal to be there for build_native_assistant has been around since early July https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1130456

It appears this was armed in https://chrome-internal-review.googlesource.com/658390 which landed on Aug 2 which is when this failed, I am surprised this made it through the CQ if it breaks this way.

However eve-release is passing (mostly) https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8938919164786318336 so the build itself cannot be fundamentally broken...

Xiaohui, Bernie and I agreed that we should land this CL ASAP to unblock the PFQs, and then we will land some follow up CLs to fix this dependency to make sure the assistant is built only when chrome_internal flag is provided on eve.

Passing back to xiaohuic@.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/dad4675f8cfa9ded3bf1a150449e81d6b9583a5d

commit dad4675f8cfa9ded3bf1a150449e81d6b9583a5d
Author: Xiaohui Chen <xiaohuic@google.com>
Date: Thu Aug 09 09:21:25 2018

Only build assistant when chrome_internal is set

BUG= chromium:871343 
TEST=locally build eve

Change-Id: I7bfa58f7828d06845736a48351523baaf402c789
Reviewed-on: https://chromium-review.googlesource.com/1168188
Commit-Ready: Xiaohui Chen <xiaohuic@chromium.org>
Tested-by: Xiaohui Chen <xiaohuic@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Bernie Thompson <bhthompson@chromium.org>

[modify] https://crrev.com/dad4675f8cfa9ded3bf1a150449e81d6b9583a5d/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild

Build cycled green this morning.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/overlay-eve-arcnext-private/+/24c8988b76b4f373a88e5e0b66ba0de10fb87619

commit 24c8988b76b4f373a88e5e0b66ba0de10fb87619
Author: Xiaohui Chen <xiaohuic@google.com>
Date: Tue Aug 14 12:55:32 2018