jwerner@ needs to chump in his changes as they can't pass the CQ. 
+akeshet@, comment?

Not sure I understand. Can you land the manifest changes first, and then the change that depends on them later?

jwerner:

"In fact, if you look closely at the error output of https://uberchromegw.corp.google.com/i/chromeos/builders/kevin-paladin/builds/440/steps/BuildPackages/logs/stdio you can see that the coreboot ebuild checked out arm-trusted-firmware at commit a8de89c97461b7cc13a596db8771c30843b06405, even though the blamelist for that builder run also includes https://chromium-review.googlesource.com/c/452659/3/full.xml which should have changed that to 95fba14bc483055114d40e72386daf9c021177b6 "

comment 3 is quote from jwerner@.

I think I could from a compile-time viewpoint, but I'd rather not because the code would be broken (at runtime) then. I'd rather just keep the CQ depend for documentation and chump them all. I have tested them locally, of course.

(Regardless, this needs to be fixed... it would be quite possible to have a similar situation where the changes in both repos are compile-time dependent on another.)

Can you link directly to the 3 CLs and explain the situation? It's hard to parse from this bug.

https://chromium-review.googlesource.com/c/452640/
https://chromium-review.googlesource.com/c/452659/
https://chrome-internal-review.googlesource.com/c/335484/

The latter two are manifest changes that change the pinned SHA for arm-trusted-firmware. The former is a coreboot change that adds an #include to a file in arm-trusted-firmware that just got added.

All changes form a CQ-depend circle so they should all be committed together. However, as you can see from https://uberchromegw.corp.google.com/i/chromeos/builders/kevin-paladin/builds/440/steps/BuildPackages/logs/stdio it seems that despite applying the manifest change in that builder run, the CQ didn't actually use the new pinned SHA when testing the coreboot ebuild. (The output shows that it's still using a8de89c97461b7cc13a596db8771c30843b06405 when it should be using 95fba14bc483055114d40e72386daf9c021177b6.)

Honestly, I don't really care if you fix this because it happens so rarely (and we wanted to change the way arm-trusted-firmware is handled anyway), I just want someone to tell me that I'm okay to chump these in right now.

Don you mentioned you might have an idea about this?

Well, I wrote the code to test manifest changes in the CQ. It seems that that isn't working right and this should be fixed.