Bug 307

Summary: pybindgen not fetchable via web proxy
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: build systemAssignee: ns-bugs <ns-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: gjcarneiro
Priority: P3    
Version: ns-3-dev   
Hardware: All   
OS: All   

Description Tom Henderson 2008-09-03 17:48:02 UTC
I've not been able to retrieve pybindgen from behind a proxy, despite setting https_proxy and Ubuntu Preferences->Network Proxy.  Is there some other way to configure proxy support for bzr?

This is a typical error:
Trying to fetch pybindgen; this will fail if no network connection is available.
 =>  /usr/bin/bzr checkout -rrevno:572 https://launchpad.net/pybindgen /home/user/hg/ns-3-dev/bindings/python/pybindgen
bzr: ERROR: Invalid url supplied to transport: "Host empty in: proxy.example.com"

I'm not sure whether this is a bzr problem (have Googled and found some people asking about bzr's proxy support) but I think that, regardless, if this occurs, a more prominent error should display at the end of ./waf configure that alerts the user to the lack of Python support.
Comment 1 Gustavo J. A. M. Carneiro 2008-09-04 07:06:01 UTC
(In reply to comment #0)
> I've not been able to retrieve pybindgen from behind a proxy, despite setting
> https_proxy and Ubuntu Preferences->Network Proxy.  Is there some other way to
> configure proxy support for bzr?
> 
> This is a typical error:
> Trying to fetch pybindgen; this will fail if no network connection is
> available.
>  =>  /usr/bin/bzr checkout -rrevno:572 https://launchpad.net/pybindgen
> /home/user/hg/ns-3-dev/bindings/python/pybindgen
> bzr: ERROR: Invalid url supplied to transport: "Host empty in:
> proxy.example.com"
> 
> I'm not sure whether this is a bzr problem (have Googled and found some people
> asking about bzr's proxy support)

Try upgrading bzr, or setting the http_proxy environment variable.  Luckily in the release tarballs bzr will not be used, so this is a problem for ns-3 developers only.

> but I think that, regardless, if this occurs,
> a more prominent error should display at the end of ./waf configure that alerts
> the user to the lack of Python support.

So you are saying that lack of Python support is more important than e.g. lack of Gtk support, so that it deserves an additional warning in the end?  Or do you think we should perhaps present a summary in the end of all optional features, saying if they are enabled or not?  If seen such summaries in some configure scripts in some projects before...

Comment 2 Tom Henderson 2008-09-04 08:26:03 UTC
> > I'm not sure whether this is a bzr problem (have Googled and found some people
> > asking about bzr's proxy support)
> 
> Try upgrading bzr, or setting the http_proxy environment variable.  Luckily in
> the release tarballs bzr will not be used, so this is a problem for ns-3
> developers only.

setting http_proxy has no effect.  Agree this is mainly a development problem.  I didn't mark it as high priority; is more of an inconvenience, along the lines of the thread Mathieu started yesterday.  However, I am able to get other pieces through a proxy.
  
> 
> > but I think that, regardless, if this occurs,
> > a more prominent error should display at the end of ./waf configure that alerts
> > the user to the lack of Python support.
> 
> So you are saying that lack of Python support is more important than e.g. lack
> of Gtk support, so that it deserves an additional warning in the end?  Or do
> you think we should perhaps present a summary in the end of all optional
> features, saying if they are enabled or not?  If seen such summaries in some
> configure scripts in some projects before...
> 

I think it would be helpful to have an output showing optionally configured pieces; e.g.

Configuration status of ns-3 optional components:
-------------------------------------------------
Python bindings:  enabled
nsc:  disabled
...

I think Mathieu's proposal will also help to clearly identify what was successfully downloaded or not.
Comment 3 Gustavo J. A. M. Carneiro 2008-09-04 08:34:31 UTC
Correction: in this case you need to define https_proxy, not http_proxy.

I had not read Mathieu's proposal.  Commented now.
Comment 4 Tom Henderson 2008-09-04 08:50:34 UTC
(In reply to comment #3)
> Correction: in this case you need to define https_proxy, not http_proxy.
> 
> I had not read Mathieu's proposal.  Commented now.
> 

Yes, I tried setting both of them.
Comment 5 Gustavo J. A. M. Carneiro 2008-09-04 09:17:42 UTC
I have bzr 1.3.1, and I am behind a company http firewall.  Setting both:

export http_proxy=http://proxy:3128
export https_proxy=http://proxy:3128

Makes bzr work for me.  I have to export both variables at the same time, though.
Comment 6 Tom Henderson 2008-09-04 11:38:07 UTC
(In reply to comment #5)
> I have bzr 1.3.1, and I am behind a company http firewall.  Setting both:
> 
> export http_proxy=http://proxy:3128
> export https_proxy=http://proxy:3128
> 
> Makes bzr work for me.  I have to export both variables at the same time,
> though.
> 

I tried this again today; no luck:

bzr: ERROR: Invalid http response for https://launchpad.net/pybindgen/.bzr/branch-format: Unable to handle http code 400: Bad Request

I'm on bzr-1.3.1 also, on Ubuntu.  Maybe this is just a local proxy problem for me, though, since you were able to get it to work.  

mark it as WORKSFORME?
Comment 7 Gustavo J. A. M. Carneiro 2008-09-04 13:20:42 UTC
One way to confirm whether it is a proxy problem would be to open the URL on the web browser: https://launchpad.net/pybindgen/.bzr/branch-format

You should receive the text page containing:

    Bazaar-NG meta directory, format 1