Yesterday I switched my gentoo repo from rsync to git, and the initial
--sync with an empty directory did a git clone successfully.
Today, when I try to sync, it always fails:
$ sudo emerge --sync >>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'... /usr/bin/git fetch origin
error: RPC failed; HTTP 504 curl 22 The requested URL returned error:
504 fatal: the remote end hung up unexpectedly !!! git fetch error in /var/db/repos/gentoo
Action: sync for repo: gentoo, returned code = 128
The SSL connection to anongit.gentoo.org happens, the handshake goes
OK, a few frames of data go back and forth, then the nothing happens
for 60s and the client end sends a FIN.
After the initial sync which does a git clone, how do you do
subsequent sync operations?
On Wed, 13 Oct 2021 18:25:12 -0000 (UTC), Grant Edwards wrote:[...]
Yesterday I switched my gentoo repo from rsync to git, and the initial
--sync with an empty directory did a git clone successfully.
Today, when I try to sync, it always fails:
$ sudo emerge --sync >>> Syncing repository 'gentoo' into
'/var/db/repos/gentoo'... /usr/bin/git fetch origin
error: RPC failed; HTTP 504 curl 22 The requested URL returned error:
504 fatal: the remote end hung up unexpectedly
After the initial sync which does a git clone, how do you do
subsequent sync operations?
emerge --sync works here. What do you have in repos.conf?
emerge --sync works here. What do you have in repos.conf?
I didn't have a sync-depth setting. Setting that to 1 fixed the
problem. It was apparently timing out because it takes too long for
the server to respond to a fetch with an unlimited depth. Seems like
maybe it ought to default to 1? Is there some reason it should default
to doing unlimited depth fetch operations?
Is there some reason it should default
to doing unlimited depth fetch operations?
On Wed, Oct 13, 2021 at 2:50 PM Grant Edwards <grant.b.edwards@gmail.com> wrote:
Is there some reason it should default
to doing unlimited depth fetch operations?
If all you want is a repo, no reason to set the depth higher.
If you want to see the history then you'll want it all.
On Thursday, 14 October 2021 03:50:59 BST Grant Edwards wrote:
On 2021-10-13, Rich Freeman <rich0@gentoo.org> wrote:<grant.b.edwards@gmail.com> wrote:
On Wed, Oct 13, 2021 at 2:50 PM Grant Edwards
Is there some reason it should default
to doing unlimited depth fetch operations?
If all you want is a repo, no reason to set the depth higher.
Then a default of 1 seems like the obvious "right" answer.
Unfortunately, it defaults to "unlimited" according to https://wiki.gentoo.org/wiki//etc/portage/repos.conf
sync-depth
Specifies sync depth to use for DVCS repositories. If set to 0,
the depth is unlimited. Defaults to 0.
If you want to see the history then you'll want it all.
Apparently, that's the default. Without any sync-depth setting the
fetch was stalling and then timing out after 60s. With sync-depth=1,
the fetch completed in about 1s.
I have it set to 8 here, for no reason I can remember. Is there a disadvantage
in that?
--
Regards,
Peter.
On 2021-10-13, Rich Freeman <rich0@gentoo.org> wrote:<grant.b.edwards@gmail.com> wrote:
On Wed, Oct 13, 2021 at 2:50 PM Grant Edwards
Is there some reason it should default
to doing unlimited depth fetch operations?
If all you want is a repo, no reason to set the depth higher.
Then a default of 1 seems like the obvious "right" answer.
Unfortunately, it defaults to "unlimited" according to https://wiki.gentoo.org/wiki//etc/portage/repos.conf
sync-depth
Specifies sync depth to use for DVCS repositories. If set to 0,
the depth is unlimited. Defaults to 0.
If you want to see the history then you'll want it all.
Apparently, that's the default. Without any sync-depth setting the
fetch was stalling and then timing out after 60s. With sync-depth=1,
the fetch completed in about 1s.
So the default being for git to act like git, instead of git to act
like an alternative to rsync, makes perfect sense in that context.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 292 |
Nodes: | 16 (2 / 14) |
Uptime: | 185:27:27 |
Calls: | 6,616 |
Files: | 12,165 |
Messages: | 5,314,808 |