Maybe the comitters ought to take an idea from many software companies and
contribute $5 to the beer fund every time they break the build. Have it
all come due at the next BSDcon to fund a committer beer bash. :-)
I'd go along with that. What do the other committers think?
At 09:18 PM 5/13/2000 +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Jeroen Ruigrok van der Werv
en writes:
-On [2513 21:06], Manfred Antar ([EMAIL PROTECTED]) wrote:
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode
On Tue, May 09, 2000 at 02:56:58PM +0400, Igor Timkin wrote:
The same problem. Local is openssh (current), remote is ssh-1.2.22 (2.2.6),
slip ~24kbps connection. Remote log:
May 9 09:59:17 crocus sshd[21285]: fatal: Local: Corrupted check bytes on input.
This thing is even worse - I
In message [EMAIL PROTECTED], Jeroen Ruigrok van der Werv
en writes:
-On [2513 21:06], Manfred Antar ([EMAIL PROTECTED]) wrote:
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert to char mode
with /dev/MAKEDEV before 2000-07-01
It seems Mike Pritchard wrote:
I did notice that I started getting all of the "unknown: PNPx"
messages after the PNPBIOS option became default. On the
machine I'm typing on this on, I used to see those messages
if I defined PNPBIOS in my config file. PNPBIOS became default
some
Mr Miller:
Try obtaining a crypto distribution from internat or freefall.
That should solve your problem.
On Sat, May 13, 2000 at 08:11:25AM -0400, Donn Miller wrote:
-I/usr/obj/usr/src/i386/usr/include/openssl -DCRYPTO -DHAVE_LIBCRYPTO
-DHAVE_RC5_H -DHAVE_CAST_H
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert to char mode with
/dev/MAKEDEV before 2000-07-01
I've run MAKEDEV all
I have a simple fstab:
# DeviceMountpoint FStype Options DumpPass#
-On [2513 21:06], Manfred Antar ([EMAIL PROTECTED]) wrote:
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert to char mode
with /dev/MAKEDEV before 2000-07-01
There is a bug somewhere in the rootmount code.
I just lack
On Sat, May 13, 2000 at 01:39:11PM +0100, Brian Somers wrote:
This has been happening to me in environments with high packet loss,
and before the NewReno changes went in. It was only happening in a
rather dubious environment were there was high packet loss
(compressed PPP over
In message [EMAIL PROTECTED], "Andrey A. Chernov" writes:
On Sat, May 13, 2000 at 01:39:11PM +0100, Brian Somers wrote:
This has been happening to me in environments with high packet loss,
and before the NewReno changes went in. It was only happening in a
rather dubious environment were
On Fri, 12 May 2000, David O'Brien wrote:
On Fri, May 12, 2000 at 04:41:09PM +0900, Munehiro Matsuda wrote:
When run 'make -j4 buildworld' with internat crypto code installed,
I get following error:
mkdir: openssl: File exists
*** Error code 1
- @test -d openssl || mkdir -p openssl
Hasan Diwan wrote:
Mr Miller:
Try obtaining a crypto distribution from internat or freefall.
That should solve your problem.
Damn - I just forgot to uncomment the cvs-crypto line in my supfile.
Thanks!
- Donn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Fri, 12 May 2000, Stephen Hocking wrote:
For the past few days, current has not compiled, owing to problems (in no
particular order) with more, vinum and various INET options in the GENERIC
kernel. Can people please check things before they commit them? I like a
working compile at
=== usr.sbin/tcpdump/tcpdump
rm -f .depend
mkdep -f .depend -a-DHAVE_CONFIG_H
-I/usr/src/usr.sbin/tcpdump/tcpdump
-I/usr/obj/usr/src/i386/usr/include/openssl -DCRYPTO -DHAVE_LIBCRYPTO
-DHAVE_RC5_H -DHAVE_CAST_H
-I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/lbl
At 09:54 PM 5/13/2000 +0200, Assar Westerlund wrote:
Jeroen Ruigrok van der Werven [EMAIL PROTECTED] writes:
-On [2513 21:06], Manfred Antar ([EMAIL PROTECTED]) wrote:
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert
In message [EMAIL PROTECTED], Manfred Antar writes:
--- vfs_subr.c~ Sat May 6 00:08:38 2000
+++ vfs_subr.c Sat May 13 21:47:08 2000
@@ -1296,7 +1296,7 @@
return (error);
}
vp = nvp;
- vp-v_type = VBLK;
+ vp-v_type = VCHR;
addalias(vp,
In some email I received from Greg Lehey, sie wrote:
On Saturday, 13 May 2000 at 9:53:40 -0700, Brian W. Buchanan wrote:
On Fri, 12 May 2000, Stephen Hocking wrote:
For the past few days, current has not compiled, owing to problems (in no
particular order) with more, vinum and various
Mike Nowlin wrote:
I'd just seen a series of bad commits whose corrections weren't caught by the
frequency of my cvs updates I guees. Vinum is compiling now, and kernels with
IPSEC and INETV6 now link, it's just that last night's problems with more got
me a little ticked off.
cc:
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
I would suggest that this driver be added to "GENERIC". For
what it's worth, I added the driver to my kernel, rebooted, and
completed the make release.
Thanks all.
Kent
To
At 10:28 PM 5/13/2000 +0200, Jeroen Ruigrok van der Werven wrote:
-On [2513 22:08], Manfred Antar ([EMAIL PROTECTED]) wrote:
Which is the correct dev /dev/da0a , /dev/rda0a , or /dev/da0s1a to use
rda0a won't work. da0a works fine and I got rid of all the da0s1a,b,e,f,g ones ?
The /dev
After cvsup'ing this afternoon, mtree compiles.
But ngctl fails:
=== usr.sbin/ngctl
cc -O -pipe -Wall -c /usr/src/usr.sbin/ngctl/types.c
/usr/src/usr.sbin/ngctl/types.c: In function `TypesCmd':
/usr/src/usr.sbin/ngctl/types.c:86: structure has no member named `type_name'
*** Error code 1
The following patch fixed the problem for me. For extra points,
rename the function.
That fixed the problem for the me too. Thanks!
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
On Saturday, 13 May 2000 at 9:53:40 -0700, Brian W. Buchanan wrote:
On Fri, 12 May 2000, Stephen Hocking wrote:
For the past few days, current has not compiled, owing to problems (in no
particular order) with more, vinum and various INET options in the GENERIC
kernel. Can people please
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
What do you mean "now"? It's _always_ been required.
I would suggest that this driver be added to "GENERIC". For
what it's worth, I added the driver to my kernel,
Actually I think this is an indication of really old boot blocks.
The old bootblocks passed in a Bmajor number for the root device.
Could you try to update your bootblocks with the disklabel
program and see if that stops the warning Manfred ?
I can't speak for this case, but the one I
Jeroen Ruigrok van der Werven [EMAIL PROTECTED] writes:
-On [2513 21:06], Manfred Antar ([EMAIL PROTECTED]) wrote:
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert to char mode
with /dev/MAKEDEV before 2000-07-01
In [EMAIL PROTECTED] Mike Smith [EMAIL PROTECTED] wrote:
In trying to build "make release" today, I discovered that the
"vn" driver is required now to build the boot floppies.
What do you mean "now"? It's _always_ been required.
I would suggest that this driver be added to "GENERIC".
Curious.
I've done several (say a dozen) make release builds in the last 4 months
of 4.0-CURRENT 5.0-CURRENT. The previous one was about 2 weeks ago.
I've never had "vn" in my kernel, nor had a problem. Maybe something
in the latest "loadable kernel modules" synchronization/version control
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], "Andrey A. Chernov" writes:
On Sat, May 13, 2000 at 01:39:11PM +0100, Brian Somers wrote:
This has been happening to me in environments with high packet loss,
and before the NewReno changes went in. It was only happening in a
-On [2513 22:08], Manfred Antar ([EMAIL PROTECTED]) wrote:
Which is the correct dev /dev/da0a , /dev/rda0a , or /dev/da0s1a to use
rda0a won't work. da0a works fine and I got rid of all the da0s1a,b,e,f,g ones ?
The /dev/da0s1a would be the correct one to use, example:
# Device
I get this in boot mesgs and I don't know how to fix it.
Device char-major=13 minor=0 opened in block mode, convert to char mode
with /dev/MAKEDEV before 2000-07-01
There is a bug somewhere in the rootmount code.
It's the following VFS_MOUNT call at line 215 of vfs_mountroot_try()
No, I havn't tracked down the last couple of causes of this, but I
will try to reproduce it as you describe it with some debugging added.
How hard would it be to print the filename (or the device/inode) that
triggers the warning?
Not at all (warning: cutpasted patch, tabs are screwed
It seems Mike Pritchard wrote:
I did notice that I started getting all of the "unknown: PNPx"
messages after the PNPBIOS option became default. On the
machine I'm typing on this on, I used to see those messages
if I defined PNPBIOS in my config file. PNPBIOS became default
-On [2513 01:30], Marius Strom ([EMAIL PROTECTED]) wrote:
cvsup as of ~20 minutes ago, during a buildworld:
-o mtree compare.o crc.o create.o misc.o mtree.o spec.o verify.o
setflags.o -lmd
create.o: In function `cwalk':
create.o(.text+0xcf): undefined reference to `check_excludes'
Should
34 matches
Mail list logo
