That is the pygobject repo, which I don't think is on SF.
Somebody could have pushed that to the gramps git though. Doing git pull here I don't see it though,

~/git/gramps$ ls
AUTHORS  debian   FAQ        help     LICENSE      NEWS    RELEASE_NOTES  test          windows
COPYING  docs     gramps     images   mac          po      scripts        TestPlan.txt
data     example  Gramps.py  INSTALL  MANIFEST.in  README  setup.py       TODO

Have a look in your Gramps/.git/config. For me it is:

~/git/gramps$ less .git/config

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = ssh://bmcage@git.code.sf.net/p/gramps/source
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
.git/config (END)


2013/11/9 Vassilii Khachaturov <vassilii@tarunz.org>
On 08.11.2013 23:08, Nick Hall wrote:
> On 08/11/13 20:27, John Ralls wrote:
>>> The clone never completes for me. I tried several times, and this is
>>>> what it looks like (after having added the SF SSH key to my ssh agent):
>>>>
>>>> vassilii@kotar:~$ git clone
>>>> ssh://vassilii@git.code.sf.net/p/gramps/source  Gramps
>>>> Cloning into 'Gramps'...
>>>> remote: Counting objects: 19299, done.
>>>> remote: Compressing objects: 100% (9130/9130), done.
>>>> error: RPC failed; result=56, HTTP code = 200iB | 687 KiB/s
>>>> fatal: The remote end hung up unexpectedly
>>>> fatal: early EOF
>>>> fatal: index-pack failed
>>>>
>> How many bytes are you getting? The whole repo is 249M.
>> Seems strange, but I wonder if SF is having trouble with everyone hitting it at the same time.
>
It had never gotten to the "Receiving objects" state, i.e., I got no
bytes at all.
Maybe indeed throttling, or maybe there was some ECN trouble between me
and SF...

Anyway, right now I got a funnier result. Did this:
and it seems to have succeeded:
Cloning into 'Gramps'...
remote: Counting objects: 19299, done.
remote: Compressing objects: 100% (9130/9130), done.
remote: Total 19299 (delta 14620), reused 13483 (delta 10005)
Receiving objects: 100% (19299/19299), 3.63 MiB | 656 KiB/s, done.
Resolving deltas: 100% (14620/14620), done.

But you can see it is much smaller size. I looked inside:

vassilii@kotar:~$ cd Gramps/
vassilii@kotar:~/Gramps$ ls
AUTHORS       COPYING  examples  INSTALL      NEWS
pygi-convert.sh                  pygobject.doap  tests
autogen.sh    demos    gi        m4           PKG-INFO.in
pygobject-3.0.pc.in              pygtkcompat
configure.ac  docs     HACKING   Makefile.am  pre-commit.hook
pygobject-3.0-uninstalled.pc.in  README
vassilii@kotar:~/Gramps$ git branch
* master
vassilii@kotar:~/Gramps$ git branch -r
   origin/HEAD -> origin/master
   origin/PYGTK_1_99_15
   origin/a93755ddba9a176
   origin/extension-class-branch
   origin/gsoc2009
   origin/gtk-3.0
   origin/gtk-gnome-1-2
   origin/invoke-rewrite
   origin/llvm
   origin/master
   origin/py3k
   origin/pygi-py3k
   origin/pygobject-2-10
   origin/pygobject-2-12
   origin/pygobject-2-14
   origin/pygobject-2-16
   origin/pygobject-2-18
   origin/pygobject-2-28
   origin/pygobject-2-8
   origin/pygobject-3-0
   origin/pygobject-3-10
   origin/pygobject-3-2
   origin/pygobject-3-4
   origin/pygobject-3-8
   origin/pygtk-2-0
   origin/pygtk-2-2
   origin/pygtk-2-4
   origin/pygtk-2-6
   origin/pygtk-compat
   origin/pygtk-introspection
   origin/python-3
   origin/python22-branch
   origin/short-class-names-branch
   origin/windows
vassilii@kotar:~/Gramps$ ls
AUTHORS       COPYING  examples  INSTALL      NEWS
pygi-convert.sh                  pygobject.doap  tests
autogen.sh    demos    gi        m4           PKG-INFO.in
pygobject-3.0.pc.in              pygtkcompat
configure.ac  docs     HACKING   Makefile.am  pre-commit.hook
pygobject-3.0-uninstalled.pc.in  README
vassilii@kotar:~/Gramps$ git log --name-status|head -60
commit 7193f0509a0ed7da7c810daa6733e34a22db3180
Author: Martin Pitt <martinpitt@gnome.org>
Date:   Tue Nov 5 15:28:12 2013 +0100

     Add type checking to positional Gtk.Box and Gtk.Window ctor arguments

     Gtk.Box and Gtk.Window are base classes of a lot of widgets. Avoid
confusion
     when trying to create a subclass of them through the GObject
constructor with
     positional arguments by at least verifying that their type is
right. Otherwise
     you can do things like

       chooser = Gtk.FileChooserWidget(Gtk.FileChooserAction.SELECT_FOLDER)

     which succeeds, but does not have the desired effect (it sets the
"homogenous"
     property of the Gtk.Box superclass instead).

     https://bugzilla.gnome.org/show_bug.cgi?id=711487

M       gi/overrides/Gtk.py
M       tests/test_overrides_gtk.py
M       tests/test_properties.py

commit 79aea2655db11bc9d2c0ad75c87862b2b66da594
Author: Simon Feltman <sfeltman@src.gnome.org>
Date:   Mon Nov 4 03:29:57 2013 -0800

     Remove overzealous argument checking for callback userdata

     Remove check which ensures userdata is None if the callback is None.
     This check would need to become more complicated with recent
versions of
     PyGObject where userdata can be variable (would also need to check
against
     a tuple containing None). Instead of adding more complex checking,
simply
     remove the checking as it is unnecessary to begin with.

     https://bugzilla.gnome.org/show_bug.cgi?id=711173

M       gi/pygi-marshal-from-py.c
M       tests/test_overrides_gtk.py

commit f32d649b72f865e32cc2b62a54d927b8345da0c8
Author: Martin Pitt <martinpitt@gnome.org>
Date:   Mon Oct 28 16:00:57 2013 +0100

     configure.ac: post-release bump to 3.11.2

M       configure.ac

commit 5bcdb56433d0ba2976f05946c6c5b6ffe3e84901
Author: Martin Pitt <martinpitt@gnome.org>
Date:   Mon Oct 28 15:59:51 2013 +0100

     release 3.11.1

M       NEWS

So it looks like I've received a wrong repo via the clone. I've never
experienced anything like that before. Note: I haven't accepted any new
SSH host keys since the git transition, and I'd used SSH to sync with
the SF SVN before, and it worked OK. What's going on? Some weird MITM
attack? Problem with SF virtual hosting/mountpoints?

V.

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel