bzr xmlrpc client doesn't use http proxy, causing network errors trying to resolve lp: urls

May be you refer to bug #74759 ?

But the code path in that bug involved http, that's not the case here.

On Tue, 2008-01-29 at 04:17 +0000, David Cournapeau wrote:
> Public bug reported:
>
> When trying to push to launchpad using lp: url, I got the following:
>
> bzr: ERROR: socket.gaierror: (-3, 'Temporary failure in name
> resolution')

Is there a standard for specifying a DNS proxy like there
is for http? Is a DNS proxy a standard thing anyway?
Why isn't the proxy just specified in /etc/resolv.conf?

Thanks,

James

I can resolve the proxy DNS, of course. But I cannot resolve any other address without using the proxy first. I don't know anything about how it works, but with 'normal' proxy, you use it once you get the IP (no need for proxy to resolve DNS -> ip). In my case, even the step DNS -> IP needs the proxy somehow.

> Vincent: yes, this one. I don't know if anything can be done to solve it.

Still there in 1.5. Is there something I can do to solve this ? This makes using bzr and launchpad rather annoying to me, hence the incentive to make it work :)

We are using the standard system calls for resolving host names. So we would need something like this to work:

  python -c "import socket; socket.gethostbyname('www.google.com')"

I would assume that this would be some sort of machine configuration, not something that we would handle specially in our program.

On Thu, 2008-05-22 at 14:59 +0000, John A Meinel wrote:
> We are using the standard system calls for resolving host names. So we
> would need something like this to work:
>
> python -c "import socket; socket.gethostbyname('www.google.com')"
>
> I would assume that this would be some sort of machine configuration,
> not something that we would handle specially in our program.

The thing is, with http proxies you do not need local DNS to work. So we
shouldn't try to resolve names when using an http proxy.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

John A Meinel wrote:
> We are using the standard system calls for resolving host names. So we
> would need something like this to work:
>
> python -c "import socket; socket.gethostbyname('www.google.com')"
>

This does not work, indeed.

> I would assume that this would be some sort of machine configuration,
> not something that we would handle specially in our program.
>
I don't agree it is a configuration problem. All software work fine on
my machine, from wget to firefox; bzr works fine, when http protocol is
used. I think it is more linked to a problematic use of http proxy in
bzr for some protocols (bzr:// and lp:// do not work ATM)

cheers,

David

Is this something you won't fix ? Since some protocols already support it (http), isn't it easy to add support for the other ones ?

On Sat, 2008-06-07 at 11:44 +0000, David Cournapeau wrote:
> Is this something you won't fix ? Since some protocols already support
> it (http), isn't it easy to add support for the other ones ?

Depends on the protocol.

The lp: protocol makes an http request - its a bug if that does use the
proxy. After that it either makes a bzr+ssh request (which is not
trivially proxiable), or another http request (which again should use
the proxy).

sftp is not trivially proxiable.

ditto ftp.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Essentially, I was surprised that depending on whether I used lp or nor, http works or not in my configuration. So the bug really is that lp does not handle proxy for its first http request ?

On Sun, 2008-06-08 at 06:35 +0000, David Cournapeau wrote:
> Essentially, I was surprised that depending on whether I used lp or nor,
> http works or not in my configuration. So the bug really is that lp does
> not handle proxy for its first http request ?

Its likely yes.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

It this difficult to fix ? I have to use ssh tunnel to access launchpad, which is annoying. Again, if I can do help solving the problem...

This is technically a bug in Python's XMLRPC lib, see this bug report:
http://bugs.python.org/issue648658

To quote a bit:

  The current xmlrpclib can't communicate through a proxy
  server. In particular, the two Transport classes
  contained within xmlrpclib use httplib directly and, as
  such, do not support the proxy handling as offered by
  urllib.

I don't know if we can put together our own "xmlrpclib Transport" class, but it seems like it is a fundamental problem inside of python's xmlrpclib.

Is there a way to link a bug with Python's bugtracker?

Will it be better to replace XMLRPC with REST interface?

john> Is there a way to link a bug with Python's bugtracker?

Congratulations mentioning it just dit it (see 'Remote bug watches' frame on this page (~top right).

john> but it seems like it is a fundamental problem inside of python's xmlrpclib.

Yes. As you pointed out proxy handling is available only in urllib2 and even there we had to work-around some deficiencies and we rely heavily on _urllib2_wrappers for HTTP/1.1 and proxy handling (mainly CONNECT, access to the proxy definitions, authentication (not needed here I think)) .

Is it possible to to do it in two steps?
1.) resolve the lp: link
2.) check out

