spontanious by-weekly crashes
Hello! An old dual-pentium 100 machine began crashing after I upgraded it to 4.0-STABLE from 3.4-STABLE. I'd just discount it as a hardware problem revealed by some of the new features of the OS, but the last two crashes happened at the time exactly two weeks apart: May 11 00:46:34 murlo /murlo: Copyright (c) 1992-2000 The FreeBSD Project. May 11 00:46:34 murlo /murlo: FreeBSD 4.0-STABLE #1: Mon May 1 08:20:37 EDT 2000 May 11 00:46:35 murlo /murlo: FreeBSD/SMP: Multiprocessor motherboard May 25 00:46:25 murlo /murlo: Copyright (c) 1992-2000 The FreeBSD Project. May 25 00:46:26 murlo /murlo: FreeBSD 4.0-STABLE #1: Mon May 1 08:20:37 EDT 2000 May 25 00:46:26 murlo /murlo: FreeBSD/SMP: Multiprocessor motherboard While I interrogate the user, what it is he was doing with it (mostly it is Applix office, Netscape, Postilion and fetchmail), may be someone can offer an idea describing this weird coincidence... There is nothing in the logs immediately before the reboots... Meanwhile, I'll see what happens in the next two weeks. TIA, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ad0 drivers revisited
> In message <[EMAIL PROTECTED]>, Kent Stewart writes: > > The sysctl code in rc IMO needs to be executed earlier. If one is > having problems reading from an ATA boot disk, e.g. cannot load init or > rc, these modes need to be set earlier. Why not a boot flag that sets > atamodes to be as conservative as possible, that could be set in > loader.conf. I see in the loader(8) man page that some sysctl > variables can be set in loader.conf. Can atamodes be set in > loader.conf? If not, maybe it should. Yes, this is it in a nutshell. All of the suggestions so far are good, but they come to late in the boot sequence to fix this problem. Jim Weeks - A mind is a terrible thing to lose! How I miss mine... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems compiling FreeBSD stable
Graham Wheeler wrote: > > Hi all > > I am trying to do a `make world' after cvsup'ing my whole /usr/src tree > to the latest RELENG_4 stable release (international version). I'm > getting a whole load of errors when it gets to compiling gcc though. I > have attached the tail end of my make output. > > Also, I managed to build a kernel using the same config file as I used > for a 4.0 kernel. The new kernel causes a page fault panic upon booting. > > Does anyone have any suggestions as to how I can proceed? Other than the > obvious one of going back to the source on my 4.0 CDs... Interestingly enough, I went and reinstalled my 4.0 release source tree, and now I get the same errors when I try to do a make world with that tree. Before I used cvsup at all, I could quite happily do a make world in this tree. So something has got horribly messed up by the process of cvsup'ing to RELENG_4 stable. I'm not sure what I can do now other than a complete reinstall of 4.0 release. 8-( > cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H >-DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" >-DPREFIX=\"/usr/obj/usr/src/i386/usr\" >-I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. >-I/usr/obj/usr/src/i386/usr/include -c >/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/xref.c > cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H >-DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" >-DPREFIX=\"/usr/obj/usr/src/i386/usr\" >-I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config >-I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. >-I/usr/obj/usr/src/i386/usr/include -static -o cc1plus parse.o call.o class.o cvt.o >decl.o decl2.o errfn.o error.o except.o expr.o friend.o init.o lex.o method.o pt.o >ptree.o repo.o rtti.o search.o semantics.o sig.o spew.o tree.o typeck.o typeck2.o >xref.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `finish_struct': > c-decl.o(.text+0x6ae8): multiple definition of `finish_struct' > class.o(.text+0x4f94): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `finish_struct' changed from 286 to >1572 in c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o)(.data+0x58): > multiple definition of `dollars_in_ident' > decl2.o(.data+0x3c): first defined here > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `print_lang_identifier': > c-decl.o(.text+0xe7c): multiple definition of `print_lang_identifier' > ptree.o(.text+0x3e0): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `print_lang_identifier' changed from >202 to 125 in c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `shadow_label': > c-decl.o(.text+0x2cc8): multiple definition of `shadow_label' > decl.o(.text+0x49ac): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `shadow_label' changed from 102 to 126 >in c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `xref_tag': > c-decl.o(.text+0x68c8): multiple definition of `xref_tag' > decl.o(.text+0xecdc): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `xref_tag' changed from 957 to 204 in >c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `init_decl_processing': > c-decl.o(.text+0x2f5c): multiple definition of `init_decl_processing' > decl.o(.text+0x6000): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `init_decl_processing' changed from >7570 to 5366 in c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `define_label': > c-decl.o(.text+0x2d48): multiple definition of `define_label' > decl.o(.text+0x4a14): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `define_label' changed from 687 to 135 >in c-decl.o > >/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): >In function `poplevel': > c-decl.o(.text+0x10e8): multiple definition of `poplevel' > decl.o(.text+0x6e0): first defined here > /usr/libexec/elf/ld: Warning: size of symbol `poplevel' changed from
using more than one md pseudo-device w/ 4.0
The md pseudo-device does work as described in the handbook in section 10.6.2. However it doesn't seem to work when I try to use a device other than /dev/md0, specifically /dev/md1. Some other pseudo-devices can be specified in the kernel configuration with a number to indicate the number of units. This doesn't seem to work with md. For example: pseudo-device md 3 # Memory "disks" I have run MAKEDEV md0 MAKEDEV md1 MAKEDEV md2 but I still get the message dd: /dev/md1: Device not configured when I do dd if=afile of=/dev/md1 How do I use more than one md device at a time? -- Adam Mackler To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ntpdate could not sync time from any server.
On Wed, May 24, 2000 at 07:48:03PM +, Wilko Bulte wrote: > On Wed, May 24, 2000 at 10:15:21AM -0700, Glen Gross wrote: > > I have had the same experience, with a DSL line. I don't know if > > ntpdate requires the time to be within a certain threshold before > > it will sync or not. Does anyone know the answer to this? > FWIW, I've had ntpdate sync my clock when it was >1 hour out, after NT advanced it another hour when we went from GMT to BST (Daylight Saving). > The time freak ;-) for FreeBSD is Poul-Henning (phk) > > > -- > Wilko Bulte FreeBSD, the power to serve http://www.freebsd.org > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- ...and on the eighth day God created UNIX FreeBSD - The Power To Serve http://www.freebsd.org My Webpage http://ukug.uk.freebsd.org/~mark/ mailto:[EMAIL PROTECTED] http://www.radan.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Transparent proxies and fetch
On Thu, 25 May 2000, Steve Roome wrote: > Then again, someone might have a better solution, but IMHO I think > it's quite rude of ISP's to divert your traffic without letting you > know about it, imagine how you'd feel if they started diverting all > your outgoing port23 connections and archiving everything that went > down that line. > > Others may feel differently about it though! And it's becoming far too > standard a practice now, so maybe we're supposed to move with the > times and accept it? I dunno! Well, I work for an ISP that does exactly this (automatic proxy/cache of http), and the reason we do it is because it saves thousands of dollars a month by cutting our inbound traffic roughly in half. A workaround if the ISP is unwilling to exclude your IP from the redirection (like, if you're on dialup with a dynamic IP, for example) would be to to use a SOCKS server that's not on your ISP's network. *** Another workaround would be to try to grab the files manually through ftp (or saved through a web browser) and stick 'em in /usr/ports/distfiles/ . *** However, I know for a fact that fetch (at least on 3.4R) has no problems with Cacheflow 3040 boxes deployed. I suspect that the problem looks like this: - fetch sends out the http:// request - the ISP's gateway redirects it to a caching box - the caching box makes the request to the server - for some reason, there's a delay - a timer expires in fetch, causing the "Document contains no data" error. I would expect that it would return a different error if the timer was expiring on the caching box (as the box would return an error as opposed to nothing) or on the server you were trying to fetch from (for the same reason). fetch appears to have a timeout switch, ie -T [seconds]. Perhaps you could try inserting very high timeout values into the Makefiles? -- Bob <[EMAIL PROTECTED]> "Reality is the only word in the language that should always be used in quotes" - The Amityville Horror III To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ad0 drivers revisited
On Mon, May 22, 2000 at 19:48 -0400, Jim Weeks wrote: > > On Mon, 22 May 2000, Alan Edmonds wrote: > > > > What worked for me was to put > > hw.atamodes=pio,,pio, > > in /etc/sysctl.conf > > I tried this also. Did you by any chance use this along with > /sbin/sysctl -w hw.atamodes=pio,pio,pio,pio in /etc/rc? IIRC are there some combinations of boards (i.e. controllers) and disks out there unable to cope with each other. And in the worse cases they do so right from the start. I struggled against such a beast myself lately: A VIA MVP4 board (that is, with a 82c586A PCI IDE controller) and a Fujitsu drive. Although both of them are new and cables aren't cheap (and of course I swapped them to make sure and I have a few of these machines and they all behave similarly) DMA mode simply won't work. The problem is: I could even disable UDMA modes in BIOS -- and all I get was that they get initialized to PIO mode when the BIOS is done. But: As soon as the BSD kernel is loaded and sees the hardware and activates its own drivers, negotiation takes place again (am I right in this or do I miss a point?). The chip is known to handle UDMA, the disk says "I can do that" and the lowest common denominator - and thus the conclusion the driver comes to - is "let's use it this way". Boom! And problems arise even before the user (or admin) is able to degrade downwards to a known to work mode (see the logs with read timeouts right after mounting root someone else - Jim? - posted in this thread). What I have seen in the previos discussions - and what I missed this time - was a simple approach like this: boot up with conservative assumptions and have UDMA mode get activated later via sysctl. This way *any* machine will work fine from boot to shutdown, and the confident in their hardware or the ones wanting to fiddle for performance could switch to higher modes for their daily operation. There might be a minimal loss of performance for those with hardware (combinations) capable of UDMA -- but only from installation to the point when they throw the switch. And I wouldn't mind the few seconds lost in the boot sequence between kernel loading and rc execution (if it's seconds at all). To make it even less important: How often does one boot? Once a year? Twice a year? I feel this little approach to be what helps most of the problematic cases where hardware claims high capabilities and fails to operate with these when actually enabled. And the UDMA switch could be prepared in /etc/sysctl.conf just as well as the routing switch is. > I even saw a post saying that someone put it into > /root/.profile and /root/.login, although I am not sure how > that was implemented or why. Setting IDE modes down to lower values (or upping them) shouldn't be necessary this often, once should suffice absolutely. The real problem is (as sketched above) that you might have errors even before you can turn off UDMA mode. I found OpenBSD show the first errors and falling back to PIO when formatting upon installation and it couldn't even boot after installation's end. And no matter how often I'm able to get a shell -- as long as during installation the sysctl(8) command is missing I could be willing to do something as much as I could, I'm simply _unable_ to make it work. Remembering this situation and hearing about yours I feel "being trapped" is the right phrase to name this. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Transparent proxies and fetch
On Thu, May 25, 2000 at 11:00:18AM +1000, Joe Shevland wrote: > when building ports. Someone wrote in asking whether our ISP has implemented a > transparent proxy. Unfortunately I culled my mail folder so I can't respond > directly, but the poster was on the money (the ISP grabs any port 80 requests > and stuffs them into the proxy instead). > > My question now is how do I work around this issue? I've tried setting the > HTTP_PROXY variable but this just makes the 'make install' of the ports fail > very quickly: In my limited experience calling the ISP and talking to them about it can work. I don't know if it will help, but you might be able to get them to remove the divert for you. The ISP I was with did that for me, on the other hand, you could always change ISP to someone who lets the customer decide when to use a proxy. Then again, someone might have a better solution, but IMHO I think it's quite rude of ISP's to divert your traffic without letting you know about it, imagine how you'd feel if they started diverting all your outgoing port23 connections and archiving everything that went down that line. Others may feel differently about it though! And it's becoming far too standard a practice now, so maybe we're supposed to move with the times and accept it? I dunno! Steve Roome To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4-stable won't boot
On Wed, May 24, 2000 at 08:35:55PM -0700, Mike Smith wrote: > > Hello, > > > > I just did a cvsup to RELENG_4 about noon EST today (Wed), built world, > > installed a new kernel, and rebooted. now, when I boot, I get the > > following: > ... > > Mounting root from ufs:/dev/ad0s3a > > no such device 'ad' > > Sounds like you left the 'ad' device out of your new kernel config. Bad > idea. 8) For what it's worth, I had similar problems recently as well, although I was getting ata_master: timeout waiting for command (from memory), however I did have the ad device, and the problem seemed to be related to some sort of conflict that appeared only when I had one of the following also in the kernel : options AUTO_EOI_1 options AUTO_EOI_2 device pcm device pcf I've not narrowed it down much yet, but suffice it to say that I got almost the same problem described above, but which automagically fixed itself once I took out the above 4 lines. I doubt it's anything to do with this, but I thought I'd mention it in case someone following this thread knows why this might happen. I will look into it further once I've got the time to recompile another 20+ kernels and test them. Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Problems compiling FreeBSD stable
Hi all I am trying to do a `make world' after cvsup'ing my whole /usr/src tree to the latest RELENG_4 stable release (international version). I'm getting a whole load of errors when it gets to compiling gcc though. I have attached the tail end of my make output. Also, I managed to build a kernel using the same config file as I used for a 4.0 kernel. The new kernel causes a page fault panic upon booting. Does anyone have any suggestions as to how I can proceed? Other than the obvious one of going back to the source on my 4.0 CDs... TIA gram cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/xref.c cc -O -pipe -DFREEBSD_NATIVE -DIN_GCC -DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"2.95.2\" -DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/usr/obj/usr/src/i386/usr/include -static -o cc1plus parse.o call.o class.o cvt.o decl.o decl2.o errfn.o error.o except.o expr.o friend.o init.o lex.o method.o pt.o ptree.o repo.o rtti.o search.o semantics.o sig.o spew.o tree.o typeck.o typeck2.o xref.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `finish_struct': c-decl.o(.text+0x6ae8): multiple definition of `finish_struct' class.o(.text+0x4f94): first defined here /usr/libexec/elf/ld: Warning: size of symbol `finish_struct' changed from 286 to 1572 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o)(.data+0x58): multiple definition of `dollars_in_ident' decl2.o(.data+0x3c): first defined here /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `print_lang_identifier': c-decl.o(.text+0xe7c): multiple definition of `print_lang_identifier' ptree.o(.text+0x3e0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `print_lang_identifier' changed from 202 to 125 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `shadow_label': c-decl.o(.text+0x2cc8): multiple definition of `shadow_label' decl.o(.text+0x49ac): first defined here /usr/libexec/elf/ld: Warning: size of symbol `shadow_label' changed from 102 to 126 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `xref_tag': c-decl.o(.text+0x68c8): multiple definition of `xref_tag' decl.o(.text+0xecdc): first defined here /usr/libexec/elf/ld: Warning: size of symbol `xref_tag' changed from 957 to 204 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `init_decl_processing': c-decl.o(.text+0x2f5c): multiple definition of `init_decl_processing' decl.o(.text+0x6000): first defined here /usr/libexec/elf/ld: Warning: size of symbol `init_decl_processing' changed from 7570 to 5366 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `define_label': c-decl.o(.text+0x2d48): multiple definition of `define_label' decl.o(.text+0x4a14): first defined here /usr/libexec/elf/ld: Warning: size of symbol `define_label' changed from 687 to 135 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `poplevel': c-decl.o(.text+0x10e8): multiple definition of `poplevel' decl.o(.text+0x6e0): first defined here /usr/libexec/elf/ld: Warning: size of symbol `poplevel' changed from 1427 to 706 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `shadow_tag': c-decl.o(.text+0x44f0): multiple definition of `shadow_tag' decl.o(.text+0x8090): first defined here /usr/libexec/elf/ld: Warning: size of symbol `shadow_tag' changed from 109 to 21 in c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_int/libcc_int.a(c-decl.o): In function `finish_decl': c-decl.o(.text+0x4888): multiple definition of `finish_decl' decl.o(.text+0x97bc): first defined here /usr/libexec/elf/ld: Warning: size of symbol `finish_decl' changed from 29 to 1082
makeworld fails on alpha
Just did a fresh cvsup on tag=RELENG_4. make buildworld fails with : don't know how to make twe.4 The reference to twe.4 is in share/man/man4/Makefile. When the reference is removed, make in share/man/man4/Makefile succeeds. mvh, Bjarne Blichfeldt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld failing on libssh
Kris Kennaway wrote: > > On Thu, 25 May 2000, Adam Mackler wrote: > > > now, the only mystery left is how did it work for so long? > > Until recently the 5.0 crypto code hadnt diverged from 4.0 very much (and > would have worked fine) It is still broken right now any way. It doesn't know how to make twe.4. Kent > > Kris > > > In God we Trust -- all others must submit an X.509 certificate. > -- Charles Forsythe <[EMAIL PROTECTED]> > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld failing on libssh
On Thu, 25 May 2000, Adam Mackler wrote: > now, the only mystery left is how did it work for so long? Until recently the 5.0 crypto code hadnt diverged from 4.0 very much (and would have worked fine) Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make buildworld failing on libssh
On Thu, 25 May 2000, Kris Kennaway wrote: > On Wed, 24 May 2000, Adam Mackler wrote: > > > I have cvsuped the RELENG_4 stable-supfile with the > > international secure-supfile, and when I make buildworld it fails, > > saying: > > Wrong supfile - you grabbed -current. once again proving that the most mind-numbing problems are the ones with one-line solutionsi knew it had to be somethng stupid and minor. i thank you (and so does my scalp, now that i can stop pulling my hair out)! now, the only mystery left is how did it work for so long? that's the real problem with FreeBSD--it's so robust that just because everything is working doesn't mean I'm doing it right. Thank you very much again! adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
