Andy Piper writes: Heresy!!

Kyle> Andy Piper writes: It's in PROBLEMS, C-s "IPv6". As pointed out, it happens in getaddrinfo(), behind the scenes, because IPv6 apparently requires a canonical name for localhost, and that you try to get IPv6 info before falling back to IPv4. You can work around it by forcing an IPv4 address for the display, either with DISPLAY or -d. There's a patch there for permanently forcing IPv4 behavior, if you want to do it in your own copy. Kyle> Me too. I think the DNS lookups at startup should go away. Yeah, I promised Karl Kleinpaste I'd make a configure option. (Martin vetoed removing it.) Mea culpa maxima, not done yet. I apologize for the delay, but I do not understand this stuff well (IPv6 or configure). A patch to configure.in to make the patch in PROBLEMS an option would be gratefully accepted. A report on a test that it works would be nice, too. Is it the curmudgeonly consensus that nuking it is not a violation of standards? If so, I'll go ahead and do it (by defaulting the configure option to "defeat IPv6 canonicalization"). This is enough of a pain in the ass for enough people that I'll delay 21.4.4 (currently scheduled for Monday) to wait on your reply. There will be a configure option in 21.4.4, the only question is who's going to write it (it will take me a while), and what is the default. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Andy Piper writes: when i ws using RH 7.1 i was getting lockups and stuff i recompiled without esd (--with-sound=none actually) and it was good from then on :) -- ------------------------------------------------------------------------- Peter Brown Web Programmer/Sys Admin/Apache Admin Education Development Web peter(a)edw.com.au www.edw.com.au rendhalver(a)users.sourceforge.net -------------------------------------------------------------------------

Andy> Seems like you should turn it round the other way - how many Andy> people would be affected by the (so called) wrong behaviour? A few people, mostly in Japan, today. Far more, probably mostly in Japan :-), in the near future. Andy> Not many I imagine. Whereas the status quo has annoyed many. Yeah, it annoyed me, too. So I fixed my system. I think we should encourage others to do that where possible, rather than defaulting to not handling IPv6 at all. I think there probably are problems, like autodialing on attempts to use the network, that will be hard to configure around. But the CNAME hang on startup is not one; you simply need to not configure your nameservers until you have a working net connection. Every DHCP client does that already, and it should be reasonably easy to configure PPP that way too. Glynn> Note that these don't require any explicit support from the Glynn> application; XOpenDisplay(NULL) and XOpenDisplay(<arbitrary Glynn> string>) will do the right thing automatically. I can't wait until X11 gets getaddrinfo'ized then. Should be a spectacular flamefest. :-) Glynn> Maybe the canonicalisation code should go, and the value of Glynn> $DISPLAY just used as-is. Anything else is bound to get it Glynn> wrong in some cases. Seems likely. Do you have any examples? I wonder why they did it in the first place, though. However, we also do canonicalization in sysdep.c (init_system_name). Why that doesn't bite anyone, I don't know. I'm going to turn IPv6 off there, too, if --with-ipv6-lookup=no. Removing canonicalization entirely is something that isn't going to happen in 21.4.4, and probably won't happen soon thereafter, either. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Stephen J. Turnbull wrote: The call to getaddrinfo() in init_system_name is conditional upon: if (!strchr (hostname, '.')) On my system (RH6.2) the result is that getaddrinfo() isn't called when running XEmacs on a tty. Brief testing suggests that failure to canonicalise correctly doesn't seem to have any really negative consequences. E.g. (frame-device (make-frame-on-display ":0")) #<x-device on ":0.0" 0x23b5> (frame-device (make-frame-on-display "localhost:0")) #<x-device on ":0.0" 0x23b5> (frame-device (make-frame-on-display "127.0.0.1:0")) #<x-device on ":0.0" 0x23b5> (frame-device (make-frame-on-display "tcp/localhost:0")) #<x-device on "tcp/localhost:0.0" 0x11dd0> Even though this is wrong, I haven't found any user-level problems as a result. Actually, the fact that the canonicalisation code fails to handle the last case at least provides a way to force a connection to "localhost:0" (which isn't the same thing as ":0"). -- Glynn Clements <glynn.clements(a)virgin.net&gt;

Glynn Clements <glynn.clements(a)virgin.net&gt; writes: Well, you can start, say, xterm on a net-enabled disconnected machine, so it's obviously possible to do X without doing the DNS resolving thing. (And, yes, I've been bitten by this behavior before while setting up machines and having to resort to (*shiver*) the eVIl editor to edit files.) -- Lars Magne Ingebrigtsen

Andy Piper wrote: Note that this isn't strictly about DNS lookups in general; simply calling XOpenDisplay(NULL) may result in a DNS lookup, depending upon what DISPLAY is set to and how the system's resolver is configured. AFAICT, the problem is that XEmacs tries to canonicalise the host part of a display specification in order to support multiple displays in the way it does, e.g. so that it can perform meaningful equality tests between devices. Having said that, I don't really see why there would be a problem if XEmacs thinks that two frames are on different devices when they're not. -- Glynn Clements <glynn.clements(a)virgin.net&gt;

At 02:34 PM 7/20/01 -0400, Craig Lanning wrote: For me this would require a screwdriver and a soldering iron. I'm willing to bet that would invalidate my warranty. andy

At 08:40 AM 7/23/01 -0400, Craig Lanning wrote: Thanks for the suggestion anyway :) andy