I am also behind a firewall that needs proxies, I can use tsocks to tunnel everything (except normal http that uses the normal proxy).

Stefan Kost wrote:
> Is it possible to to do it in two steps?
> 1.) resolve the lp: link
> 2.) check out

Yes. That's what we do.

Aaron

As far as I understood, you do that in one go. Please at least print the resolved URL. what I ment was:
> bzr resolve lp:foo
lp:foo = https://code.launchpad.net/foo
> bzr branch https://code.launchpad.net/foo
...

The problem is that you mix proxied and un-proxied conection in one operation. I can checkout code if I have the http: link.

No it's really made in two steps.

The problem is that the lp translation needs to connect to the launchpad.net site and does so using the python xmlrpc library which *doesn't* handle all proxies configurations (yours is one).

The http client implementations specific to bzr works around the urllib2 proxy handling bugs which allows http[s] connections to work.

The bugs the python httplib library (used by both xmlrpc and urllib2 libraries) are known and worked on but they may not land in python before 2.7 or 3.1.

So there is no way (today) to give you the result of the lp translation.

It is mayby two steps internaly but this is not available from the commandline ui. For the user its *one* operation.

> It is mayby two steps internaly but this is not available from the commandline ui. For the user its *one* operation.

We are in violent agreement !

But you were asking for a feedback or some way to get the translation done while resolving the lp url, this can't be done because of the proxy bug. Either we can resolve it and exposing the translation is useless or we can't.

To workaround this bug, I would agree to go to launchpad by the web to see which is the translation of lp:foo but I don't know how to do that. I know that the main branch of my project is ~gtg/gtg/trunk but I didn't succeed in trying to do any of bzr branch http(s)://(code.)launchpad.net/~gtg/gtg/trunk

Go to:
  http://launchpad.net/gtg

Click 'Code', this goes to :

  https://code.launchpad.net/gtg

Click 'lp:gtg', this goes to :

  https://code.launchpad.net/~gtg/gtg/trunk

Now do:

  bzr branch https://code.launchpad.net/~gtg/gtg/trunk

vila : that's what I did but I have :

bzr: ERROR: Connection error: while sending POST /%7Egtg/gtg/trunk/.bzr/smart: (8, 'EOF occurred in violation of protocol')

So I assume that this error is not related to the current bug.

Behind proxy, I sparodically get stuff like this:

Merging from remembered parent location
http://bazaar.launchpad.net/~mdipierro/web2conf/devel/
bzr: ERROR: Invalid http response for
http://bazaar.launchpad.net/%7Emdipierro/web2conf/devel/.bzr/repository/packs/c27a5afe823f2b87b7b46e1136bfa12d.pack:
Expected a boundary (1i4ZlhblF0tixfV2r?mo) line, got ''

(on either Fedora or Windows).

