i don't think rvg is necessary when talking about all open source repos

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

commit 7066bc5fd2eb1b3fe2fe8921ae599ddda3105571
Author: Manoj Gupta <manojgupta@google.com>
Date: Fri Feb 09 20:12:00 2018

libcxxabi: Black list from auto uprev.

Some change done in aosp branch is breaking the builds.
Blacklist it for now from auto uprevs.

BUG=chromium:810864
TEST=No uprev done.

Change-Id: Idac6409231a27e1a5891f231fa62793c212d71c6
Reviewed-on: https://chromium-review.googlesource.com/912199
Reviewed-by: Xixuan Wu <xixuan@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Xixuan Wu <xixuan@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Xixuan Wu <xixuan@chromium.org>

[rename] https://crrev.com/7066bc5fd2eb1b3fe2fe8921ae599ddda3105571/sys-libs/libcxxabi/libcxxabi-4.0.0-r32.ebuild
[modify] https://crrev.com/7066bc5fd2eb1b3fe2fe8921ae599ddda3105571/sys-libs/libcxxabi/libcxxabi-9999.ebuild

Chumped in Cl to disable auto uprevs.

 Issue 810861  has been merged into this issue.

I think https://chromium-review.googlesource.com/912328 is needed as well to get the builds working again.

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

commit 8e3fd0dace5cf52f596e65c3ba593926d5235851
Author: Rahul Chaudhry <rahulchaudhry@chromium.org>
Date: Fri Feb 09 20:33:52 2018

sys-libs/libcxxabi: revert commit hashes to last known good versions.

This is a follow up to https://chromium-review.googlesource.com/912199
That CL blacklisted this ebuild from future auto-uprevs, but we also
need to revert the auto-uprev that introduced the build failure:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ed0f28d1109d51d62ebb051eebfdd51d67390d9d%5E%21/#F476

BUG=chromium:810864
TEST='sudo emerge sys-libs/libcxxabi' works.

Change-Id: I1a6c2cd8985f0c190753f9893eb6a4b32ba96b95
Reviewed-on: https://chromium-review.googlesource.com/912328
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Trybot-Ready: Manoj Gupta <manojgupta@chromium.org>

[rename] https://crrev.com/8e3fd0dace5cf52f596e65c3ba593926d5235851/sys-libs/libcxxabi/libcxxabi-4.0.0-r33.ebuild

The underlying problem is fixed now so reducing to P1.

https://luci-milo.appspot.com/buildbot/chromeos/master-paladin/17708 uprev'ed the overlay. In Uprev stage, uprev on libcxxabi was skipped but in PublishUprevChanges stage, libcxxabi was uprev'ed to r31.

08:25:12: INFO: Creating new stable ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild
08:25:12: INFO: Old and new ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild are exactly identical; skipping uprev




11:02:22: INFO: Creating new stable ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild

CQ should have caught this problem earlier at the time when the package was upreved.
From #11, it appears that CQ didn't uprev it in Uprev stage therefore the updated ebuild was not tested.
But somehow PublishUprevChanges staged upreved it and submitted the broken version which broke the later CQ runs.

Submitting an untested uprev looks scary to me.

Add 'Chase-Pending' for team discussions.

Summarizations before discussion:

https://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/17709
https://uberchromegw.corp.google.com/i/chromeos/builders/master-paladin/builds/17710

Build 17708,
In Uprev stage: sys-libs/libcxxabi-4.0.0-r31 is not upreved due to it's identical.
In buildPackage stage: sys-libs/libcxxabi-4.0.0-r30 is built & succeeds
17708 succeeds, and sys-libs/libcxxabi-4.0.0-r31 is published in https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ed0f28d1109d51d62ebb051eebfdd51d67390d9d without any problems, with the same command used in Uprev stage.


Build 17709:
In uprev stage: sys-libs/libcxxabi/libcxxabi-4.0.0-r32.ebuild is not upreved due to it's identical.
In BuildPackage stage: sys-libs/libcxxabi-4.0.0-r31 is built and failed.
No commit in PublishUprevChanges for sys-libs/libcxxabi-4.0.0-r32 in /chromiumos/overlays/chromiumos-overlay due to it's identical.

Build 17710:
In uprev stage: No attempt to uprev
In setupBoard stage: Since CL:912199 is chumped, sys-libs/libcxxabi-4.0.0-r32 is manually updated to blocking further CLs. But CL:912328 is not committed, it still includes the bad commits in libcxxabi-4.0.0-r31. So fails.
No commit in PublishUprevChanges.


Build 17711:
In uprev stage: No uprev
In setupBoard stage: Due to CL:912328, sys-libs/libcxxabi-4.0.0-r33 is manually generated to be the same as sys-libs/libcxxabi-4.0.0-r30, last known good version.  sys-libs/libcxxabi-4.0.0-r33 passes (the same as 17708)
In buildPackage stage: sys-libs/libcxxabi-4.0.0-r33 passes also (the same as 17708)
No commit in PublishUprevChanges I guess.

So the cause is there's a chance that even if stage Uprev (http://shortn/_kGVjP06kXa) & PublishUprevChanges (http://shortn/_q2U6EzmG88) calls the same script "cros_mark_as_stable", the package is probably skipping Uprev when CQ begins, but get new changes published in PublishUprevChanges when CQ ends. Obviously we're submitting changes without testing for some time.

https://luci-milo.appspot.com/buildbot/chromeos/master-paladin/17708


08:14 am CommitSyncStage

it fetched the latest version fd5cfb8.

  <project name="platform/external/libcxxabi" path="src/aosp/external/libcxxabi" remote="aosp" revision="fd5cfb8557ee5599498a63f08f500ae930a1b53b" upstream="refs/heads/master"/>


08:25 am UprevStage

it found no change, so it skipped uprev for libcxxabi.

INFO: Creating new stable ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild
08:25:12: INFO: Old and new ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild are exactly identical; skipping uprev


10:23 am
A CL was merged to libcxxabi.
https://android-review.googlesource.com/c/platform/external/libcxxabi/+/611958


10:56:55 am PublishUprevChanges

it saw the new changes, so it created the new ebuilds and pushed it. 

Fetching project platform/external/libcxxabi
From https://android.googlesource.com/a/platform/external/libcxxabi

11:02:22: INFO: Creating new stable ebuild /b/c/cbuild/repository/src/third_party/chromiumos-overlay/sys-libs/libcxxabi/libcxxabi-4.0.0-r31.ebuild

Awaiting further occurrences.