Some weeks have passed since this issue came up; wish I'd be reading the list more
frequently. For whatever it's worth I remember having trouble with subversion behind
a corporate firewall when bootstrapping prefix Gentoo on Solaris half a year ago. I
used to run a script that was supposed to go unattended for many hours, and I was
using the code below as a workaround for the subversion issue.
When reading the code snippet you should assume that PROXYHOST is set to a hostname
or IP address, and PROXYPORT is a port number. And `die' is a function that makes the
script print a message and die of course.
Note that the first lap hangs for a couple of minutes (?) before failing, so some
patience is required when trying it out.
--------- 8< -----------------------------------------------
# Configure proxy for subversion, if it seems
# to be needed. Run this code twice: the first lap
# creates the config directory and files and fails
# because we have not done the proxy configuration;
# on the second lap we configure for proxy and should
# succeed. If we are not behind a proxy we should
# succeed on the first attempt.
while [ $COUNT -lt 2 -a $RESULT -ne 0 ]; do
if [ -n "$PROXYHOST" -a -n "$PROXYPORT" -a -f $SVNCONF ]; then
-e '/^[global/,$s|^# http-proxy-host =.*|http-proxy-host = '"$PROXYHOST"'|'
-e '/^[global/,$s|^# http-proxy-port =.*|http-proxy-port = '"$PROXYPORT"'|'
if cmp $TMPFILE $SVNCONF >/dev/null 2>&1; then
mv $TMPFILE $SVNCONF
Fabian Groffen wrote:
> On 03-12-2007 15:01:47 -0500, A. Khattri wrote:
>> On Fri, 30 Nov 2007, Peter Ansell wrote:
>>> Why wouldn't an svn update to a HTTP server work from behind a
>>> corporate firewall? The prefix does not use rsync for emerge --sync,
>>> it uses subversion, if that is what you are thinking about.
>> I guess the firewall + proxy server combo doesn't like it:
>> $ emerge --sync
>>>>> Starting svn update...
>> svn: REPORT request failed on '/svn/proj/alt/!svn/vcc/default'
>> svn: REPORT of '/svn/proj/alt/!svn/vcc/default': 400 Bad Request
> Hmmm, yuck. I think it doesn't use the proxy or something. Or maybe it
> If that is what you have, then you're doomed. Unfortunately we (still)
> don't have any alternative to svn.
email@example.com mailing list