Keep running into problem when building chromeos-chrome package in release 60

59 views
Skip to first unread message

kr...@flintos.io

unread,
Aug 16, 2017, 2:51:06 AM8/16/17
to Chromium OS dev
Hi,

I'm building the 60 release but keep running into problem when building the chromeos-chrome package, at the stage of cloning sources under the src/third_party/webrtc directory of chromium source tree. In the log I noticed these:

Error: Command 'git checkout --quiet 3b55aad9a673614b5cc8ab0e10aec433dbea261f' returned non-zero exit status 128 in /var/cache/chromeos-cache/distfiles/target/chrome-src/src/third_party/webrtc
fatal: reference is not a tree: 3b55aad9a673614b5cc8ab0e10aec433dbea261f

So I looked into the /var/cache/chromeos-cache/distfiles/target/chrome-src/src/third_party/webrtc dir and did a "git checkout 3b55aad9a673614b5cc8ab0e10aec433dbea261f" there, got the same "fatal: reference is not a tree: 3b55aad9a673614b5cc8ab0e10aec433dbea261f".

Then I retried building chromeos-chrome many times, and found that only around 30% of the time it could download all sources successfully and start building. So I compare the successfully downloaded source of third_party/webrtc and the failed one, noticed that the repo is different.

In a successfully cloned third_party/webrtc, I got this in its .git/config
[remote "origin"]
        url = https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = +refs/branch-heads/*:refs/remotes/branch-heads/*
        fetch = +refs/tags/*:refs/tags/*

In a failed clone, I got this in webrtc/.git/config:
[remote "origin"]
        url = https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git
        fetch = +refs/heads/*:refs/remotes/origin/*

The last two "fetch=" lines are missing from the failed clone. I added them manually and run a "git pull" again, some more commits were downloaded and then "git checkout 3b55aad9a673614b5cc8ab0e10aec433dbea261f" worked without problem.

I have no idea why ~30% of the chance the clone process downloaded different .git/config content. I have looked into the DEPS file and there seems no anything special regarding third_party/webrtc repo. Every time when cloning of third_party/webrtc failed gclient complains about corrupted repo and removes everything and re-clone from scratch. This is really annoying as the download is really big. I would be really appreciated if anyone can shed some light here.

Mike Frysinger

unread,
Aug 16, 2017, 3:44:31 PM8/16/17
to kr...@flintos.io, Chromium OS dev
i think you're describing the chrome sync logic which is (almost) entirely done on the browser side.  the ebuild uses chromite/scripts/sync_chrome.py to fetch the code, and that uses gclient to do the actual fetching (which is from Chromium's depot_tools).

i might suggest instead doing the branch checkout yourself outside of CrOS, and then mounting that into your CrOS build and telling the ebuild to use that source tree.  that way you don't have to keep refetching things, and you narrow down the steps.  look into CHROME_ORIGIN=LOCAL_SOURCE workflow.
-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en


kr...@flintos.io

unread,
Aug 18, 2017, 6:35:22 AM8/18/17
to Chromium OS dev, kr...@flintos.io
Hi Mike,

Thanks for your reply. Local source indeed is a practical solution to the problem I encountered.

But I still would like to find out why server source operation failed. I've looked further and its my understanding that if gclient sync command is not called with the --with_branch_heads option then those refs/branch-heads/* will not be cloned to local. However I looked into sync_chrome(file chromite/lib/gclient.py) and it seems that option is there in the Sync method.  I'm really curious about why even with the --with_branch_heads option specified the webrtc module still was cloned without branch heads refs from time to time. I'm accessing Google git server via proxy, could it be the reason?

Mike Frysinger

unread,
Aug 18, 2017, 6:07:19 PM8/18/17
to kr...@flintos.io, Chromium OS dev
sorry, i'm not familiar with gclient internals to provide tips
-mike
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages