Seen for these two CLs:

chromite: https://chromium-review.googlesource.com/c/553462/
depends on
crosutils: https://chromium-review.googlesource.com/c/553404/

This pre-cq build complained in the BootstrapStage: 
https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/pre_cq/builds/41946
https://luci-logdog.appspot.com/v/?s=chromeos%2Fbb%2Fchromiumos.tryserver%2Fpre_cq%2F41946%2F%2B%2F%2A%2A%2Fstdout&s=chromeos%2Fbb%2Fchromiumos.tryserver%2Fpre_cq%2F41946%2F%2B%2F%2A%2A%2Fstderr

but then moved on.
My reading of the code suggests that a paladin builder will actually fail at this point.


I dug a bit and my current understanding is:
(http://cs/chromeos_public/chromite/cbuildbot/stages/sync_stages.py?l=187&rcl=8fbe8f9f69c19213551eccb9adcc31fd6a6df18e)

- Bootstrap looks for all changes that need to be applied
- filters to just the chromite changes
- creates a manifest containing just the chromite project
- tries to apply the _transaction_ for the chosen changes
- At this point, the transaction contains the crosutils change as well. This is supposed to be skipped / failed
- But I see that it fetches the crosutils change, and perhaps tries to apply it to the chromite project (and fails).


This will only happen when a chromite change depends on a non chromite change, i.e., very rarely.

To test this theory, bmgordon@ is going to remove the chromite --> crosutils dependence and try the pre-cq again.