Re: NAT tutorial?
Hi Jason, This is really a -questions question, not a -current question. On Wed, 26 Apr 2000, Jason Mitchell wrote: Does anyone know of a tutorial or more detailed instructions on how to use NAT and IP masquerading in 3.4? "IP masquerading" is what the linux people call NAT. They are the same thing. I can configure it so that it is running and working with IP firewall within the box no problem, but as far as dolling out local IPs to the rest of the workstations Dynamic allocation of IP addresses to workstations doesn't have much to do with NAT -- try hunting for information on dhcp or bootp. There are two DHCP servers in the ports tree (net/isc-dhcp2 and net/wide-dhcp). If I'm barking up the wrong tree, and you're actually talking about static NAT maps, then see natd(8). or even building a natd.conf file, I'm lost. You have read natd(8), right? The closest I've found is the tutorial at http://freebsd.peon.net, but that doesn't quite cover enough. Try describing exactly what you're trying to achieve, rather than guessing at components that might provide solutions -- then post the question to the -questions list. There are lots of helpful people there that will give you ideas. Oh -- also, check out Dan's list of NAT articles at http://www.freebsddiary.org/topics.php3#nat Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0-RELEASE boot.flp fails to boot on K6/2
Problem report booting 4.0-RELEASE follows. /boot.config: -P Keyboard: yes BTX loader 1.00 BTX version is 1.01 Console: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/56256kB available memory FreeBSD/i386 bootstrap loader, Revision 0.7 ([EMAIL PROTECTED], Wed Mar 15 01:23:43 GMT 2000) | Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel text=0x1d56fe data=0x2f4ca0+0x1a718 zf_read: fill error elf_loadexec: archsw.readin failed can't load 'kernel' no bootable kernel \ Type '?' for a list of commands, 'help' for more detailed help. ok What does this mean? If this is a -questions question, then please feel free to flame me privately (just thought it sounded -currentish). If there are any useful diags I can type, let me know. Hardware is 350MHz K6/2, generic-looking Asus motherboard with integrated video and audio, no-name PCI 10baseT ethernet adapter, floppy, single 20G IDE disk, 64M RAM. No other peripherals. Have tried different floppies. Recent OpenBSD snapshot floppy works just fine, by way of crude hardware sanity check. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
On Tue, Mar 21, 2000 at 07:52:18AM +0100, Thierry.herbelot wrote: Joe Abley wrote: Problem report booting 4.0-RELEASE follows. I had the exact same error message trying to boot from a floppy where I had tried to dd the full boot.flp (2,8 Megs is just too much for a normal floppy), instead of kern.flp (and dd does not give error messages ..) Oh, how hideously embarassing. Thank you, Thierry, and please excuse me as I shoot myself in the head. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Mon, Jan 24, 2000 at 02:17:54PM +0100, Brad Knowles wrote: At 11:34 PM +1300 2000/1/22, Joe Abley wrote: This should give you a relative performance metric between the servers you measured, hopefully with local network performance variations cancelled out by the fact that all tests are run around the same time. This is a really cool idea! Are you going to be writing some code to do this for us? ;-) Can do if people think it is worthwhile. Could be done quite easily in a wrapper to cvsup, I would thought. It _will_ need a static test set to be installed at each of the cvsup mirrors to be useful though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 06:20:38PM -0500, Ben Rosengart wrote: Anyway, if multi CNAME is no good then do: cvsup IN A198.104.92.71 ; cvsup1.freebsd.org cvsup IN A205.149.189.91 ; cvsup2.freebsd.org ... and so on This is legal, is it? Not only is it legal, but I believe BIND will return all the A records to any query, and will rotate them. The problem with this is that any time a cvsup server operator decides to renumber their mirror, they need to inform the soa for freebsd.org (and factor in the freebsd.org TTLs to manage the change). In practice this will not work, and will cause 1/n cvsup attempts to fail after a machine has been renumbered until TTLs expire. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please help spread the CVSup mirror load more evenly
On Fri, Jan 21, 2000 at 05:23:17PM -0800, Rodney W. Grimes wrote: You don't even need to modify the protocol. Just write a small tcp program that times the 3 way handshake on open to all the servers, take the one with the sortest time and spit that out for the user to stuff in his cvsupfile. 15 lines of perl should be more than enough :-) Unfortunately, timing a three-way handshake would give you a very coarse measurement of the packet loss, jitter and bandwidth between the client and server. It would give you a better measurement of the latency, but still (statistically speaking) quite a poor one. Cvsup sessions tend to be long-lived, which means other factors can have much more dramatic effect on session performance: + packet loss + path bandwidth + optimisation of TCP stacks at either end to the round-trip latency of the network path (RFC1323 and SACK support, for example) The only effective way to _really_ measure the cumulative effect of all these is to model a representative cvsup session to multiple servers, and compare performance. This is pretty much what John was recommending in the first place by "why not try a different server every once in a while" :) You could automate this like this (and no doubt in other ways): + install a small, representatively-sized but junk collection on every cvsup mirror server + every week (say) pull the entire junk collection down from scratch from a selection of likely servers, and store the relative time taken to do so. This should give you a relative performance metric between the servers you measured, hopefully with local network performance variations cancelled out by the fact that all tests are run around the same time. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Odd TCP glitches in new currents
On Tue, Dec 21, 1999 at 01:23:05PM -0800, Matthew Dillon wrote: I just rebooted both machines and it didn't fix the problem. I did a packet trace on both boxes and there does indeed appear to be packet loss. Sorry if this is stating the obvious, but I've seen more than one clueful person bitten by this: hard-wire your duplex setting on your machine and also on the switch Even if the switch and NIC appear to auto-negotiate a sensible duplex setting, I have seen many cases where they will forget for no apparent reason, usually in the middle of the night just after you have stepped onto a plane to fly to a different country. If one end thinks it is full-duplex and the other end thinks it is half, then late collisions can occur which will not result in MAC-layer retransmissions from the full-duplex-thinking station -- hence packet loss. Joe (possibly #2 in a series of red herrings :) -- Ua lawa küpono ka hakahaka pä o këia pä malule To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** location of sendmail.cf changed
On Sun, Dec 19, 1999 at 12:05:43PM -0800, David O'Brien wrote: On your next CVSup, /usr/sbin/sendmail will look for sendmail.cf in /etc/mail/ , not /etc/. Then change was made because the current offical Sendmail Inc. version uses /var/mail/ and when we upgrade our repository to that version, we s/var/etc/ presunably. Joe -- Ua lawa küpono ka hakahaka pä o këia pä malule To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People getting automatically unsub'ed from -arch
On Mon, Oct 11, 1999 at 11:21:52AM -0700, Sean Eric Fagan wrote: In article [EMAIL PROTECTED] you write: only one comment. i remove people from the lists whenever their email bounces. the threshhold is approximately 30 messages in a 24 hour period. mail may bounce due to DNS problems, mail box full, MTA misconfiguration. i also remove people that send vacation messages to the list. oh, and spammers. My mail _has not bounced_. And yet I have been removed. You have no way of knowing whether inbound mail to you has bounced, or not. Why are you so adamant that mail has not bounced? This discussion is a little one-sided, and is getting personal for some reason. Jmb: on behalf of the many people who have _not_ experienced problems (and those who have, but are not blaming you for them), thanks for your efforts. To those who _have_ experienced problems, remember this is a volunteer effort. Would you flame someone on a public list if you found a bug in the code they had contributed? Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
On Wed, Sep 29, 1999 at 11:05:49PM +1200, Joe Abley wrote: On Wed, Sep 29, 1999 at 12:02:09PM +0200, Mark Murray wrote: There is breakage in the new FICL. This fixes it... [awk diff] I remember a long time ago someone asked me to make some modifications to softcore.awk to compress the textual ficl keywords by eliminating double-spaces and newlines, and that kind of thing. Modifications have been made; patch in kern/14087. It produces identical output to the new softcore.pl for my test case of cat sys/boot/ficl/softwords/*.fr People (more) familiar with ficl syntax might like to craft some awkward constructs and check that I'm handling them legally. Note that the script contains one gawk-ism (use of strftime() to include a cosmetic "last update" comment in the generated softcore.c). In my opinion, this should be eliminated -- it seems like a needless GNUism to me. gawk(1) says that the use of the character class [[:space:]] is consistent with POSIX 1003.2 (and I have no reason to disbelieve it). However, [[:space:]] also seems to be frequently misunderstood by other common awks, so it might also be considered a candidate for removal in the interests of portability. The alternative is a bit messier, though, and not necessarily portable across different locales. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FICL breakage...
On Wed, Sep 29, 1999 at 12:02:09PM +0200, Mark Murray wrote: There is breakage in the new FICL. This fixes it... [awk diff] I remember a long time ago someone asked me to make some modifications to softcore.awk to compress the textual ficl keywords by eliminating double-spaces and newlines, and that kind of thing. I don't believe I ever got around to doing it at the time, but I'd be more than happy to implement the changes now if (a) someone could remind me what the compression logic should be, and (b) someone could confirm that these changes haven't already been made :) If I sound vague, it's because I am without a FreeBSD box right now, and do not have an easy way to check the source tree. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: On hub.freebsd.org refusing to talk to dialups
Mark Murray [EMAIL PROTECTED] writes: [hub.freebsd.org now blocking IP adresses on the DUL] If you use your ISP's mailer as a "smarthost", you will avoid this problem. Thos of us in the anti-spam community think thsat this is a Good Thing. One of us, at least, evidently. How much mail does the use of the MAPS DUL reject? How much of that do you think is worth rejecting? Serious questions; just interested. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
coda in STABLE
Hi, From /sys/coda/coda.h on 3.2-STABLE, it looks like the version in the tree is 3.1. At http://www.coda.cs.cmu.edu/download.html#gpl_notice it is mentioned that version 5 clients and servers are not backwards compatible with version 4 (and by inference, previous versions, hence my first paragraph). Earlier on the same page, -CURRENT is mentioned, but not -STABLE. Does -CURRENT have different kernel hooks for coda than -STABLE? If so, does anybody know if work is progressing to back-port the changes? If anybody has any general experience of coda on FreeBSD, and feels like sharing it, I'm keen to listen :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMTP to dynamic ip's
On Thu, Jun 03, 1999 at 03:51:07AM +, Mike Tancsa wrote: On 2 Jun 1999 17:20:38 -0400, in sentex.lists.freebsd.current you wrote: [mailbagging] Do you make checks to see that the person does not login twice with the same account name ? Yes. Simultaneous logins are prohibited -- instead, users get to create multiple userids on a single account, and those individual userids can each connect at the same time. Also, what happens if one user who has a big queue, gets killed mid transit, than another user comes on with the same IP. Do you have a facility for stopping the queue ? We rely partially on TCP to sort this out for us (i.e. on the guess the sequence number game being hard to play), but also make checks during the queue run using the same RPC service to find out whether the user has gone away. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Tue, Jun 01, 1999 at 02:16:55PM -0600, Nate Williams wrote: this is less and less of a problem because if you lose your link on PPP you are liable to get a differetn IP address on your redial. Not true. Only if you're using a dynamic IP address setup. Most business connections have a static connection, so they'll end up with the same IP address everytime. I would take issue with that. All of the regional registries require extremely good justification for allocating static IP addresses to transient network connections. This might be something that older, established providers are able to do (since they were delegated way too many addresses in the good ol' days) but it isn't an option for (m)any ISPs younger than three or four years. When it comes down to it, there is very little justification for a static address. The one I most commonly hear is so we can do SMTP mail delivery to the customer, but even that doesn't mandate use of static addressing -- we support SMTP mail delivery (we call it mailbagging for some reason) to dynamically-addressed dial-up clients, and it works just fine. Other times the reason is so the customer can carry on downloading after the line dropped to which the answer is maintain your access servers properly and this won't happen. Anyway, this is off-topic. Back to your scheduled programming. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SMTP to dynamic ip's
On Wed, Jun 02, 1999 at 11:03:05PM +0200, Leif Neland wrote: When it comes down to it, there is very little justification for a static address. The one I most commonly hear is so we can do SMTP mail delivery to the customer, but even that doesn't mandate use of static addressing -- we support SMTP mail delivery (we call it mailbagging for some reason) to dynamically-addressed dial-up clients, and it works just fine. Would you care to explain how? Very interested. Inbound mail to mailbagging customers is not queued normally by sendmail, but is delivered through a local-like mailer to a separate per-user queue directory. When users authenticate, radius uses a back-end RPC service to register users as connected from a particular IP address. This IP address is dynamically assigned. When we receive a stop record from radius (indicating that the user has disconnected) a similar RPC removes the record. Inserting this record triggers an SMTP delivery attempt after a few seconds' delay. The per-user queue directory (the mailbag) is emptied as messages are sent to the connected user. A periodic job (every ten minutes, I think, to give people a chance to idle out their automatically-dialled connection) checks for connected mailbagging customers for whom a queue run is not in progress. For each of these users, the mailbag is delivered by SMTP to the registered, connected address. The main thing to be careful on all this is to do paranoid checking at every stage to try to ensure that the user hasn't disconnected and been replaced by someone else (who should not get their mail). Incidentally, ETRN is still accepted (some people like to do it) but it doesn't do anything. We rely on mail being delivered regularly enough for ETRN not to be necessary. Calling the RPCs is very cheap, and we have experienced no load issues with scaling this to large numbers of customers. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Pcmcia support
On Sat, May 29, 1999 at 11:59:35PM -0700, k...@lyris.com wrote: That is the kind of response I like. I don't appreciate being flamed for a reasonable question about something that is not documented in an obvious place. Check the archives for freebsd-current, freebsd-hackers and freebsd-mobile. They're easy to find from www.freebsd.org, and contain numerous extensive threads with all the details. If you _do_ look for these, you will easily see how (a) the apparently hostile responses you got were, in fact, quite mild and (b) why nobody is eager to start another discussion on the subject. I think the correct way of asking why doesn't someone roll PAO into current is I have taken aspect X of APM/PCMCIA/whatever support from PAO, and tidied it up for CURRENT -- the patch is attached, please test. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
ftp.nz.freebsd.org
Hi, CLEAR is operating a pretty full mirror of ftp.freebsd.org:/pub/FreeBSD/ at ftp.clear.net.nz:/pub/FreeBSD/. Dan Langille has kindly made ftp.nz.freebsd.org a CNAME to ftp.clear.net.nz to make this easier to find. Just thought I'd mention it -- I haven't done a clean install for a long time, so I don't know whether ftp.nz.freebsd.org is given explicitly as an option for network installs. But if it isn't, it might be good to put it in. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
has the 3.2 branch happened?
(he asked :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SPAM
On Mon, May 10, 1999 at 10:29:16PM +0200, Mark Murray wrote: Garrett Wollman wrote: On Mon, 10 May 1999 22:14:56 +0200, Mark Murray m...@grondar.za said: Have you ever considered only allowing list members to post, or are there difficulties that make this impossible? Yes, there are. Content-free answer. Please elaborate? You might like to check the mailing list archives. This has been discussed to death many, many times. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Our routed - Vern says it's old and buggy.
On Wed, Apr 28, 1999 at 02:34:51PM -0400, Chuck Robey wrote: And you didn't know that the RIP spec is even older, and was publicly available via an RFC (the same as OSPF?) But, of course, RIP sucks in many well-known ways. I can't quite figure why they stuck the word open in there, because it couldn't possibly be more open than RIP. I thought the open referred to the algorithm -- i.e. shortest open path first would be a synonym. I have no reason to think this, though. I could well be wrong, and probably am. OSPF has been around for a long time. But RIP is older, and was the first routing scheme. X.25 is older than IP, which clearly makes it better in all circumstances. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Our routed - Vern says it's old and buggy.
On Wed, Apr 28, 1999 at 09:36:09AM +0930, Kris Kennaway wrote: On Tue, 27 Apr 1999, Garrett Wollman wrote: Most importantly: - Recent values of GateD are distributed under a very unfriendly license. And the last free version is hideous in the extreme. There's also zebra, in ports (as someone pointed out on -net the other day), which seems to be GPL'ed. I haven't tried either of the two except to poke around briefly in the code.. It's also probably worth mentioning that Zebra is being developed in an extremely active and proactive fashion, and the principal developers are extremely open to contributed feedback and code. Zebra's BGP seems pretty good and stable right now; the OSPF work has apparently received a lot of attention recently, although I haven't tried it. One of the nice things about zebra is the way that each routing protocol is neatly compartmentalised into a separate daemon. This makes it simple and easy to maintain individual protocols (or add new ones) without jeopardising others. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Consistent errors making buildworld
On Fri, Apr 16, 1999 at 09:45:29PM -0400, Luoqi Chen wrote: Do you have an empty /usr/X11R6/include? Ah, yes I do. Thanks for that :) The Makefile assumes you have the header files if the directory /usr/X11R6/include is present and tries to build the X version of doscmd. This assumption may not be true though. I'll change the Makefile to check for /usr/X11R6/include/X11/X.h instead. By the way, X headers only take 4M disk space, you might want to consider installing them. Hav done. I'm a little confused as to why they weren't there already, actually, as I was certain I had compiled and installed XFree86 from the port... Ah well :) Whatever. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Consistent errors making buildworld
Hi, I've been trying to make buildworld on an aged Compaq DX2 (using newly- supped CURRENT source) for about a week now, and (modulo the few egcs-looking failures early on) I am now stuck with compilation failures in doscmd. I have completely removed /usr/obj/* prior to starting, each time, and the last time I tried I also wiped /usr/src/* and re-supped. Same error (below) [note on my machine, /usr/src and /usr/obj are symlinks to /var/src and /var/obj, respectively). I have also appended /etc/make.conf to this message. Just out of interest, why is a make buildworld trying to include X headers? Machine was previously running CURRENT (supped and compiled quite a while before the egcs import). It takes about three days to make buildworld, hence my delay in reporting this... However, I see loads of other people successfully making world in -current, so I assume it must be something local. Any pointers appreciated. [last few log lines from make buildworld follows] cc -O -pipe -I. -I/usr/X11R6/include -DDISASSEMBLER -I/usr/obj/var/src/tmp/usr/include -c /var/src/usr.bin/doscmd/trap.c cc -O -pipe -I. -I/usr/X11R6/include -DDISASSEMBLER -I/usr/obj/var/src/tmp/usr/include -c /var/src/usr.bin/doscmd/tty.c /var/src/usr.bin/doscmd/tty.c:36: X11/Xlib.h: No such file or directory /var/src/usr.bin/doscmd/tty.c:37: X11/Xutil.h: No such file or directory /var/src/usr.bin/doscmd/tty.c:38: X11/keysym.h: No such file or directory /var/src/usr.bin/doscmd/tty.c:77: parse error before `*' /var/src/usr.bin/doscmd/tty.c:77: warning: data definition has no type or storage class /var/src/usr.bin/doscmd/tty.c:78: parse error before `win' /var/src/usr.bin/doscmd/tty.c:78: warning: data definition has no type or storage class /var/src/usr.bin/doscmd/tty.c:79: parse error before `*' /var/src/usr.bin/doscmd/tty.c:79: warning: data definition has no type or storage class /var/src/usr.bin/doscmd/tty.c:103: parse error before `gc' /var/src/usr.bin/doscmd/tty.c:103: warning: data definition has no type or storage class /var/src/usr.bin/doscmd/tty.c:104: parse error before `cgc' /var/src/usr.bin/doscmd/tty.c:104: warning: data definition has no type or storage class /var/src/usr.bin/doscmd/tty.c: In function `setgc': /var/src/usr.bin/doscmd/tty.c:380: `XGCValues' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:380: (Each undeclared identifier is reported only once /var/src/usr.bin/doscmd/tty.c:380: for each function it appears in.) /var/src/usr.bin/doscmd/tty.c:380: parse error before `v' /var/src/usr.bin/doscmd/tty.c:382: `v' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:393: `GCForeground' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:393: `GCBackground' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c: In function `video_update': /var/src/usr.bin/doscmd/tty.c:409: `XGCValues' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:409: parse error before `v' /var/src/usr.bin/doscmd/tty.c:484: `v' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:487: `GXxor' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:490: `GXcopy' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:492: `GCForeground' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:492: `GCFunction' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c: In function `debug_event': /var/src/usr.bin/doscmd/tty.c:737: warning: passing arg 1 of `dump_regs' from incompatible pointer type /var/src/usr.bin/doscmd/tty.c: In function `video_async_event': /var/src/usr.bin/doscmd/tty.c:986: `XEvent' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:986: parse error before `ev' /var/src/usr.bin/doscmd/tty.c:994: `ev' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c: At top level: /var/src/usr.bin/doscmd/tty.c:1126: parse error before `*' /var/src/usr.bin/doscmd/tty.c: In function `video_event': /var/src/usr.bin/doscmd/tty.c:1128: `ev' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1129: `MotionNotify' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1130: `XMotionEvent' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1130: `me' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1130: parse error before `)' /var/src/usr.bin/doscmd/tty.c:1144: `ButtonRelease' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1145: `XButtonEvent' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1145: `be' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1145: parse error before `)' /var/src/usr.bin/doscmd/tty.c:1162: `ButtonPress' undeclared (first use in this function) /var/src/usr.bin/doscmd/tty.c:1163: parse error before `)' /var/src/usr.bin/doscmd/tty.c:1184: `NoExpose' undeclared (first use in
Re: ATTENTION PLEASE: g77 in base system.
On Fri, Apr 09, 1999 at 03:16:41AM +0200, Dag-Erling Smorgrav wrote: David O'Brien obr...@nuxi.com writes: I've only heard back from 4 folks about adding EGCS's g77 to the base system -- all 4 said yes. Unless I get more feedback, I will add g77 to the base system this weekend. I beg your pardon? You're adding g77 to the system because you know of four people who would find it useful? Where's the logic in that? If you do add it to the base system, make it optional. I don't care if it defaults to on, as long as I have the option to turn it off. Oh good lord, not again. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
TI PCI-1220 cardbus/PCI bridge
Is there any work in progress on sys/pccard/*? I'm using a Gateway Solo for the week which has the PCI/cardbus bridge mentioned in the title, and I have been getting spurious results with 4.0-CURRENT (supped a couple of days ago). If there are some patches in test which might enhance support for this laptop, pointers would be appreciated. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: adding DHCP client to src/contrib/
On Mon, Feb 08, 1999 at 02:28:20PM -0800, David O'Brien wrote: I am planning on adding the Wide-DHCP client to src/contrib/ and src/sbin/ in a few days. I have it bmaked and ready go to. I have choosen the WIDE client because it is much smaller space-wise than the ISC client and its configuration is simplier. The plan is to make a boot floppy / boot CDROM with a DHCP client on it. Content-Type: text/applause Yaay! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Even more interesting NFS problems..
I've been using amd on bleeding-edge current for the past year or so with
no problems - the servers in my case are Solaris 2.5.1 boxes.
I remember becoming extremely confused when I configured my first amd map
file, since there was no coherent documentation to be found at the time, but
I ended up with this (and have kept it ever since):
% grep amd /etc/rc.conf
amd_enable=YES # Run amd service with $amd_flags (or NO).
amd_flags=-a /a -c 1800 -k i386 -d clear.net.nz -l syslog /home
/etc/amd.home.map /net /etc/amd.net.map
amd_map_program=NO # Can be set to ypcat -k amd.master
%
% cat /etc/amd.home.map
# auto-mount home directories
/defaults type:=nfs;rfs=/export/${path};rhost:=oms
jableyrhost:=intdev
* opts:=rw,resvport
%
% cat /etc/amd.net.map
# automount /net hierarchies
/defaults opts:=rw,grpid,resvport,nosuid
buddhatype:=link;fs=/
* type:=host;rhost:=${key}
buddha is the local machine; intdev is where my home directory happens to
be (everybody else's is mounted off oms).
Never had a problem with it. Just to confirm that amd is not hideously
broken beyond the point where _some_ people can use it just fine.
Joe
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
