help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error while trying to clone the Emacs git repo (via http)


From: Bob Proulx
Subject: Re: Error while trying to clone the Emacs git repo (via http)
Date: Thu, 26 Jan 2017 11:54:07 -0700
User-agent: NeoMutt/20170113 (1.7.2)

Dani Moncayo wrote:
> I'm trying to clone the Emacs git repository, from a cygwin
> environment, installed on my work PC.  This PC connects to the
> internet through a corporate proxy server.

I am one of the admins working on Savannah.  I have been working on
the server migration too so can help you with this problem.

> I've configured git to know about the proxy:
> 
>   $ git config --global http.proxy http://myproxy.mycompany.com:xxxx
>
> And then I've tried to clone the repo:
> 
>   $ git clone -b master git://git.sv.gnu.org/emacs.git
>   Cloning into 'emacs'...
>   fatal: unable to connect to git.sv.gnu.org:
>   git.sv.gnu.org[0: 208.118.235.72]: errno=Connection timed out

The native git protocol uses tcp port 9418 and has no ability to use
the http proxy.  It looks like your environment blocks port 9418
making that transport impossible.  Setting up an http proxy won't be
helpful when trying to use either git:// or ssh:// protocols.

[[As an aside a workaround is if you had any other location you could
use for checkout.  Checkout there.  Then clone from your location.
This is possible and practical with git because every full clone is a
full copy of the repository and may itself be used to mirror it
elsewhere.]]

> My second try has been to uset the http protocol (since the proxy
> probably does not allow the git protocol):

I definitely recommend either the native git or ssh transports.  But
if neither of those are available that is the reason that the "dumb"
http transport exists.

>   $ git clone http://git.sv.gnu.org/r/emacs.git
>   Cloning into 'emacs'...
>   remote: Counting objects: 780227, done.
>   remote: aborting due to possible repository corruption on the remote side.
>   fatal: protocol error: bad pack header
> 
> The above error message suggests a problem on the remote side.  So,
> could anyone try the above and see if it fails the same way?

Confirmed.  This appears to be a bug in the older git code still
active on the old server.  I say old server because there is a new
server.  We have migrated most of the version services to the new
server.  I moved git there also but had to recall it back to the old
one.

[[Git has actually been moved back and forth a few times between the
old server to the new and back again over the last month.  I try not
to flip-flop it too often because people with IP checking enabled get
warning messages about the IP change causing them noise and extra
effort.  (If you have experienced this, sorry!)  But I had to recall
it back to the old server in order to avoid breakage while working
through the problem reports on the new.

The current (hopefully last) problem I am working through is a problem
using the git-daemon for native git protocol access combined with
shallow checkouts (using "--depth 1") that fails.  All other
combinations seem to be working except for that one corner case.]]

Here is a workaround that is somewhat of a hack.  The new server is
running and things are mostly okay on the new server, other than that
last problem with git-daemon.  The DNS name is simply pointing to the
old server at the moment.  Therefore as a small hack you can use our
test dns name that points to the new server and get the newer git
version installed there.  Should work for you.

  git clone https://git0.savannah.gnu.org/r/emacs.git
    Cloning into 'emacs'...
    ... takes about twenty minutes with no output on my network ...

Consider that name and protocol to be beta at this moment and not
quite released to production yet.  I am still hacking on things.  So
there may be transient problems when I have it disabled during a
debugging session.  And since the DNS name is a temporary then at some
point it will get cleaned up and you will need to revert to the
production name.  But if you use it and it works then the result is
correct.  It should work for you and get you over this problem.  If
you encounter problems using it I would appreciate problem reports.

> If the problem is actually on the server side, who could I report it to?
>
> I've reported the issue to the savannah admins:
>   http://savannah.gnu.org/support/?109236

That was perfect!  Thanks!

Just to pass along information...  If you don't like the form tracker
and prefer mailing lists like this one then it is also okay to report
issues to the savannah-hackers-public AT gnu.org mailing list too.

There are too many Savannah mailing lists to keep track of and even I
am always referring to the list of mailing lists on the project site.

  https://savannah.gnu.org/mail/?group=administration

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]