New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 615278 link

Starred by 10 users

Issue metadata

Status: Verified
Owner:
Closed: May 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , iOS
Pri: 0
Type: Bug-Regression



Sign in to add a comment

fetch chromium fails while trying to fetch libc++ and libc++abi

Project Member Reported by rkuroiwa@chromium.org, May 27 2016

Issue description

Version: 7715e330567f9aab72ed070618723d533457207d
OS: Windows

This probably happens on other platforms as well.

`fetch chromium` failed first and I kept on trying to `gclient sync`.
Looks like its failing to checkout the right commit.
It says aad34a13af010898f54c1bb2069194cb083cea4b here https://code.google.com/p/chromium/codesearch#chromium/src/buildtools/DEPS&l=8
But it should be b1ece9c037d879843b0b0f5a2802e1e9d443b75a

For libc++abi it should be 0edb61e2e581758fc4cd4cd09fc588b3fc91a653

`gclient sync` output below

What is the expected output?
fetch chromium and gclient sync to succeed.

What do you see instead?
D:\chrome\src>gclient sync
.gclient file in parent directory D:\chrome might not be the file you want to us
e
Syncing projects: 100% (75/75) src\buildtools\third_party\libc++abi\trunk

src\buildtools\third_party\libc++\trunk (ERROR)
----------------------------------------
[0:00:36] Started.
[0:00:44] _____ src\buildtools\third_party\libc++\trunk : Attempting rebase onto
 aad34a13af010898f54c1bb2069194cb083cea4b...
[0:00:45]
[0:00:45] Rebase produced error output:
fatal: Needed a single revision
Does not point to a valid commit: aad34a13af010898f54c1bb2069194cb083cea4b
----------------------------------------
Error: 74> Unrecognized error, please merge or rebase manually.
74> cd D:\chrome\src\buildtools\third_party\libc++\trunk && git rebase --onto aa
d34a13af010898f54c1bb2069194cb083cea4b refs/remotes/origin/master


 
Labels: -Pri-2 Pri-1
This is breaking all chromecast builders

To reproduce locally: rm -rf buildtools/ and then run gclient sync again.

libc++abi fails with:
fatal: reference is not a tree: 9a39e428d018b723d7d187181fd08908b1cb6bd0



Cc: glider@chromium.org earthdok@chromium.org
Labels: OS-Linux
Cc: thakis@chromium.org
Labels: -Type-Bug Type-Bug-Regression

Comment 4 by thakis@chromium.org, May 27 2016

Cc: aga...@chromium.org
Looks like the git mirror is in a weird state? Nothing has changed here recently.
Cc: carusom@chromium.org
Labels: OS-iOS
This is breaking official iOS builders as well.

Comment 6 by phihag...@gmail.com, May 27 2016

I'm seeing what I believe to be a related issue; running  fetch chromium  on a new system, I'm seeing the attached output, where

[0:09:46] _____ Conflicting directory found in /home/phihag/src/buildtools/third_party/libc++/trunk. Moving to /home/phihag/_bad_scm/src/buildtools/third_party/libc++/trunkHIpS_S.

seems to be another symptom of the same problem.
fetch.log
3.5 KB View Download
Issue 615304 has been merged into this issue.
Cc: olivierrobin@chromium.org
Labels: -Pri-1 Pri-0
It appears this affects anyone pulling a new checkout.

Comment 9 by aga...@chromium.org, May 27 2016

Owner: aga...@chromium.org
Status: Started (was: Untriaged)
This is my fault, see https://bugs.chromium.org/p/chromium/issues/detail?id=609914

Trying to figure out best resolution now. Not as simple as a revert.
Plan:
* Change the new copy-config to only copy refs/heads/master, instead of refs/*
* Get access to the old refs on the old git_updater host
* Push the old refs to refs/heads/old_svn
Then the old git hashes will be accessible to anyone who fetches/clones with the default refspec (refs/heads/*), and will be accessible to gclient which directly fetches the specified hash.

Will update again when these steps are completed, or if any roadblocks are hit.
Status: Fixed (was: Started)
The repos now have the old refs pushed to them under refs/heads/old_svn. I removed my buildtools/ checkout and successfully ran a gclient sync. This should be fixed.

Please let me know if you see any continuing failures locally or on bots.
I have triggered an ios build to verify this fix.
Looks good on the iOS side.
Issue 615427 has been merged into this issue.
Status: Verified (was: Fixed)

Sign in to add a comment