Various mostly bonjour related fixes
eion at robbmob.com
Mon Dec 12 17:52:41 EST 2011
Oops, 2.10.1 didn't compile on win32 with the new linklocal detection code.
Patchs at http://developer.pidgin.im/ticket/14802 fixes the issue.
On 9 December 2011 01:26, Linus Lüssing <linus.luessing at web.de> wrote:
> Hi Mark, hi Ethan, hi Kevin,
> Thanks for having a glance at these patches.
> On Tue, Nov 29, 2011 at 11:24:20PM -0500, Ethan Blanton wrote:
> > Mark Doliner spake unto us the following wisdom:
> > > On Tue, Nov 29, 2011 at 7:21 PM, Ethan Blanton <elb at pidgin.im> wrote:
> > > > Mark Doliner spake unto us the following wisdom:
> > > >> I guess I'd prefer if we didn't commit these to 2.x.y. Supporting
> > > >> ipv6 for bonjour doesn't seem critical to me.
> > > >
> > > > Please clarify what you mean by "these".
> > >
> > > I guess I meant all of them. And I don't have a strong opinion about
> > > this. I guess I'm mostly saying that _I_ wouldn't have committed them
> > > to 2.x.y. It's probably not worth reverting the changes from 2.x.y.
> > > And I'm not going to stop anyone from committing the remaining patches
> > > to 2.x.y. But we should be EXTREMELY careful not to cause other bugs.
> > I generally agree; however, I can confirm that Bonjour + IPv6 = not
> > good at the moment, and the patches which have already been applied
> > should not affect anything but Bonjour (they are all local to the
> > Bonjour plugin) on IPv6 (they come into play only for IPv6 addresses).
> > The way I see it, we're unlikely to break anything that isn't already
> > broken.
> Yes, those ones are all supposed to be just fixes and should
> address critical issues with bonjour if IPv6 is activated in
> > The remaining patch is a bit of a different story.
> Oki doki. As it's only related to the file transfering in bonjour,
> I guess I can live without it in a 2.10.1 release as long as it
> doesn't take too long for a following release.
> However I'm currently wondering whether other protocols might have
> issues with purple_network_do_listen() / purple_network_listen()
> on some operating issues. At first I thought having read somewhere
> that the order of addresses returned by getaddrinfo() was
> unspecified. Now I searched again and it looks like RFC3484 is
> responsible for the ordering. I couldn't quite figure this out yet
> - does it ensure that ::ffff:0.0.0.0 (mapped IPv4 wildcard) is
> always prefered over ::0 (IPv6 wildcard)?
> If not, wouldn't it be better to change AF_UNSPEC to AF_INET in
> purple_network_listen() until purple_network_do_listen() is doing
> what it is supposed to do?
> > Patch 2 (fix socket listen address) requires a minor version
> > bump, as it adds API.
> Just for clarification (I'm not really familiar with the
> development/release process in pidgin): My impression was
> that in the 2.10.0 API purple_network_listen() was supposed to
> offer both IPv4 and IPv6 connectivity in case of AF_UNSPEC (which
> currently is not the case). Is any change that tries to allow this
> supposed behaviour considered an API change needing a minor
> version bump? When do you consider a behaviour change
> in the API being a fix instead?
> On another note, I would like to remove this Windows XP disclaimer
> in the second patch. It'd probably be the best to create two
> separate sockets for IPv4 and IPv6, right? Which as far as I know
> would require a far more invasive patch instead - or does anyone
> with some better knowledge of the libpurple API have an idea about
> how to achieve this easily?
> > Ethan
> Cheers, Linus
> Devel mailing list
> Devel at pidgin.im
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel