Unfortunately that didn't work (i mean the tarball download/unpack and exporting env var)... I can make it to work as the installation is described by several simple python scripts but this is not right solution.

Thank you guys for help, it seems to me that the only way is to ask our sysadmins to open git ports for several opensource git repositories. I hope they won't refuse.

Thank you again!

2011/1/24 Justin Clift <jclift@redhat.com>
On 24/01/2011, at 11:42 PM, Daniel P. Berrange wrote:
<snip>
> Err, http:// access works fine with gitorious. I think
> you simply didn't wait long enough. GIT's  HTTP access
> mechanism is seriously inefficient, and doesn't appear
> to give you ongoing progress feedback like the git://
> protocol, so expect to wait a while. I've verified I
> can clone the main GIT repo over http in about 2 minutes
> using:
>
> git clone http://git.gitorious.org/libvirt/libvirt.git


Thanks Daniel.  Tried http again (first time today) and this
time it worked:

 $ time git clone http://git.gitorious.org/libvirt/libvirt.git
 Cloning into libvirt...

 real  9m57.209s
 user  0m11.130s
 sys   0m5.670s
 $

~10 mins, but still, at least it worked.

For the gnulib submodule, I'm thinking it might be possible
to use a tarball as a workaround.

Fyodor, are you ok to try something?

If you can grab this tarball (41MB):

 http://justinclift.fedorapeople.org/gnulib_commit_2f41af65.tar.bz2

Extract it somewhere (ie /tmp/gnulib), then set the
GNULIB_SRCDIR environment variable to point to it prior to doing
the libvirt pieces.

 $ export GNULIB_SRCDIR=/tmp/gnulib
 $ git clone http://git.gitorious.org/libvirt/libvirt.git
 $ cd libvirt
 $ ./autogen.sh

That *might* work.  Not for sure, but probably worth trying.

+ Justin