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(a)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