New issue
Advanced search Search tips

Issue 697106 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

internal & external manifests no longer match exactly

Project Member Reported by cmt...@chromium.org, Feb 28 2017

Issue description

ChromeOS has two manifests that are always supposed to be identical:

manifest/full.xml
manifest-internal/external_full.xml

These two manifests are in different repos, so updating them requires two separate CLs.  On Feb. 14 a single CL was committed that updated one manifest but there was no corresponding CL to update the other, so now the two manifests are not identical any more.  This needs to be fixed ASAP.

$ cd manifest-internal
$ diff external_full.xml ../manifest/full.xml 
336,340d335
<   <project path="src/third_party/ntirpc"
<            name="chromiumos/third_party/ntirpc" />
<   <project path="src/third_party/nfs-ganesha"
<            name="chromiumos/third_party/nfs-ganesha"
<            revision="refs/heads/V2.4-stable" />
$

The git log entry for the change is:

commit 60bd5934391c4eec147de868283f7817fc87a042
Author: Dylan Reid <dgreid@chromium.org>
Date:   Tue Feb 14 17:47:34 2017 -0800

    Add nfs-ganesha and ntirpc to the manifest
    
    Add:
    chromiumos/third_party/ntirpc
    and
    chromiumos/third_party/nfs-ganesha
    
    nfs-ganesha is being used for NFS experiments.  It depends on ntirpc.
    Use the 2.4-stable branch of Ganesha as master/2.5 isn't ready for production
    use yet.
    
    BUG=none
    TEST='repo sync' and verify that code is checked out in the right place.
    
    Change-Id: Id9c4189961756be1ea9691e0759d0701fe84f132
    Signed-off-by: Dylan Reid <dgreid@chromium.org>
    Reviewed-on: https://chrome-internal-review.googlesource.com/328011
    Commit-Ready: Slava Malyugin <slavamn@google.com>
    Tested-by: Slava Malyugin <slavamn@google.com>
    Reviewed-by: Slava Malyugin <slavamn@google.com>




 
As a note, repohooks should have alerted you to this when the original CL was uploaded.

Why didn't that happen?

Comment 2 by cmtice@google.com, Mar 1 2017

It's been my observation that the repohooks that checks for this only does so in one directory, not in both; so if you do the 'repo upload' from the "wrong" repository, it doesn't check to make sure the files match.
I didn't miss it at upload, I missed it at cq:(

443306 is the change to full.xml, which will hopefully land soon.

Thanks!

If you are getting them back in sync, and you are strongly confident, please chump it in.
I sent it to the CQ again, if this run doesn't work, I'll chump it.

Thanks Don.
One question: I know I made a recent change in the manifests myself...are you sure the change you are about to chump is really up-to-date with any other changes?
I didn't diff the whole file, but i just double checked that ntirpc and nfs-ganesha will be in sync after this change lands.
$ tail -n 15 full.xml
  <project path="src/aosp/toolchain/gcc"
           name="toolchain/gcc"
           revision="32c89c19b042a12b5a1bf0153299154ea5435c03"
           remote="aosp" />

  <!-- Weave repository. -->
  <project path="src/weave/libweave"
           name="weave/libweave"
           revision="refs/heads/refactor-01-2017"
           remote="weave" />

  <!-- Manifests are not standard projects. -->
  <project path="manifest" name="chromiumos/manifest" />

</manifest>

Please make sure the gcc revision number in your change (at the very bottom of the file, as shown above) matches the number shown above.

How is gcc related to my change?  If it needs to get resynced, it should happen in its own change.
The GCC change has gone in; I just want to make sure your change does not undo it.
This should just involve rebasing your change.
Diff the two manifests after applying your change. If they are exactly
identical, everything is good.
Oh, that's OK, git will take care of that.  My change doesn't touch the gcc version so gcc won't be affected.
Status: Fixed (was: Untriaged)
Closing this sine problem seems to be fixed.

Sign in to add a comment