I see this on numerous repositories - and accross bzr versions (currently

Regards,
Yarko

On Thu, Dec 4, 2008 at 8:05 AM, Lionel Dricot <email address hidden> wrote:

> vila : that's what I did but I have :
>
> bzr: ERROR: Connection error: while sending POST
> /%7Egtg/gtg/trunk/.bzr/smart: (8, 'EOF occurred in violation of
> protocol')
>
> So I assume that this error is not related to the current bug.
>
> --
> bzr launchpad does not handle proxy when used for name resolution
> https://bugs.launchpad.net/bugs/186920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Bazaar Version Control System: Triaged
> Status in Launchpad Bazaar Integration: Confirmed
> Status in Python: Confirmed
>
> Bug description:
> When trying to push to launchpad using lp: url, I got the following:
>
> bzr: ERROR: socket.gaierror: (-3, 'Temporary failure in name resolution')
>
> Traceback (most recent call last):
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 806, in run_bzr_catch_errors
> return run_bzr(argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 762, in run_bzr
> ret = run(*run_argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 492, in run_argv_aliases
> return self.run(**all_cmd_args)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/builtins.py",
> line 726, in run
> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 688, in open_from_transport
> redirected)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/transport/__init__.py",
> line 1661, in do_catching_redirections
> return action(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 665, in find_format
> transport, _server_formats=_server_formats)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 1417, in find_format
> return format.probe_transport(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 1427, in probe_transport
> format_string = transport.get(".bzr/branch-format").read()
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/plugins/launchpad/lp_indirect.py",
> line 137, in get
> self._request_redirect(relpath)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/plugins/launchpad/lp_indirect.py",
> line 130, in _request_redirect
> target = self._resolve(branchpath) + extra
> File
> "/home/david/local/stow/bzr-1.1...

>>>>> "yarko" writes:

    yarko> Behind proxy, I sparodically get stuff like this:
    yarko> Merging from remembered parent location
    yarko> http://bazaar.launchpad.net/~mdipierro/web2conf/devel/
    yarko> bzr: ERROR: Invalid http response for
    yarko> http://bazaar.launchpad.net/%7Emdipierro/web2conf/devel/.bzr/repository/packs/c27a5afe823f2b87b7b46e1136bfa12d.pack:
    yarko> Expected a boundary (1i4ZlhblF0tixfV2r?mo) line, got ''

    yarko> (on either Fedora or Windows).

    yarko> I see this on numerous repositories - and accross bzr versions
    yarko> (currently

Too bad your email sounds incomplete... But I think it's not
relevant to *this* bug, sounds more like bug #198646.

If that's not the case please file a *new* bug.

On Thu, Dec 4, 2008 at 12:06 PM, vila
<<email address hidden><v.ladeuil%<email address hidden>>
> wrote:

> >>>>> "yarko" writes:
>
> yarko> Behind proxy, I sparodically get stuff like this:
> yarko> Merging from remembered parent location
> yarko> http://bazaar.launchpad.net/~mdipierro/web2conf/devel/<http://bazaar.launchpad.net/%7Emdipierro/web2conf/devel/>
> yarko> bzr: ERROR: Invalid http response for
> yarko>
> http://bazaar.launchpad.net/%7Emdipierro/web2conf/devel/.bzr/repository/packs/c27a5afe823f2b87b7b46e1136bfa12d.pack
> :
> yarko> Expected a boundary (1i4ZlhblF0tixfV2r?mo) line, got ''
>
> yarko> (on either Fedora or Windows).
>
> yarko> I see this on numerous repositories - and accross bzr versions
> yarko> (currently
>
> Too bad your email sounds incomplete... But I think it's not

...email is complete: ends with "got [two single quotes with nothing in
between]" - and you're right - this is like 198646 (thanks)

Yarko

>
> relevant to *this* bug, sounds more like bug #198646.
>
> If that's not the case please file a *new* bug.
>
> --
>

>>>>> "yarko" writes:

<snip/>

    yarko> I see this on numerous repositories - and accross bzr versions
    yarko> (currently
    >>
    >> Too bad your email sounds incomplete... But I think it's not

    yarko> ...email is complete: ends with "got [two single quotes with nothing in
    yarko> between]"

I wasn't referring to that part (which is fine and allowed me to
identify bug #198646), but to:

    yarko> I see this on numerous repositories - and accross bzr versions
    yarko> (currently

currently what ?

    yarko> - and you're right - this is like 198646 (thanks)

Good.

On Fri, Dec 5, 2008 at 2:27 AM, vila
<<email address hidden><v.ladeuil%<email address hidden>>
> wrote:<snip>

> yarko> ...email is complete: ends with "got [two single quotes with
> nothing in
> yarko> between]"
>
> I wasn't referring to that part (which is fine and allowed me to
> identify bug #198646), but to:
>
> yarko> I see this on numerous repositories - and accross bzr versions
> yarko> (currently
>
> currently what ?
>

RIght - this I think is where I was going to give more data - and
experienced the "it fails about 90% of the time, and then once in a while
just works and gets the data..." grrrrrrr

cheers,
Yarko

This isn't a bug in Launchpad per se, rather it's a bug in the Launchpad plugin.

As far as xmlrpclib not supporting proxies, this is not really true. See http://docs.python.org/library/xmlrpclib.html which gives an example of how to use a proxy. (Also pasted below for reference, but it's formatting will probably look weird here.)

"""
To access an XML-RPC server through a proxy, you need to define a custom transport. The following example shows how:

import xmlrpclib, httplib

class ProxiedTransport(xmlrpclib.Transport):
    def set_proxy(self, proxy):
        self.proxy = proxy
    def make_connection(self, host):
        self.realhost = host
        h = httplib.HTTP(self.proxy)
        return h
    def send_request(self, connection, handler, request_body):
        connection.putrequest("POST", 'http://%s%s' % (self.realhost, handler))
    def send_host(self, connection, host):
        connection.putheader('Host', self.realhost)

p = ProxiedTransport()
p.set_proxy('proxy-server:8080')
server = xmlrpclib.Server('http://time.xmlrpc.com/RPC2', transport=p)
print server.currentTime.getCurrentTime()
"""

I just checked the launchpad xmlrpclib usage and I see it uses https. The previous link and the corresponding example code doesn't address https.

I am still getting a time out error with the proposed solution:

C:\Programme\Bazaar\plugins>bzr checkout --lightweight https://code.launchpad.net/~bzr/bzr-merge-into/trunk merge_into
bzr: ERROR: Connection error: while sending POST /%7Ebzr/bzr-merge-into/trunk/.bzr/smart: (10060, 'Operation timed out')

2 bits

1) The best url is actually "http://bazaar.launchpad.net/..." as that is the actual hosting area. (The 'http://code...' URLs have redirects over to the 'bazaar.launchpad.net')

2) I don't know if https versus http is causing you problems here, but the actual hosting is done over regular http, (Not https).

3) If you are getting a timeout during POST, that is because we are probing if the HTTP url has smart-server support. Your proxy seems to be intercepting these requests and hanging forever. To disable, you should be able to do:

bzr branch nosmart+http://bazaar.launchpad.net/~bzr/bzr-merge-into/trunk

Hello,
this still seems to be an issue:
getting external branches behind a proxy:

> bzr branch nosmart+http://bazaar.launchpad.net/~bzr/bzr-merge-into/trunk
bzr: ERROR: Connection error: while sending GET /%7Ebzr/bzr-merge-into/trunk/.bzr/branch-format: (10060, 'Operation timed out')

This seems to be an issue for others to consider migration to other systems:
http://groups.google.com/group/web2py/msg/b71ef6f346395b8d

On Thu, 2009-04-09 at 09:30 +0000, Tim wrote:
> Hello,
> this still seems to be an issue:
> getting external branches behind a proxy:
>
>
> > bzr branch nosmart+http://bazaar.launchpad.net/~bzr/bzr-merge-into/trunk
> bzr: ERROR: Connection error: while sending GET /%7Ebzr/bzr-merge-into/trunk/.bzr/branch-format: (10060, 'Operation timed out')

http uses the proxy setting quite well - I think this particular symptom
is either misconfiguration, or a different bug.

-Rob

So finally is there any answer or some hack to make it work temporary since I really need to download stuff from the trunk now.

By the way, I am using Unix system.

Thanks and Regards,

--ubuntol

2009/6/2 ubuntol <email address hidden>:
> So finally is there any answer or some hack to make it work temporary
> since I really need to download stuff from the trunk now.
>
> By the way, I am using Unix system.

The best workaround at present is to manually expand the URL into an
SSH url yourself, eg

 bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk

--
Martin <http://launchpad.net/~mbp/>

On Thu, Jun 4, 2009 at 4:15 AM, Martin Pool <email address hidden> wrote:

> 2009/6/2 ubuntol <email address hidden>:
> > So finally is there any answer or some hack to make it work temporary
> > since I really need to download stuff from the trunk now.
> >
> > By the way, I am using Unix system.
>
> The best workaround at present is to manually expand the URL into an
> SSH url yourself, eg
>
> bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk<http://bazaar.launchpad.net/%7Ebzr/bzr/trunk>

I know the proxy I've been behind doesn't allow external ssh connections.
I also remember experiencing sparodic behavior with this over days, over
clients.
(I also no longer use the proxy)

>
> --
> Martin <http://launchpad.net/~mbp/ <http://launchpad.net/%7Embp/>>
>
> --
> bzr launchpad does not handle proxy when used for name resolution
> https://bugs.launchpad.net/bugs/186920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Bazaar Version Control System: Triaged
> Status in Launchpad Bazaar Integration: Invalid
> Status in Python: Confirmed
>
> Bug description:
> When trying to push to launchpad using lp: url, I got the following:
>
> bzr: ERROR: socket.gaierror: (-3, 'Temporary failure in name resolution')
>
> Traceback (most recent call last):
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 806, in run_bzr_catch_errors
> return run_bzr(argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 762, in run_bzr
> ret = run(*run_argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 492, in run_argv_aliases
> return self.run(**all_cmd_args)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/builtins.py",
> line 726, in run
> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 688, in open_from_transport
> redirected)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/transport/__init__.py",
> line 1661, in do_catching_redirections
> return action(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 665, in find_format
> transport, _server_formats=_server_formats)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 1417, in find_format
> return format.probe_transport(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 1427, in probe_transport
> format_string = transport.get(".bzr/branch-format").read()
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/plugins/launchpad/lp_indirect.py",
> line 137, in get
> self._request_redirect(relpath)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/plugins/launchpad/lp_indirect.py",
> line 130, in _request_redirect
> target = self._resolve(branchpath) + extra
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/plu...

2009/6/5 yarko <email address hidden>:
> On Thu, Jun 4, 2009 at 4:15 AM, Martin Pool <email address hidden> wrote:
>
>> 2009/6/2 ubuntol <email address hidden>:
>> > So finally is there any answer or some hack to make it work temporary
>> > since I really need to download stuff from the trunk now.
>> >
>> > By the way, I am using Unix system.
>>
>> The best workaround at present is to manually expand the URL into an
>> SSH url yourself, eg
>>
>>  bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk<http://bazaar.launchpad.net/%7Ebzr/bzr/trunk>
>
>
> I know the proxy I've been behind doesn't allow external ssh connections.

If you can't make outgoing ssh connections you can't write to
Launchpad. You can still read from all public branches with urls like
this:

  http://bazaar.launchpad.net/~bzr/bzr/trunk

--
Martin <http://launchpad.net/~mbp/>

On Fri, Jun 5, 2009 at 12:56 AM, Martin Pool <email address hidden> wrote:

> 2009/6/5 yarko <email address hidden>:
> > On Thu, Jun 4, 2009 at 4:15 AM, Martin Pool <email address hidden> wrote:
> >
> >> 2009/6/2 ubuntol <email address hidden>:
> >> > So finally is there any answer or some hack to make it work temporary
> >> > since I really need to download stuff from the trunk now.
> >> >
> >> > By the way, I am using Unix system.
> >>
> >> The best workaround at present is to manually expand the URL into an
> >> SSH url yourself, eg
> >>
> >> bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk<http://bazaar.launchpad.net/%7Ebzr/bzr/trunk>
> <http://bazaar.launchpad.net/%7Ebzr/bzr/trunk>
> >
> >
> > I know the proxy I've been behind doesn't allow external ssh connections.
>
> If you can't make outgoing ssh connections you can't write to
> Launchpad. You can still read from all public branches with urls like
> this:
>
> http://bazaar.launchpad.net/~bzr/bzr/trunk<http://bazaar.launchpad.net/%7Ebzr/bzr/trunk>
>

Well... you can _attempt_ to read; and when that doesn't work, you can
attempt htttp+nosmart://...
...and when neither of those work, you can wait a day or two and try
again...

At least that has been my (longtime now) experience...

>
> --
> Martin <http://launchpad.net/~mbp/ <http://launchpad.net/%7Embp/>>
>
> --
> bzr launchpad does not handle proxy when used for name resolution
> https://bugs.launchpad.net/bugs/186920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Bazaar Version Control System: Triaged
> Status in Launchpad Bazaar Integration: Invalid
> Status in Python: Confirmed
>
> Bug description:
> When trying to push to launchpad using lp: url, I got the following:
>
> bzr: ERROR: socket.gaierror: (-3, 'Temporary failure in name resolution')
>
> Traceback (most recent call last):
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 806, in run_bzr_catch_errors
> return run_bzr(argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 762, in run_bzr
> ret = run(*run_argv)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/commands.py",
> line 492, in run_argv_aliases
> return self.run(**all_cmd_args)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/builtins.py",
> line 726, in run
> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 688, in open_from_transport
> redirected)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/transport/__init__.py",
> line 1661, in do_catching_redirections
> return action(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 665, in find_format
> transport, _server_formats=_server_formats)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/site-packages/bzrlib/bzrdir.py",
> line 1417, in find_format
> return format.probe_transport(transport)
> File
> "/home/david/local/stow/bzr-1.1/lib/python2.5/...

2009/6/6 yarko <email address hidden>:
> Well... you can _attempt_ to read; and when that doesn't work, you can
> attempt htttp+nosmart://...
> ...and when neither of those work, you can wait a day or two and try
> again...
>
> At least that has been my (longtime now) experience...

That sounds bad. Could you file another bug with more details, or
point me to one if it exists?

--
Martin <http://launchpad.net/~mbp/>

Yes, me neither. I could not do that:

dhcp09:~ ubuntol$ bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk
    -bash: bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk: No such file or directory

On Fri, 2009-06-12 at 13:44 +0000, ubuntol wrote:
> Yes, me neither. I could not do that:
>
> dhcp09:~ ubuntol$ bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk
> -bash: bzr+ssh://bazaar.launchpad.net/~bzr/bzr/trunk: No such file or directory

You still need to be running bzr -
bzr <command> bzr+ssh://.......

I'm trying fix this by using a modified form of Bill Bumgarner's HTTPTransport (python bug #648658) for xmlrpclib which allows it to use urllib2 and thus an HTTP proxy, but I'm having a problem where the XMLRPC reply from launchpad is just an empty page.

C:\dev>bzrdev launchpad-open lp:bzr
HTTPTransport: url=https://xmlrpc.edge.launchpad.net/bazaar/
Request headers:
  Host: xmlrpc.edge.launchpad.net
  Content-type: text/xml
  User-agent: bzr/2.1.0dev2 (xmlrpclib/1.0.1)
Request Body:
<?xml version='1.0'?>
<methodCall>
<methodName>resolve_lp_path</methodName>
<params>
<param>
<value><string>bzr</string></value>
</param>
</params>
</methodCall>

Response headers:
  Content-Type: text/html
  Refresh: 0; URL=https://xmlrpc.edge.launchpad.net/bazaar/
Response data:
<HTML></HTML>

Any idea what could be causing this? Is the XMLRPC request malformed?

Milestone is 2.1.0b2, is this bug fixed yet? I am using bzr 2.1.1

On 15 May 2010 14:52, Madhusudan.C.S <email address hidden> wrote:
> Milestone is 2.1.0b2, is this bug fixed yet? I am using bzr 2.1.1

Yes, it's fixed in 2.1.1.

--
Martin <http://launchpad.net/~mbp/>

    > Milestone is 2.1.0b2, is this bug fixed yet? I am using bzr 2.1.1

It ought to be fixed in 2.1.1. Can you confirm ?

@Madhusudan please test by setting *https_proxy* e.g.
export https_proxy=http://192.168.0.1:8080/
bzr info lp:bzr

lp url lookup requires an HTTPS request, not plain HTTP, and just
setting an HTTP proxy isn't enough.

That said, I expect it will fail as we have just fixed a bug in HTTPS
proxy support in bzr 2.2, which is also present in 2.1, and we
probably need to backport it to 2.1.

Vincent - perhaps you'd be interested in doing that today? Should be a
no-brainer.

-Rob

 bzr --version
Bazaar (bzr) 2.1.1
  Python interpreter: /usr/bin/python 2.6.5
  Python standard library: /usr/lib/python2.6
  Platform: Linux-2.6.32-22-generic-pae-i686-with-Ubuntu-10.04-lucid
  bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
  Bazaar configuration: /home/ensonic/.bazaar
  Bazaar log file: /home/ensonic/.bzr.log

still nothing fixed here.
bzr launchpad-login <username>
just hangs and so does
bzr co lp:<project>

This is getting no #1 bug of shame, seriously.

Stefan, what does

env |grep -i proxy

show you?

If you run

  strace -e trace=network bzr launchpad-login

what happens?

Please see the comment previous to yours asking for details about how
you are reproducing, and stating that we have fixed a similar/same
issue in 2.2.

If you want to gather the requested data, we can compare and see if
its the same.

$ env |grep -i proxy
http_proxy=http://xxx.yyy.zzz.com:8080

$ strace -e trace=network bzr launchpad-login ensonic
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.89.222")}, 16) = -1 EINPROGRESS (Operation now in progress)
getsockopt(4, SOL_SOCKET, SO_ERROR, [110], [4]) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("91.189.89.223")}, 16) = -1 EINPROGRESS (Operation now in progress)
getsockopt(4, SOL_SOCKET, SO_ERROR, [110], [4]) = 0
bzr: ERROR: Connection error: curl connection error (couldn't connect to host)
on https://launchpad.net/~ensonic/%2Bsshkeys

where "91.189.89.223" is "launchpad-net.nutmeg.canonical.com"

@Stefan: you need to use https_proxy as mentioned in https://bugs.edge.launchpad.net/bzr/+bug/186920/comments/50 (the 'comment previous to yours' as Robert mentioned).

> $ env |grep -i proxy
> http_proxy=http://xxx.yyy.zzz.com:8080

> $ strace -e trace=network bzr launchpad-login ensonic
...
> bzr: ERROR: Connection error: curl connection error (couldn't connect to host)
> on https://launchpad.net/~ensonic/%2Bsshkeys

> where "91.189.89.223" is "launchpad-net.nutmeg.canonical.com"

Note the 'on httpS'.

Oh my, now I can login at least. Please be nice to people and tell them or even better try http_proxy as well. The checkout failed. I am attaching the log and hope that its related to this bug.

Hi Stefan,

This is <https://bugs.edge.launchpad.net/bzr/+bug/558343> which is fixed in bzr 2.2 but not (yet) in the 2.1 series. As an immediate fix I would suggest you install 2.2b from <https://edge.launchpad.net/~bzr-nightly-ppa/+archive/ppa>.

I added <https://code.edge.launchpad.net/~mbp/bzr/doc/+merge/29244>, please tell me what you think.

I have tried Bazaar (bzr) 2.2.0dev1 from the PPA but still get a crash. The traceback looks shorter though.

Hello,
this problem still persists:

D:\>set HTTP_PROXY=http://155.335.1.4:1234

D:\>set HTTPS_PROXY=https://155.335.1.4:1234

D:\>bzr co nosmart+http://code.launchpad.net/~flavour/sahana-eden/trunk
bzr: ERROR: Connection error: while sending GET http://code.launchpad.net/~flavour/sahana-eden/trunk/.bzr/branch-format: (10060, 'Operation timed out')

>bzr version
Bazaar (bzr) 2.1.1
  Python interpreter: C:\Programme\Bazaar\python25.dll 2.5.4
  Python standard library: C:\Programme\Bazaar\lib\library.zip
  Platform: Windows-XP-5.1.2600-SP3
  bzrlib: C:\Programme\Bazaar\lib\library.zip\bzrlib

Any help is appreciated.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim wrote:
> Hello,
> this problem still persists:
>
> D:\>set HTTP_PROXY=http://155.335.1.4:1234
>
> D:\>set HTTPS_PROXY=https://155.335.1.4:1234
>
> D:\>bzr co nosmart+http://code.launchpad.net/~flavour/sahana-eden/trunk
> bzr: ERROR: Connection error: while sending GET http://code.launchpad.net/~flavour/sahana-eden/trunk/.bzr/branch-format: (10060, 'Operation timed out')
>
>
>> bzr version
> Bazaar (bzr) 2.1.1
> Python interpreter: C:\Programme\Bazaar\python25.dll 2.5.4
> Python standard library: C:\Programme\Bazaar\lib\library.zip
> Platform: Windows-XP-5.1.2600-SP3
> bzrlib: C:\Programme\Bazaar\lib\library.zip\bzrlib
>
> Any help is appreciated.
>
> ** Changed in: bzr
> Status: Fix Released => Confirmed
>

Can you try:

bzr co -Dhttp \
  nosmart+http://code.launchpad.net/~flavour/sahana-eden/trunk

And then attach the My Documents\.bzr.log file (or part of it.) You may
want to delete the file before running that, so that you only have the
new results in it.

I think we also check the Internet Explorer proxy settings.

I'm sure that the core of this bug is actually fixed, so I'm going to
leave it marked that way. But you are welcome to open a new bug for the
details of your case.

John
=:->

 status fixreleased
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxO9kIACgkQJdeBCYSNAAOugwCfTDGlfTg1BZnyqM0zmLZ6MEAR
ar8An1horFU6gHoqTkkCcpChvx/UVsjl
=s1hk
-----END PGP SIGNATURE-----

Hello,
now it finally works when I issue:

SET HTTP_PROXY=proxy.example.com:8000
SET HTTPS_PROXY=proxy.example.com:8000
bzr co -Dhttp nosmart+http://code.launchpad.net/~flavour/sahana-eden/trunk

on the Windows command line.

Should be documented like this.

I still regard this nosmart and etc. stuff as overhead.

Why not bzr co lp:mycode?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim wrote:
> Hello,
> now it finally works when I issue:
>
> SET HTTP_PROXY=proxy.example.com:8000
> SET HTTPS_PROXY=proxy.example.com:8000
> bzr co -Dhttp nosmart+http://code.launchpad.net/~flavour/sahana-eden/trunk
>
> on the Windows command line.
>
> Should be documented like this.
>
> I still regard this nosmart and etc. stuff as overhead.
>
> Why not bzr co lp:mycode?
>

My guess is that your proxy is refusing a POST request, which is sort of
silly. (The final target would refuse it, and we would fall back
gracefully to the regular code paths.)

Also, I'm not sure what version of bzr you are using, but bzr 2.2
introduced support for using lp: behind proxies. (It is a long-standing
bug that the xmlrpc library that is built into python doesn't support
http proxies.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxlmOIACgkQJdeBCYSNAAMbHgCgxJrb5JaiBEnChpkQnu5a4mK2
C38AoKiIePIkGz6KA6AwV1B9FcjfbddK
=5LF1
-----END PGP SIGNATURE-----

John A Meinel wrote:
   It is a long-standing bug that the xmlrpc library that is built into python doesn't support http proxies.

According to the Python documentation the xmlrpc library *does* support proxies.
However, some extra effort is required.
http://docs.python.org/library/xmlrpclib.html
Section 20.23.9 contains an example of proxy usage.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/20/2010 6:12 AM, shypike wrote:
> John A Meinel wrote:
> It is a long-standing bug that the xmlrpc library that is built into python doesn't support http proxies.
>
> According to the Python documentation the xmlrpc library *does* support proxies.
> However, some extra effort is required.
> http://docs.python.org/library/xmlrpclib.html
> Section 20.23.9 contains an example of proxy usage.
>

ServerProxy doesn't look to be the same thing as an HTTP Proxy.

ServerProxy is a proxy-object that sends its calls to a remote machine.
(so you call obj.foo() and it actually sends an XMLRPC request, it is
'proxying' for the rpc)

An HTTP Proxy is about sending the HTTP request to this machine, telling
it you really want the data from *that* machine.

Very different things.

There is the statement about:
 class ProxiedTransport(xmlrpclib.Transport):

Which is basically what we did. Except after doing it, python2.7 changed
the internals a bit, and broke our custom Transport implementation.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxyk4IACgkQJdeBCYSNAAPG8QCgz6rXGh0/EdQWEh2BhpoY9DDg
+UkAn3dYE9mEL7Yr4zZoZc0l5Z/X/NZ8
=I4gY
-----END PGP SIGNATURE-----

Tim is doing some work towards resolving lp: urls purely within the
ssh server so that they work better with private branches; when that
is all complete we may be able to do away with xmlrpc which would be
nice.