2

I try to repo sync cyanogenmod source. It got until the 99% stage, but it seems that there is a big file in this stage, and because of quite frequent disconnections of my internet connection, it doesn't manage to download it.

Every time a disconnection occurs, a fatal: early EOF is printed, the repo sync stops and it seems that in its next run, it starts this file from the beginning, although saving a temporary object of it before.

Is there a way to tell repo sync to start in its next run from the point it stopped in a specific file, instead of starting it from the beginning?

I tried running the repo sync in an inifinite loop overnight, but the download didn't end, instead my memory got full.

The temporal files are under the folder ~/android/system/.repo/project-objects/CyanogenMod/android_frameworks_base.git/objects/pack in the format:

 78M    tmp_pack_7JhRgA
 106M   tmp_pack_fprjIZ
 523M   tmp_pack_tydAd5
 436M   tmp_pack_po9dEw
 780M   tmp_pack_rewDSS

I also tried to delete these temporary files before every new repo sync to avoid a full memory, but it still doesn't help to end the download. By the way, it seems that deleting them doesn't make the next run to start from a different point, so it confirms the suspicion that it ignores them in the next run.

The exact repo sync command that I run is repo sync -j4 -f -c

The repo init command was: repo init -u https://github.com/CyanogenMod/android.git -b cm-13.0

The error printed after an internet disconnection is:

Fetching projects:  94% (497/528)  Fetching project   CyanogenMod/android_frameworks_opt_vcard
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   
Fetching projects:  96% (507/528)  Fetching project    CyanogenMod/android_hardware_qcom_audio00 KiB/s   
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   616668), 4.93 MiB | 131.00 KiB/s   
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   616668), 5.12 MiB | 123.00 KiB/s   
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   
Fetching projects:  99% (523/528)  Fetching project CyanogenMod/android_hardware_qcom_audio
Fetching project CyanogenMod/android_hardware_qcom_audio00 KiB/s   
error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
J. Doe
  • 191
  • 1
  • 10
  • You should probably reach out on the Git mailing list, git@vger.kernel.org, about this. IIRC there was recently a discussion about supporting resume in the `git fetch`, which I suspect is what your `repo sync` relies on, but I don't remember what the conclusion of that discussion was. – Pockets Jun 18 '17 at 23:34

2 Answers2

2

I attempted the following command just now and sync went trough. I got all the projects

repo init -u https://github.com/CyanogenMod/android.git -b cm-13.0`
repo sync -j8 -q -c --no-tags`

The -c/--current-branch option for repo sync makes repo to fetch only the branch you really need instead of all branches of each git.

The --no-tags avoids syncing all the tags

Using -c and --no-tags makes you download lesser, thus sync goes faster.

If you want to make it even faster you could try --depth=<n>, but that will prune the git history.

After an internet disconnection repo effectively picks up where it left off. It does work through the project list from the beginning again, may fetch some new data for projects that were processed already.

But it moves quite fast through previously synced projects, because all the data that it had previously fetched is there in the .repo directory.

I hope ensure you aren't doing repo init every time after disconnection.

sob
  • 982
  • 11
  • 31
  • Hey, I don't understand how this could help to my situation. My problem is the frequent internet disconnections. Which of those flags could help that? – J. Doe Jun 19 '17 at 12:30
0

At the end, it seems that the problem was enhanced because using VMWare, which was used to run the Ubuntu machine. Somehow VMWare caused the internet interface to disconnect frequently, and when I tried using VirtualBox, although now and then a fatal: early EOF occured, at the end the internet interface was steady enough to complete the sync.

J. Doe
  • 191
  • 1
  • 10