Bugs in current zeroconf

[Matt Mackall]

On Sun, 2008-10-12 at 21:06 -0700, Jeremy Fitzhardinge wrote:
> I just updated to mainline a4769dec7773 and tried zeroconf again.
> 
> I'm still seeing:
> 
> Traceback (most recent call last):
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 862, in run
>     self.readers[socket].handle_read()
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 907, in handle_read
>     msg = DNSIncoming(data)
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 469, in __init__
>     self.readQuestions()
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 495, in readQuestions
>     question = DNSQuestion(name, info[0], info[1])
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 262, in __init__
>     raise NonLocalNameException
> NonLocalNameException
> 
> 
> exceptions when I run avahi-discover, though it seems to be a different 
> problem.
> 
> The name in question is "_services._dns-sd._udp.0pointer.de.", which 
> does seem reasonable; zeroconf supports the notion of non-local browable 
> domains, so there's no particular reason why a name will always end with 
> .local.  I'm not sure why the hg serve code is seeing this; I guess 
> avahi-discover is broadcasting this or something.  Perhaps the quick fix 
> is to simply eat this exception.

Probably. It's not clear what the maintenance level of Zeroconf.py is
but maybe we can get this fixed upstream. The current copy is pristine
as grabbed from somewhere at Canonical a few months ago, so it's
possible it's already fixed.

Or not. It seems it hasn't been touched since Feb, 2007. 

> Anyway, aside from that it seems to work OK.
> 
> I noticed that if I try to start "hg serve" twice on the one machine, 
> the second fails because port 8000 is busy.  When zeroconf is enabled, 
> it would seem reasonable for it to choose a random port, because its 
> discoverable either way (or at least have an option to use a 
> kernel-assigned port).

We should probably do the latter. Most of the world is not quite ready
for zeroconf yet. Unfortunately, the part of the extensions that figures
out what port we're listening on is a complete hack..

> Hm, sometimes I get this from "hg paths".  It seems to be a race; 
> sometimes it appears, other times not.
> 
> : abulafia:pts/5; hg paths
> zc-linux = http://192.168.0.226:8000/linux
> Exception in thread Thread-3 (most likely raised during interpreter shutdown):
> Traceback (most recent call last):
>   File "/usr/lib64/python2.5/threading.py", line 486, in __bootstrap_inner
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 1002, in run
>   File "/usr/lib64/python2.5/site-packages/hgext/zeroconf/Zeroconf.py", line 1296, in wait
>   File "/usr/lib64/python2.5/threading.py", line 240, in wait
> <type 'exceptions.ValueError'>: list.remove(x): x not in list
> Unhandled exception in thread started by 
> Error in sys.excepthook:
> 
> Original exception was:
> 
> 	J
-- 
Mathematics is the supreme nostalgia of our time.