The only change to depthcharge in the first failing build was:

https://chromium-review.googlesource.com/#/c/347482/

It doesn't appear related, maybe we have a missing dependency and this failed because a rebuild was triggered?

-> durbin@chromium.org

*adurbin@

_joth@ since it only appears to affect veyron_rialto for some reason?

Off top of my head I don't know why this impacts chrome PFQ, but the underlying issue is in a break in depth charge that only impacts rialto as it's not get a display driver.  That's already reported as  http://crbug.com/615730 

That appears to be the root cause.

Why would you expect that bug not to affect the PFQ?

(Er, not the root cause, but the same problem)

My fuzzy understand was chrome PFQ uses the "simple chrome" workflow to build chrome browser (only) against a pre-built CrOS SDK. So I'm surprised depth charge is built as part of this builder, that was all.

The PFQ uses ToT chrome + ToT chromeos and builds everything, including chrome in the chroot (and typically runs VM and/or HW tests), and also builds simple chrome.

(Note: BuildPackages in the PFQ builders should use prebuilts for packages that do not depend on chromeos-chrome, but apparently depthcharge does somehow depend on the chromeos-chrome package).

The configs for libpayload for veyron_rialto do not have CONFIG_LP_VIDEO_CONSOLE set so I'm unclear why libpayload would be built with this configuration resulting in the linking error. See src/third_party/chromiumos-overlay/sys-boot/libpayload/files/configs/config.veyron 

However, there's also a config.veyron checked into libpayload's configs directory itself. It select CONFIG_LP_COREBOOT_VIDEO_CONSOLE=y which has a dependency on VIDEO_CONSOLE, but that should be effectively ignored. 

Julius is more familiar with all the veyron building and configurations.

> The configs for libpayload for veyron_rialto do not have CONFIG_LP_VIDEO_CONSOLE set so I'm unclear why libpayload would be built with this configuration

CONFIG_LP_VIDEO_CONSOLE is now a default for CONFIG_LP_CHROMEOS, since the majority of our boards use it. It has to be explicitly deselected for boards that don't.

This whole thing was just me not being careful enough when merging the configs and not noticing that Rialto had a difference. Sorry for the hassle. The simple one-line change that disables the option will fix it. (Also, if we care so much about Rialto ToT breakages it really ought to be in the CQ...)

That is an excellent point. It had not occurred to me that there was not already a rialto paladin. I will investigate.

> (Also, if we care so much about Rialto ToT breakages it really ought to be in the CQ...)

Irony is I've been trying to do exactly that for the last few weeks:
https://bugs.chromium.org/p/chromium/issues/detail?id=583465 (plus tree of blocking issue)

I got final the +2 for adding it as important on CQ https://chromium-review.googlesource.com/#/c/347485/
but before I could commit that, this breakage (plus one more break than landed atop it) stopped that config change going in....