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  INSTALL  README       TODO

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

~/git/gramps$ less .git/config

        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = ssh://
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
.git/config (END)

2013/11/9 Vassilii Khachaturov <>
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://  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                  pygobject.doap  tests    demos    gi        m4               pygtkcompat  docs     HACKING  pre-commit.hook  README
vassilii@kotar:~/Gramps$ git branch
* master
vassilii@kotar:~/Gramps$ git branch -r
   origin/HEAD -> origin/master
vassilii@kotar:~/Gramps$ ls
AUTHORS       COPYING  examples  INSTALL      NEWS                  pygobject.doap  tests    demos    gi        m4               pygtkcompat  docs     HACKING  pre-commit.hook  README
vassilii@kotar:~/Gramps$ git log --name-status|head -60
commit 7193f0509a0ed7da7c810daa6733e34a22db3180
Author: Martin Pitt <>
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
     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
     property of the Gtk.Box superclass instead).

M       gi/overrides/
M       tests/
M       tests/

commit 79aea2655db11bc9d2c0ad75c87862b2b66da594
Author: Simon Feltman <>
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
     a tuple containing None). Instead of adding more complex checking,
     remove the checking as it is unnecessary to begin with.

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

commit f32d649b72f865e32cc2b62a54d927b8345da0c8
Author: Martin Pitt <>
Date:   Mon Oct 28 16:00:57 2013 +0100 post-release bump to 3.11.2


commit 5bcdb56433d0ba2976f05946c6c5b6ffe3e84901
Author: Martin Pitt <>
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?


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
Gramps-devel mailing list