Bugzilla – Bug 307
pybindgen not fetchable via web proxy
Last modified: 2008-10-07 01:28:45 EDT
You need to log in before you can comment on or make changes to this bug.
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.
(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...
> > 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.
Correction: in this case you need to define https_proxy, not http_proxy. I had not read Mathieu's proposal. Commented now.
(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.
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.
(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?
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