Re: Patch for settrans --help

2011-02-17 Thread olafBuddenhagen
Hi, On Sat, Feb 12, 2011 at 11:01:04AM -0800, Roland McGrath wrote: > --help is not the place to describe everything about the system. Sure, but being *somewhat* more verbose certainly can't hurt... Either way, I assume a patch that adds *only* the "(default)" bit would be uncontroversial? -an

Re: Patch for settrans --help

2011-02-17 Thread Samuel Thibault
olafbuddenha...@gmx.net, le Mon 14 Feb 2011 08:45:42 +0100, a écrit : > On Sat, Feb 12, 2011 at 11:01:04AM -0800, Roland McGrath wrote: > > > --help is not the place to describe everything about the system. > > Sure, but being *somewhat* more verbose certainly can't hurt... > > Either way, I ass

Re: Patch for settrans --help

2011-02-17 Thread olafBuddenhagen
Hi, On Thu, Feb 17, 2011 at 01:50:36AM +0100, Samuel Thibault wrote: > Roland McGrath, le Tue 15 Feb 2011 19:10:34 -0800, a écrit : > > "Start TRANSLATOR and set it as NODE's active translator" might be > > more clear, though perhaps too long. > Maybe simply > > "Start and set NODE's active tra

Re: Patch for settrans --help

2011-02-17 Thread olafBuddenhagen
Hi, On Tue, Feb 15, 2011 at 07:02:46PM +0200, Ognyan Kulev wrote: > Some days ago "(default)" was added for "-p". I think it'd be good if > clarification is added that -a and -p are not mutually exclusive. > Something like ""Set NODE's active translator. Can be combined with > --passive." Indeed

Re: Patch for settrans --help

2011-02-17 Thread olafBuddenhagen
Hi, On Mon, Feb 14, 2011 at 06:00:10PM -0800, Roland McGrath wrote: > Perhaps what would both be appropriate for --help and satisfy the > apparent intent behind your changes, is to add a short paragraph about > what active and passive translators are to the "doc" text after the > \v, so it appear

Re: [Fwd: Questions on isc-dhcp]

2011-02-17 Thread Samuel Thibault
Svante Signell, le Thu 17 Feb 2011 06:52:52 +0100, a écrit : > > > However, I found some trouble with hardware types identified with an > > > integer bigger than 255 (ARPHRD_IEEE802_TR and ARPHRD_FDDI) and I gave > > > up. Leaving them out when compiling for GNU is probably the easiest > > > workar