Re: adduser(8) in 5.0-R

2003-01-21 Thread Mike Makonnen
I have cc'ed bmah, because I think it should be in the errata.

On Tue, 21 Jan 2003 14:36:11 -
Robin Breathe [EMAIL PROTECTED] wrote:

 Hmmm, it might be worth mentioning, since md5 is the default passwd hash,
 it's not infeasible that someone might choose `rm -rf /`, or similar, as
 their passwd... Which would have somewhat unpleasant results since adduser
 runs as root.

Well, you would have to be root to run it in the first place, but I deserve the
pointy hat none the less.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg50656/pgp0.pgp
Description: PGP signature


Re: aout support not working on todays -current

2003-01-21 Thread Mike Makonnen
I believe aout support was removed from the kernel some months ago. It was going
to be made a port, but I don't know if that has happened yet.

-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg50658/pgp0.pgp
Description: PGP signature


Re: aout support not working on todays -current

2003-01-21 Thread Mike Makonnen
On Tue, 21 Jan 2003 09:47:20 -0800
Kris Kennaway [EMAIL PROTECTED] wrote:

 You're confusing two issues.  To run a.out binaries you just need
 COMPAT_AOUT.  To generate new a.out binaries you need an a.out
 toolchain, which is what someone was going to make a port for, but
 never did.

Ahh, I see. Thanks for clearing that up.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg50660/pgp0.pgp
Description: PGP signature


Re: Adduser difference between 5.0 and earlier versions

2003-01-21 Thread Mike Makonnen

The new adduser was not intended to be a feature-for-feature replacement of the
perl version. This version allows you to enter multiple accounts from a file, so
providing this type of functionality wasn't particularly important on my list of
things to do. 

But, as long as someonle else is submitting the patch, that's fine
with me :-)  I have one request though: All the other yes/no prompts will repeat
the prompt if they get anything other than what they expect, can you redo the
patch so that it repeats the prompt if it gets no input or anything other than
yes/no? For consistency's sake.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg50684/pgp0.pgp
Description: PGP signature


Re: alpha tinderbox failure

2003-01-19 Thread Mike Barcroft
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
 --
  Kernel build for LINT started on Sun Jan 19 03:36:18 PST 2003
 --
 === vinum
 Makefile, line 4437: warning: duplicate script for target geom_bsd.o ignored
 /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken 
and is not compiled with LINT
 /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
 /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer 
target type
 /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken 
and is not compiled with LINT
 /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and 
is not compiled with LINT
 cc1: warnings being treated as errors
 /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
 /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant 
conversion
 *** Error code 1

Fixed.  Peter fixed the same problem elsewhere, but must have missed
this one.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: RELENG_5 branch ?

2003-01-17 Thread Mike Barcroft
Joao Pedras [EMAIL PROTECTED] writes:
 
 Hi all
 
 Will there be a RELENG_5 where we would get 5.0-STABLE ? Pretty much in the same
 way it has been up until now...
 
 Is this code currently tagged with RELENG_5_0 ?

This won't happen until after 5.1 or 5.2.  For now we have 5.1-CURRENT
or something like that.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: unexpected machine check on 5.0 alpha

2003-01-16 Thread Mike Tibor
On Thu, 16 Jan 2003, Trevor Johnson wrote:

 I just got a similar crash:

   unexpected machine check:

   mces= 0x1
   vector  = 0x670
   param   = 0xfc004e10
   pc  = 0xfc4069bc
   ra  = 0xfc4069b4
   curproc = 0xfc001f169200
   pid = 23, comm = intr: sym1


 I was sitting next to it when it crashed, and I would have noticed if the
 fans had stopped.  From earlier logs, I see that the temperature has
 varied between 21 and 27 Celsius.  I don't know what it is now, but it
 feels warmish when I'm wearing just a tee shirt.  There's a fan that
 constantly blows air into the room, which points toward the back of the
 computer.  Should I run the air conditioner more often?

I believe a 670 machine check can also result from a read of a
non-existent I/O space.  I'm not a programmer, but could that be the
problem here?

Mike


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: unexpected machine check on 5.0 alpha

2003-01-16 Thread Mike Tibor
On Thu, 16 Jan 2003, Andrew Gallatin wrote:

(I wrote: )
   I believe a 670 machine check can also result from a read of a
   non-existent I/O space.  I'm not a programmer, but could that be the
   problem here?

 No, that's a 660. (system machine check).
 A 670 is much more likely to be bad ram, bad cache, bad CPU, etc.
 Its not always overheating.

Hmm... well, I got that from Jay Estabrook (works at DEC/Compaq/HP) via
the [EMAIL PROTECTED]  The archived message is here:

http://www.lib.uaa.alaska.edu/axp-list/archive/1998-12/0491.html

FWIW...

Mike


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: [PATCH] Fix man pages with iovec

2003-01-12 Thread Mike Barcroft
Craig Rodrigues [EMAIL PROTECTED] writes:
 Hi,
 
 This patch fixes the read(2) and write(2) man pages
 to accurately reflect the iovec structure defined
 in sys/_iovec.h and sys/uio.h.

Committed, thanks.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-10 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Jan 10 10:17:39 GMT 2003
--
=== usb
ld: cannot open output file usb.kld: No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/usb.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-09 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Jan 10 04:16:49 GMT 2003
--
=== vx
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/vx.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-08 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Jan  8 10:16:18 GMT 2003
--
=== ipfilter
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/ipfilter.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-08 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Jan  8 16:16:05 GMT 2003
--
=== ipfilter
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/ipfilter.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-08 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Jan  8 22:16:49 GMT 2003
--
=== vx
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/vx.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sparc64 tinderbox failure

2003-01-08 Thread Mike Barcroft
Jake Burkholder [EMAIL PROTECTED] writes:
 Apparently, On Wed, Jan 08, 2003 at 11:25:12PM +,
   Mike Barcroft said words to the effect of;
  --
   Kernel build for GENERIC started on Wed Jan  8 22:16:49 GMT 2003
  --
  === vx
  touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/vx/export_syms:
 No such file or directory
  *** Error code 1
 
 FWIW, I can't reproduce this locally, it must be a problem with the
 tinderbox.  I haven't seen Mike around lately, hopefully he can see
 what's going on soon.
 
 Sorry for the spam.

Hmm, I'll try clearing the obj directory and see if that helps.  I did
have some trouble with the filesystem the tinderbox runs on.  fsck may
have deleted some files that left things in an unexpected state.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-07 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Tue Jan  7 16:18:02 GMT 2003
--
=== unionfs
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/unionfs/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/unionfs.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-07 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Tue Jan  7 22:18:05 GMT 2003
--
=== ums
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ums/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/ums.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: alpha tinderbox failure

2003-01-06 Thread Mike Barcroft
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
 --
  Kernel build for LINT started on Mon Jan  6 03:35:12 PST 2003
 --
 === vinum
 Makefile, line 4445: warning: duplicate script for target geom_bsd.o  [...]
 /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...]
 /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
 /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
 /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...]
 /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...]
 cc1: warnings being treated as errors
 /h/des/src/sys/security/mac_lomac/mac_lomac.c: In function `mac_lomac_ass [...]
 /h/des/src/sys/security/mac_lomac/mac_lomac.c:1070: warning: passing arg  [...]
 /h/des/src/sys/security/mac_lomac/mac_lomac.c:1081: warning: int format,  [...]
 *** Error code 1

These new truncated lines only make problems harder to solve.

Anyway, the problem is the 5th argument to vn_extattr_get() should be
an int *, but it's passing a size_t *.  It looks like most consumers
of vn_extattr_get() would prefer a size_t *, so maybe the interface
should be changed.

This patch should resolve the problem without changing
vn_extattr_get()'s interface:

%%%
Index: mac_lomac.c
===
RCS file: /work/repo/src/sys/security/mac_lomac/mac_lomac.c,v
retrieving revision 1.6
diff -u -r1.6 mac_lomac.c
--- mac_lomac.c 10 Dec 2002 16:20:33 -  1.6
+++ mac_lomac.c 6 Jan 2003 15:53:02 -
@@ -49,6 +49,7 @@
 #include sys/malloc.h
 #include sys/mount.h
 #include sys/proc.h
+#include sys/stdint.h
 #include sys/systm.h
 #include sys/sysproto.h
 #include sys/sysent.h
@@ -1067,7 +1068,7 @@
bzero(temp, buflen);
 
error = vn_extattr_get(vp, IO_NODELOCKED, MAC_LOMAC_EXTATTR_NAMESPACE,
-   MAC_LOMAC_EXTATTR_NAME, buflen, (char *)temp, curthread);
+   MAC_LOMAC_EXTATTR_NAME, (int *)buflen, (char *)temp, curthread);
if (error == ENOATTR || error == EOPNOTSUPP) {
/* Fall back to the fslabel. */
mac_lomac_copy_single(source, dest);
@@ -1077,8 +1078,9 @@
 
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
-   printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
-   buflen);
+   printf(
+   mac_lomac_associate_vnode_extattr: bad size %ju\n,
+   (uintmax_t)buflen);
return (EPERM);
}
bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
%%%

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: alpha tinderbox failure

2003-01-06 Thread Mike Barcroft
Mike Barcroft [EMAIL PROTECTED] writes:
 @@ -1077,8 +1078,9 @@
  
   if (buflen != sizeof(temp)) {
   if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
 - printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
 - buflen);
 + printf(
 + mac_lomac_associate_vnode_extattr: bad size %ju\n,
 + (uintmax_t)buflen);
   return (EPERM);
   }
   bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));

Oops, I forgot we have %z in printf(9) now.  That would obviously be
better.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2003-01-06 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Tue Jan  7 04:15:50 GMT 2003
--
=== ipfilter
touch: 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC/modules/tinderbox/sparc64/src/sys/modules/ipfilter/export_syms:
 No such file or directory
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules/ipfilter.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/modules.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: alpha tinderbox failure

2003-01-01 Thread Mike Barcroft
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
 === vinum
 Makefile, line 4453: warning: duplicate script for target geom_bsd.o ignored
 cc1: warnings being treated as errors
 /h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc':
 /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different type 
arg (arg 5)
 /h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg (arg 
6)
 /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type 
arg (arg 6)
 /h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type 
arg (arg 7)
 *** Error code 1

Proposed fix:

%%%
Index: isp_pci.c
===
RCS file: /work/repo/src/sys/dev/isp/isp_pci.c,v
retrieving revision 1.89
diff -u -r1.89 isp_pci.c
--- isp_pci.c   11 Oct 2002 17:28:01 -  1.89
+++ isp_pci.c   1 Jan 2003 14:56:25 -
@@ -1538,9 +1538,10 @@
cto-rsp.m0.ct_dataseg[cto-ct_seg_count].ds_count =
dm_segs[segcnt].ds_len;
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
-   isp_prt(isp, ISP_LOGTDEBUG1, isp_send_ctio2: ent0[%d]0x%x:%d,
-   cto-ct_seg_count, dm_segs[segcnt].ds_addr,
-   dm_segs[segcnt].ds_len);
+   isp_prt(isp, ISP_LOGTDEBUG1,
+   isp_send_ctio2: ent0[%d]0x%lx:%lu,
+   cto-ct_seg_count, (unsigned long)dm_segs[segcnt].ds_addr,
+   (unsigned long)dm_segs[segcnt].ds_len);
}
 
while (segcnt  nseg) {
@@ -1567,9 +1568,10 @@
crq-req_dataseg[seg].ds_base = dm_segs[segcnt].ds_addr;
crq-req_dataseg[seg].ds_count = dm_segs[segcnt].ds_len;
isp_prt(isp, ISP_LOGTDEBUG1,
-   isp_send_ctio2: ent%d[%d]%x:%u,
+   isp_send_ctio2: ent%d[%d]%lx:%lu,
cto-ct_header.rqs_entry_count-1, seg,
-   dm_segs[segcnt].ds_addr, dm_segs[segcnt].ds_len);
+   (unsigned long)dm_segs[segcnt].ds_addr,
+   (unsigned long)dm_segs[segcnt].ds_len);
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
cto-ct_seg_count++;
}
%%%

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-31 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== usr.bin/gcore
In file included from /tinderbox/sparc64/src/usr.bin/gcore/elfcore.c:38:
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include/vm/vm_map.h:167: 
field `system_mtx' has incomplete type
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.bin/gcore.
*** Error code 1

Stop in /tinderbox/sparc64/src/usr.bin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-30 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 2)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 4)
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/swapon.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-30 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
=== usr.sbin/fwcontrol
cd: can't cd to /tinderbox/sparc64/src/usr.sbin/fwcontrol
*** Error code 2

Stop in /tinderbox/sparc64/src/usr.sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-30 Thread Mike Barcroft
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html

--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== bin/df
cc1: warnings being treated as errors
/tinderbox/sparc64/src/bin/df/df.c: In function `prtstat':
/tinderbox/sparc64/src/bin/df/df.c:395: warning: passing arg 1 of `getbsize' from 
incompatible pointer type
/tinderbox/sparc64/src/bin/df/df.c: In function `update_maxwidths':
/tinderbox/sparc64/src/bin/df/df.c:448: warning: passing arg 1 of `getbsize' from 
incompatible pointer type
*** Error code 1

Stop in /tinderbox/sparc64/src/bin/df.
*** Error code 1

Stop in /tinderbox/sparc64/src/bin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-29 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 2)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 4)
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/swapon.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-29 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 2)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 4)
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/swapon.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ia64 tinderbox failure

2002-12-29 Thread Mike Barcroft
Bruce Evans [EMAIL PROTECTED] writes:
 The correct fix is to unbreak getbsize() so that it takes an `int *' as its
 first arg like it used to.  The interface change and the above change
 just give a header length that is not directly usably by any of its users.
 The header length is what must be passed to printf in %*s formats; it
 should have type int since that is what printf takes; any bounds checking
 of it belongs in getbsize() (but in practice it is a small positive
 number since anything else would give preposterous formatting, so there
 is never a problem with its bounds).  Other users of getbsize() in the
 src tree but perhaps not ones in ports have been broken to match the
 interface breakage.  The usual breakage is to cast the size_t to int
 without checking bounds.

Agreed.  Not a single consumer actually wants a size_t and not all base
system uses have been fixed for the new interface (ls(1) for instance).
I'd like to see the interface restored and merged into RELENG_5_0 before
we introduce this mistake on the world.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-29 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 2)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 4)
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/swapon.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-29 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/swapon
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sbin/swapon/swapon.c: In function `swaplist':
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:246: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 3)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:265: warning: field width is not type int 
(arg 5)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 2)
/tinderbox/sparc64/src/sbin/swapon/swapon.c:274: warning: field width is not type int 
(arg 4)
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin/swapon.
*** Error code 1

Stop in /tinderbox/sparc64/src/sbin.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: ia64 tinderbox failure

2002-12-28 Thread Mike Barcroft
Peter Wemm [EMAIL PROTECTED] writes:
 === sbin/swapon
 cc1: warnings being treated as errors
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c: In function `swaplist':
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:246: warning: field width is not type 
int (arg 3)
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:246: warning: field width is not type 
int (arg 5)
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:265: warning: field width is not type 
int (arg 3)
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:265: warning: field width is not type 
int (arg 5)
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:274: warning: field width is not type 
int (arg 2)
 /home/tinderbox/ia64/src/sbin/swapon/swapon.c:274: warning: field width is not type 
int (arg 4)
 *** Error code 1

Proposed fix:

%%%
Index: swapon.c
===
RCS file: /work/repo/src/sbin/swapon/swapon.c,v
retrieving revision 1.14
diff -u -r1.14 swapon.c
--- swapon.c28 Dec 2002 23:39:47 -  1.14
+++ swapon.c29 Dec 2002 05:53:17 -
@@ -53,6 +53,7 @@
 #include err.h
 #include errno.h
 #include fstab.h
+#include limits.h
 #include stdio.h
 #include stdlib.h
 #include string.h
@@ -210,8 +211,8 @@
 {
size_t mibsize, size;
struct xswdev xsw;
-   int mib[16], n, pagesize;
-   size_t hlen;
+   int hlen, mib[16], n, pagesize;
+   size_t hsize;
long blocksize;
long long total = 0;
long long used = 0;
@@ -229,7 +230,8 @@
hlen = 10;
break;
default:
-   getbsize(hlen, blocksize);
+   getbsize(hsize, blocksize);
+   hlen = MIN(INT_MAX, hsize);
break;
}

%%%

BTW, the tabbing in this area of the source file is messed up.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-27 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Dec 27 16:12:52 GMT 2002
--
=== ipfilter
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c: In function `ffs_load_inode':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `mtype' doesn't match 
prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `fs' doesn't match 
prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: number of arguments doesn't match 
prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sa_handler and sigaction...

2002-12-26 Thread Mike Barcroft
Brandon S. Allbery  KF8NH [EMAIL PROTECTED] writes:
 I don't have the spec, but a perusal of secondary sources has
 P1003.1-1990 specifying sa_handler and P1003.1-1993 adding sa_sigaction.
 
 I should add that sigaction() without sa_handler is almost entirely
 useless for portable programming, so it would be downright bizarre for
 POSIX to specify sigaction() and yet omit sa_handler.

This looks like my bug.  I'll fix it.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-20 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sys/boot/sparc64/loader
In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15:
machine/asm.h:105:1: warning: __FBSDID redefined
In file included from machine/asm.h:46,
 from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15:
/tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the 
previous definition
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared 
here (not in a function)
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is not 
constant
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for 
`file_system[2]')
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot/sparc64/loader.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot/sparc64.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: VLAN v.s. NIC with VLAN hardware support bug.

2002-12-20 Thread Mike Tancsa
At 02:45 AM 12/21/2002 +0100, Dan Lukes wrote:

 At 10:22 PM 20/12/2002 +0100, Dan Lukes wrote:

 If there somebody failing to configure vlans on a nic with
 vlan-hardware support - read the PR 46405 (patch attached).


 Mike Tancsa wrote, On 12/20/02 22:46:
 Does this bug show up in the trunk ports statistics as runt
 packets ?


Did you mean the statistics on switch ?



Yes
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 6031000 bits/sec, 877 packets/sec
  5 minute output rate 3104000 bits/sec, 1160 packets/sec
 1631516276 packets input, 4237296754 bytes
 Received 161839 broadcasts, 212836721 runts, 0 giants, 0 throttles
 212836725 input errors, 0 CRC, 4 frame, 0 overrun, 84223 ignored
 0 watchdog, 0 multicast
 0 input packets with dribble condition detected
 194910163 packets output, 3947790078 bytes, 0 underruns
 0 output errors, 0 collisions, 0 interface resets
 0 babbles, 0 late collision, 0 deferred
 0 lost carrier, 0 no carrier
 0 output buffer failures, 0 output buffers swapped out




No, it doesn't affect the switch statistic because bug is in 
receive part of FreeBSD driver - it doesn't affect packets sent out to switch.

It doesnt seem to affect performance.  When I did some benchmarks way back 
with netperf, the difference in vlan performance vs native fxp performance 
was  barely significant.

---Mike

Mike Tancsa,  	  tel +1 519 651 3400
Sentex Communications, 			  [EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada			  www.sentex.net/mike


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


sparc64 tinderbox failure

2002-12-19 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sys/boot/sparc64/loader
In file included from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15:
machine/asm.h:105:1: warning: __FBSDID redefined
In file included from machine/asm.h:46,
 from /tinderbox/sparc64/src/sys/boot/sparc64/loader/locore.S:15:
/tinderbox/sparc64/src/sys/sys/cdefs.h:239:1: warning: this is the location of the 
previous definition
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: `zipfs_fsops' undeclared 
here (not in a function)
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: initializer element is not 
constant
/tinderbox/sparc64/src/sys/boot/sparc64/loader/main.c:110: (near initialization for 
`file_system[2]')
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot/sparc64/loader.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot/sparc64.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys/boot.
*** Error code 1

Stop in /tinderbox/sparc64/src/sys.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-18 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type

sparc64 tinderbox failure

2002-12-18 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type

sparc64 tinderbox failure

2002-12-18 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type

sparc64 tinderbox failure

2002-12-17 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
=== sbin/gbde
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeySched':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function 
`rijndaelKeyEncToDec':
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast 
increases required alignment of target type
/tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast 
increases required alignment of target type

Re: rcng script bugs

2002-12-15 Thread Mike Makonnen

[ cc'ed imp@ since the second one concerns changes he recently made ]

On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
 
 17c17
  pidfile=/var/run/${name}.pid
 ---
  pidfile=/var/run/${name}/pid
 
 in order to match the default named.conf file.

Yes, definitely a bug. I had changed my named.conf so I didn't notice
this. However, I think your solution is just as broken as the current
code. While it would work if the user doesn't change the default
pid path, it wouldn't work for people who do change it (like me).
I think the way to solve it is with a named_pidfile variable in
defaults/rc.conf that defaults to /var/run/named/pid. What are people's
thoughts on this?  Secondly, the change would have to go into the
'FreeBSD' case-clause in order not to mess up the NetBSD case.


 
 /etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
 preventing the machine from booting.  I noticed that a change has been added to
 check if an interface is up and skip configuring it if it is.  Instead of using
 grep it is possible to use ifconfig's -d option (see man page) to only list
 interfaces marked as down.  This is my change for /etc/rc.d/network1
 
 140c140
network_interfaces=`ifconfig -l -d`
 ---
network_interfaces=`ifconfig -l`
 148a149,153
if ifconfig ${ifn} | grep -s UP,  /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
 
Warner,

He's working off the first set of changes you made but it seems
that in the diskless case you may have to reconfigure more
than just lo0.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48762/pgp0.pgp
Description: PGP signature


Re: rcng script bugs

2002-12-15 Thread Mike Makonnen
[ ok, really cc him this time]

On Sun, Dec 15, 2002 at 01:02:51AM -0800, Mike Makonnen wrote:
 
 [ cc'ed imp@ since the second one concerns changes he recently made ]
 
 On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
  
  17c17
   pidfile=/var/run/${name}.pid
  ---
   pidfile=/var/run/${name}/pid
  
  in order to match the default named.conf file.
 
 Yes, definitely a bug. I had changed my named.conf so I didn't notice
 this. However, I think your solution is just as broken as the current
 code. While it would work if the user doesn't change the default
 pid path, it wouldn't work for people who do change it (like me).
 I think the way to solve it is with a named_pidfile variable in
 defaults/rc.conf that defaults to /var/run/named/pid. What are people's
 thoughts on this?  Secondly, the change would have to go into the
 'FreeBSD' case-clause in order not to mess up the NetBSD case.
 
 
  
  /etc/rc.d/network1:
 When using a diskless configuration this file took the interface offline,
  preventing the machine from booting.  I noticed that a change has been added to
  check if an interface is up and skip configuring it if it is.  Instead of using
  grep it is possible to use ifconfig's -d option (see man page) to only list
  interfaces marked as down.  This is my change for /etc/rc.d/network1
  
  140c140
 network_interfaces=`ifconfig -l -d`
  ---
 network_interfaces=`ifconfig -l`
  148a149,153
 if ifconfig ${ifn} | grep -s UP,  /dev/null 21; then
 # Interface is already up, so ignore it.
 continue;
 fi
  
 Warner,
 
 He's working off the first set of changes you made but it seems
 that in the diskless case you may have to reconfigure more
 than just lo0.
 
 Cheers.
 -- 
 Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
 [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48763/pgp0.pgp
Description: PGP signature


sparc64 tinderbox failure

2002-12-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sun Dec 15 10:09:17 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sun Dec 15 16:09:34 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sun Dec 15 22:11:11 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-14 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sat Dec 14 10:08:25 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-14 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sat Dec 14 16:12:14 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-14 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sat Dec 14 22:09:33 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-12-14 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sun Dec 15 04:10:39 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from 
integer of different size
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from 
integer of different size
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Posix Semaphores in -CURRENT

2002-12-13 Thread Mike Barcroft
Joe Kelsey [EMAIL PROTECTED] writes:
 Yes, I realize this, but it seems that from my cursory inspection of 
 uipc_sem.c that the check for embedded '/' characters is unnecessary and 
 much too restrictive according to the posix standard.  The standard only 
 talks about whether or not the semaphore name begins with '/' and has 
 nothing to say about embedded slashes except that the name must conform 
 to filename requirements.  It seems to me that either you take the TRU64 
 approach and place a marker in the file system (special directory 
 entry?) or you allow all strings, only looking at the first character 
 and not caring about anything else, except for whatever maximum pathname 
 requirements you choose to impose.
 
 Maybe I am missing something in the system call semantics?

Sounds like a bug to me.  Could you open a PR?

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: __BSD_VISIBLE and u_int

2002-12-13 Thread Mike Barcroft
Nate Lawson [EMAIL PROTECTED] writes:
 On Wed, 11 Dec 2002, Mike Barcroft wrote:
  Nate Lawson [EMAIL PROTECTED] writes:
   What's the proper way to get a typedef for u_int?  Is there a doc
   somewhere on what we expect in terms of #defines for 3rd party application
   authors?
  
  sys/types.h will give you a typedef, provided you aren't writing a
  POSIX or X/Open application.  If you're writing a POSIX or X/Open
  application (the only time __BSD_VISIBLE is false) you'll have to do
  the typedef manually in your application.
 
 Hmm, which of these defines claims posix src? -D_ANSI_SOURCE ?

_ANSI_SOURCE means a strictly conforming C89 application.  Everything
in sys is off limits for such a program.

 cc -O -c -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -I./../include
 -I./.. -DDIRENT=1 -DDIRENT=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1
 -DHAVE_FCNTL_H=1 -DHAVE_ST_RDEV=1 -DHAVE_TM_ZONE=1
 -DHAVE_LONG_FILE_NAMES=1 -DHAVE_RESTARTABLE_SYSCALLS=1 -D_ANSI_SOURCE
 -DHAVE_DEV_CONSOLE=1 os.c
 In file included from os.c:25:
 /usr/include/sys/file.h:130: syntax error before u_int
 
  u_int is undocumented and unportable, so it probably shouldn't be
  used.  It's only 3 characters shorter than `unsigned' anyway.
 
 It's for ports.

I fixed a port like this recently.  _ANSI_SOURCE was actually added by
the port, not the application vendor, in that case.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: __BSD_VISIBLE and u_int

2002-12-13 Thread Mike Barcroft
Mike Barcroft [EMAIL PROTECTED] writes:
 Nate Lawson [EMAIL PROTECTED] writes:
  cc -O -c -O -pipe -mcpu=pentiumpro -mcpu=pentiumpro -I./../include
  -I./.. -DDIRENT=1 -DDIRENT=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1
  -DHAVE_FCNTL_H=1 -DHAVE_ST_RDEV=1 -DHAVE_TM_ZONE=1
  -DHAVE_LONG_FILE_NAMES=1 -DHAVE_RESTARTABLE_SYSCALLS=1 -D_ANSI_SOURCE
  -DHAVE_DEV_CONSOLE=1 os.c
  In file included from os.c:25:
  /usr/include/sys/file.h:130: syntax error before u_int
  
   u_int is undocumented and unportable, so it probably shouldn't be
   used.  It's only 3 characters shorter than `unsigned' anyway.
  
  It's for ports.
 
 I fixed a port like this recently.  _ANSI_SOURCE was actually added by
 the port, not the application vendor, in that case.

Wait a minute, I think this might be the same port.  Is it gnu-finger?
If so, try the attached patch.  Kris was going to commit it for me.

Best regards,
Mike Barcroft

Index: files/patch-aa
===
RCS file: /work/repo/ports/net/gnu-finger/files/patch-aa,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 patch-aa
--- files/patch-aa  10 Jul 1996 22:33:13 -  1.1.1.1
+++ files/patch-aa  30 Nov 2002 15:55:31 -
@@ -1,6 +1,6 @@
 configure.orig Fri Oct 16 06:49:05 1992
-+++ configure  Mon Jul  8 19:39:32 1996
-@@ -1041,8 +1041,10 @@
+--- configure.orig Thu Oct 15 17:49:05 1992
 configure  Sat Nov 30 10:55:20 2002
+@@ -1041,8 +1041,8 @@
  

echo checking for /proc file system
@@ -8,12 +8,10 @@
 -  fi
 +# if test -r /proc ; then DEFS=$DEFS -DHAVE_PROC_FS=1
 +# fi
-+
-+  DEFS=$DEFS -D_ANSI_SOURCE

  

-@@ -1071,8 +1073,9 @@
+@@ -1071,8 +1071,9 @@

  

Index: files/patch-ab
===
RCS file: /work/repo/ports/net/gnu-finger/files/patch-ab,v
retrieving revision 1.3
diff -u -r1.3 patch-ab
--- files/patch-ab  6 Jan 1997 14:09:34 -   1.3
+++ files/patch-ab  30 Nov 2002 16:03:57 -
@@ -1,7 +1,10 @@
 lib/os.c.orig  Mon Jan  6 22:09:06 1997
-+++ lib/os.c   Mon Jan  6 22:08:34 1997
-@@ -26,6 +26,8 @@
+--- lib/os.c.orig  Thu Oct 22 17:01:10 1992
 lib/os.c   Sat Nov 30 11:03:54 2002
+@@ -24,8 +24,11 @@
+ #include sys/stat.h
+ #include sys/file.h
  #include sys/acct.h
++#include errno.h
  #include time.h
  #include packet.h
 +#include sys/socket.h
@@ -9,7 +12,7 @@
  
  #ifdef HAVE_UTMPX_H
  #include utmpx.h
-@@ -70,8 +72,12 @@
+@@ -70,8 +73,12 @@
  
  /* Where the utmp file is located. */
  #ifndef HAVE_GETUTENT
@@ -22,7 +25,25 @@
  
  /* A non-null value is the address of the utmp entry which contains the
 information for the user using the console. */
-@@ -288,6 +294,21 @@
+@@ -210,15 +217,12 @@
+ 
+   if (!(hostname = xgethostname ()))
+ {
+-  extern int errno;
+-  extern char *sys_errlist[];
+-
+   /* Arbitrary limit: we only return the first 128 characters of
+an error. This limit would be too complicated to remove. */
+   static char hostname_error[128];
+ 
+-  strncpy (hostname_error, sys_errlist[errno],
+- sizeof hostname_error);
++  if (strerror_r(errno, hostname_error, sizeof hostname_error))
++strcpy(hostname_error, Unknown error);
+   hostname = hostname_error;
+ }
+ 
+@@ -288,6 +292,21 @@
  {
idle = current_time - get_last_access (utmplist[i]-ut_line);
  
@@ -44,7 +65,7 @@
if (idle  0)
idle = 0;
  
-@@ -485,6 +506,7 @@
+@@ -485,6 +504,7 @@
  
UTMP **result;
int result_size = 0;
@@ -52,7 +73,7 @@
  
  #ifndef HAVE_GETUTENT
file = open (UTMP_FILE, O_RDONLY);
-@@ -528,6 +550,26 @@
+@@ -528,6 +548,26 @@
if (!UT (entry, ut_name)[0])
continue;
  #endif /* sun */
Index: files/patch-error.c
===
RCS file: files/patch-error.c
diff -N files/patch-error.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ files/patch-error.c 30 Nov 2002 15:52:45 -
@@ -0,0 +1,52 @@
+--- lib/error.c.orig   Thu Oct  1 14:55:04 1992
 lib/error.cSat Nov 30 10:52:14 2002
+@@ -23,6 +23,7 @@
+ #include config.h
+ #include general.h
+ #include error.h
++#include errno.h
+ 
+ /* These can be filled in `manually' by callers, but the easiest way
+is to call default_error_handling (argv[0]). */
+@@ -50,11 +51,14 @@
+ exit (1);
+ }
+ 
++/* XXX conflicts with system function by the same name. */
++#if __FreeBSD__  5
+ /* Hack to handle previous bad setjmp (). */
+ longjmperror ()
+ {
+   exit (1);
+ }
++#endif
+ 
+ /* Handle some error. */
+ void
+@@ -92,24 +96,10 @@
+  int severity;
+  char *filename;
+ {
+-  extern int errno, sys_nerr;
+-  extern char *sys_errlist[];
+-
+-  char *error_text;
+-
+-  if (errno) {
+-if (errno  sys_nerr)
+-  error_text = sys_errlist[errno];
+-else

Re: RC NG, ntp and routed

2002-12-12 Thread Mike Makonnen
On Thu, Dec 12, 2002 at 08:09:24AM -0200, Daniel C. Sobral wrote:
 
 I mean that routed is _one_ routing daemon, one that supports the old, 
 would someone please shot it in the head to give it peace, RIP. If you 
 happen to run a modern routing protocol... hell, if you happen to run a 
 middle-aged routing protocol, you'll be using something else.
 
 And, since you do not seem to be aware of it, Zebra, for one, is run as...
 
 router_enable=YES
 router=/usr/local/sbin/zebractl
 router_flags=start
If you are using a daemon essential to network connectivity in /usr/local
and at the same time have it (/usr/local) mounted remotely, then you haven't
thought things through properly.

Listen, I think we're talking past each other here. I _am_ in favour of
adding routing to NETWORKING (look at an earlier email in the thread).
My only argument is that if an admin chooses to use a daemon
from ports then he should be bright enough to
include it in a local filesystem.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48610/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-11 Thread Mike Makonnen
On Wed, Dec 11, 2002 at 08:17:50AM +0100, Brad Knowles wrote:
 
   I believe that DISKS should be split into DISKS_LOCAL and 
 DISKS_NETWORK.  This allows us to get NETWORKING going after 
 DISKS_LOCAL and before DISKS_NETWORK. 

Don't over-engineer it. This is the order it is done in now.
The barier scripts are supposed to be major milestones. With your
suggestion DISKS_{LOCAL,NETWORK) would each have _only_ one
dependency (mountcritlocal and mountcritremote, respectively), so
what would be the point then?

 We may also want to split 
 NETWORKING into INTERFACES and ROUTING (and higher level networking), 
 in case there is anything that we might need to slide in-between.  We 
 might even need to split NETWORKING into three parts.

I think the current barrier scripts plus Gordon's suggestion to
include routing in NETWORKING works ok. However, improvements
to /etc/rc.d/network1 to allow bringing up/down the interfaces
individually would be nice.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48512/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-11 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 10:33:48PM -0800, Gordon Tetlow wrote:
  That sounds like a good idea. According to current NETWORKING requirements it
  just means the network interfaces are brought up, but routing seems to be a
  reasonable requirement as well. I can't think of a good reason why it would
  not be a good idea. Maybe we could move the other routing daemons
  there as well (from /usr/sbin)? 
 
 Well, there in lies the chicken and the egg problem (and why I've been
 cursing rcng recently). /usr is mounted after networking so all the things
 that implictly require /usr must be run after networking is setup (but what
 about things like route6d that is in /usr/sbin?)

You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin.
I think if we have routed there we might as well have the others there. Actually we
only need to move route6d to /sbin. I can't think of a reason you would need
multicast routing before the whole system was up. I think we can live with and
additional 42k on /.

 
 IMO rc.d should have the following major catagories:
 
 DISKS
 FILESYSTEMS
 NETWORKING
 DAEMON
 LOGIN
 
I don't see the need for FILESYSTEMS. As it is we only have two scripts
mountcritlocal and mountcritremote. And since network mounted filesystems
are quite common any script that needs FILESYSTEM is simply going to
have to wait until NETWORKING is up. There's no way we can get around that.

 NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also
 describes a SERVERS catagory that I don't really understand the need for.

Basicaly it's for daemons that you need running as early as possible, like
syslogd. Other services are going to need them, but you can't really fit them
in the other categories.

 
 I'd like to think about really sitting down and overhauling the rc.d
 system after 5.0 is branched. I think that it's reasonable to say we
 should not try to be compatible with NetBSD except for keeping a common
 rc.subr and major initialization catagories (basically anything that is
 in all caps). Does anyone have a problem with dyking out the NetBSD
 specific portions after 5.0?

I was quite a ways through porting our scripts when David insisted that they
be compatible with NetBSD in order to make it into the tree. It took quite
a bit more work to restart almost from the beginning and redo them. And I
would hate to see that work go to waste. So, I'm not an impartial party
here and won't say anymore about it except to say that I think being in
sync with NetBSD is a worthwhile and doable goal if we (both projects) make a
firm commitment to do it. This means that we wouldn't be slavishly accepting
NetBSD code, but that the projects would work the differences out so that the only
differences left would be because of architectural differences between the
two OSes.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48516/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-11 Thread Mike Makonnen
On Wed, Dec 11, 2002 at 09:16:27AM -0200, Daniel C. Sobral wrote:
 
 Mm. How about ntpd running in multicast mode? :-)

Hah! I  knew I should have checked that before I opened my mouth.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48525/pgp0.pgp
Description: PGP signature


Re: __BSD_VISIBLE and u_int

2002-12-11 Thread Mike Barcroft
Nate Lawson [EMAIL PROTECTED] writes:
 What's the proper way to get a typedef for u_int?  Is there a doc
 somewhere on what we expect in terms of #defines for 3rd party application
 authors?

sys/types.h will give you a typedef, provided you aren't writing a
POSIX or X/Open application.  If you're writing a POSIX or X/Open
application (the only time __BSD_VISIBLE is false) you'll have to do
the typedef manually in your application.

u_int is undocumented and unportable, so it probably shouldn't be
used.  It's only 3 characters shorter than `unsigned' anyway.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: RC NG, ntp and routed

2002-12-11 Thread Mike Makonnen
On Wed, Dec 11, 2002 at 03:28:12PM -0200, Daniel C. Sobral wrote:
 
 [root@piratinga root]# ls -l /usr/local/sbin/ospfd
 -r-xr-xr-x  1 root  wheel  471392 Dec  1 00:58 /usr/local/sbin/ospfd*
 [root@piratinga root]# ls -l /usr/local/sbin/bgpd
 -r-xr-xr-x  1 root  wheel  691952 Dec  1 00:58 /usr/local/sbin/bgpd*

Who said anything about moving ports into /? I meant the routing
daemons in /usr/sbin. But as Gordon pointed out that's still
quite a bit of disk space.

 
 And all this because... people don't want to break fs mounting in local 
 and remote?
 
 I saw break it, and have routing run after local. If your /usr is 
 remote, then either you'll copy routed (or whatever you use) to a local 
 disk, or you won't be using it.
 
 People, let's face it. There *ARE* things you want to be run *after* 
 local fs mount and *before* remote fs mount. And we are hurting 
 ourselves in a few places just because we haven't admitted to it.

I don't understand what you are saying. Why would we have routing run after
local filesystems are mounted but before the network is up?

 
 btw, someone mentioned a freebsd-rc list, but I found no such list. 
 Mispelling? Not freebsd.org list? Delusions?

Yahoo! .

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48580/pgp0.pgp
Description: PGP signature


Re: RCng -- docs and whatnot?

2002-12-11 Thread Mike Makonnen
man 8 rc
man 8 rc.subr

-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48581/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-11 Thread Mike Makonnen
On Wed, Dec 11, 2002 at 10:11:18PM -0800, Doug Barton wrote:
 On Wed, 11 Dec 2002, Mike Makonnen wrote:
 
  I don't understand what you are saying. Why would we have routing run after
  local filesystems are mounted but before the network is up?
 
 What if /usr/local is an nfs-mounted partition (like it is on my systems,
 both at home and work)?

I still don't see how having the routing daemon start before the network
interfaces come up helps you. The correct order seems to me: 
local filesystem, network, routing, remote filesystem. Am I missing something
here?

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48584/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-10 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote:
 On another note, I thought the patch a bit excessive. Here, I just added 
 BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more.

It's not excessive. It's the correct solution. 
Your solution solves your specific problem but it's
not the right way to go about solving the problem. It's kind of hard to
explain, you have to work with it for a while to get the hang of it. For
some things it might be easier _and_ right to say this must come before
that. In this case; however,  ntpd requires that routing be available as a 
prerequisite, but there's no real relationship that exists between
the two that necessitates routed having to know about ntpd. If we were
to follow your example to its logical conclusion the BEFORE line for
the routing daemons would have to include _every_ daemon that requires
network availability. I think in this case it would be more correct to
have the network daemons REQUIRE the routing daemons. Does that make
sense?

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48487/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-10 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 08:22:08AM -0800, Gordon Tetlow wrote:
 
 I think keeping our boot scripts the same is kind of a pipe dream. I think
 we should keep our rc.subr the same, but for individual scripts, I think we
 should just go our own way.

I can see how keeping every we possibly can the same can make things
easier and I'm in favor of it. What I don't like is this stradling the
middle business. It's all or nothing. We can't keep some things in
sync and others not because the parts make up the whole. If we
change some parts that's going to affect other parts, which in turn
is going to affect the whole. This is really frustrating sometimes.

So, in short: Please let's pick a path and follow it whole-heartedly! 

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48488/pgp0.pgp
Description: PGP signature


Re: SCM Microsystems Inc. eUSB SmartMedia Adapter

2002-12-10 Thread Mike Tancsa

Are you sure you have all the bits in your kernel that are needed ?
i.e
   device umass
   device scbus
   device da
   device pass


In mine, I have

# usbdevs -v
Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev
1.00
 port 1 addr 2: power 100 mA, config 1, ImageMate CF-MS (0x0820),
SanDisk(0x0781), rev 0.12
 port 2 addr 3: power 100 mA, config 1, eUSB CompactFlash Adapter(0x000a),
SCM Microsystems Inc.(0x04e6), rev 2.18
Controller /dev/usb1:
addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev
1.00
 port 1 powered
 port 2 powered

da1 at umass-sim0 bus 0 target 1 lun 0
da1: eUSB Compact Flash  Removable Direct Access SCSI-2 device 
da1: 650KB/s transfers
da1: 61MB (125440 512 byte sectors: 64H 32S/T 61C)

---Mike

On Tue, 10 Dec 2002 22:13:49 -0500, in sentex.lists.freebsd.current you
wrote:

Hey everyone,
   I have a question, when i try to plugin my eUSB SmartMedia USB 
adapter, umass doesnt recognize it. Darius over at #freebsdhelp@efnet 
suggested me to send a mail to the questions/current mailing lists. 
Thanks to him :). When i plug in my Adapter, in my dmesg it states:

ugen0: SCM Microsystems Inc. eUSB SmartMedia Adapter, rev 1.10/2.18, addr 2

When i unplug it, it reports:

ugen0: at uhub0 port 1 (addr 2) disconnected
ugen0: detached

Any suggestions? Any help is appreciated, thanks in advance.

Cheers,

Brad Hughes
[EMAIL PROTECTED]

Mike Tancsa  ([EMAIL PROTECTED])  
http://www.sentex.net/mike

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: RC NG, ntp and routed

2002-12-10 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 04:23:18PM -0800, Gordon Tetlow wrote:
 
 Ideally, ntpd should require NETWORKING and that should solve all problems.
 The real problem is that routed is included with DAEMON, not NETWORKING. I
 think that's the real problem and judging that routed is in /sbin, we could
 probably move it there without a problem.

That sounds like a good idea. According to current NETWORKING requirements it
just means the network interfaces are brought up, but routing seems to be a
reasonable requirement as well. I can't think of a good reason why it would
not be a good idea. Maybe we could move the other routing daemons
there as well (from /usr/sbin)? 

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48503/pgp0.pgp
Description: PGP signature


Re: Confused by mpd and ipnat

2002-12-09 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 12:06:21AM +0800, leafy wrote:

 map ng0 192.168.0.0/24 - 0/32

 When I reboot, this line (along with ipnat stuff) got executed before mpd
 fiinishes PPPoE negotiation, and ipnat -l shows that the ng0 ip was 0.0.0.0/32.
 Is there anyway I can ensure that ipnat -f /etc/ipnat.rules get executed
 only after mpd has obtained proper ip settings?

Does mpd install a startup script in /usr/local/etc/rc.d ? Does it get started
in the background? If it's script is in /usr/local/etc/rc.d then it gets
run by the /etc/rc.d/local script which runs after /etc/rc.d/ipnat. In this
case you can simply re-apply the rules after the negotiation is completed:
/etc/rc.d/ipnat reload

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48442/pgp0.pgp
Description: PGP signature


Re: RC NG, ntp and routed

2002-12-09 Thread Mike Makonnen
[ cc'd some more people on this ]

On Mon, Dec 09, 2002 at 11:23:58AM -0200, Daniel C. Sobral wrote:
 I suggest that routed be specified as being BEFORE ntpd. In the absence 
 of a route to the specified servers, ntpd has the annoying behavior of 
 chosing the address of lo0 as the source address for ntp requests, 
 resulting in all sorts of problems.

Yeah, makes sense. It also worked like that (correctly, that is) in rc.network.

 
 I do see one contraindication to this behavior. Most routing protocols 
 also react badly to time changes. Egg and chicken problem, but, 
 personally, and running OSPF, which is one of those protocols that react 
 badly to time changes, I find it preferably to run the router first. 
 After all, having ntpd using 127.0.0.1 as source is useless to me.

The following patch should solve your problem. However,
it's only a partial solution. It fixes the case for ntpd
and ntpdate but not for other network daemons like rpcbind, which still get
started _before_ the routing daemons. I haven't included patches for
those because sorting out the dependencies is going to be a bit more
involved. I'll have it done when I get a chance later this week.
(A consequence of this is going to be that we will be moving *away* from
 NetBSD in the dependency ordering, but we can sort that out with them later).

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9

Index: etc/rc.d/ntpd
===
RCS file: /home/ncvs/src/etc/rc.d/ntpd,v
retrieving revision 1.5
diff -u -r1.5 ntpd
--- etc/rc.d/ntpd   2002/10/12 10:31:31 1.5
+++ etc/rc.d/ntpd   2002/12/10 02:09:05
@@ -5,7 +5,7 @@
 #
 
 # PROVIDE: ntpd
-# REQUIRE: DAEMON
+# REQUIRE: DAEMON routed route6d mrouted mroute6d ntpdate
 # BEFORE:  LOGIN
 # KEYWORD: FreeBSD NetBSD
 
Index: etc/rc.d/ntpdate
===
RCS file: /home/ncvs/src/etc/rc.d/ntpdate,v
retrieving revision 1.4
diff -u -r1.4 ntpdate
--- etc/rc.d/ntpdate2002/10/12 10:31:31 1.4
+++ etc/rc.d/ntpdate2002/12/10 02:09:05
@@ -5,7 +5,8 @@
 #
 
 # PROVIDE: ntpdate
-# REQUIRE: NETWORKING syslogd
+# REQUIRE: DAEMON routed route6d mrouted mroute6d
+# BEFORE:  LOGIN
 # KEYWORD: FreeBSD NetBSD
 
 . /etc/rc.subr
Index: etc/rc.d/rpcbind
===
RCS file: /home/ncvs/src/etc/rc.d/rpcbind,v
retrieving revision 1.6
diff -u -r1.6 rpcbind
--- etc/rc.d/rpcbind2002/09/06 16:18:05 1.6
+++ etc/rc.d/rpcbind2002/12/10 02:09:05
@@ -5,7 +5,7 @@
 #
 
 # PROVIDE: rpcbind
-# REQUIRE: NETWORKING ntpdate syslogd named ppp
+# REQUIRE: NETWORKING syslogd named ppp
 # KEYWORD: FreeBSD NetBSD
 
 . /etc/rc.subr



msg48443/pgp0.pgp
Description: PGP signature


Re: Confused by mpd and ipnat

2002-12-09 Thread Mike Makonnen
On Tue, Dec 10, 2002 at 11:24:59AM +0800, leafy wrote:
 I finally got over this one. The problem is that mpd needs a very long time
 for PPPoE negotiation, thus if we run ipnat reload before it's settled, that
 will be totally useless. So I moved the mpd startup script to
 PREFIX/etc/rc.d/000.mpd.sh and the ipnat reload in zzz.ipnat_reload.sh and
 VIOLA!
 
 Putting them in the same script does not work, maybe this could be improved?

How could this not work? Are you starting it in the background? Must be.
I'm assuming that you don't want to run them serially
because it would take too long to startup your system so you use some sort
of mechanism (like the -background option to ppp(8)) to run it in the background.
I would suggest that you do something like this:
( mpd -foreground; /etc/rc.d/ipnat reload ) 

... unless it is not possible for some reason.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg48446/pgp0.pgp
Description: PGP signature


Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
Marc Recht [EMAIL PROTECTED] writes:
 Hi!
 
 While compiling some third-party code I got this:
 gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 
 -D_XOPEN_SOURCE_EXTENDED=1 test.c
 In file included from test.c:2:
 /usr/include/sys/file.h:130: syntax error before u_int
 
 This makes me wonder a bit.. Shouldn't the header at least be includeable ? 
 Eg. setting __BSD_VISIBLE around xfile ?
 
 Test source:
 
 #include sys/types.h
 #include sys/file.h
 
 int main() {
return 0;
 }

Why are you specifying a standard and then using features outside its
scope?  Either you want a BSD environment (in which case don't specify
a standard), or you want a standard environment (where file.h doesn't
exist).  Indeed what you are trying to do is unsupported.

For details on how to write a conforming application see section 2.2
of POSIX.1-2001.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
[CC'd port's maintainer.]

Vasyl S. Smirnov [EMAIL PROTECTED] writes:
 On Sun, Dec 08, 2002 at 01:17:15PM +0100, Marc Recht wrote:
  Hi!
  
  While compiling some third-party code I got this:
  gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE_=600 
  -D_XOPEN_SOURCE_EXTENDED=1 test.c
  In file included from test.c:2:
  /usr/include/sys/file.h:130: syntax error before u_int
  
  This makes me wonder a bit.. Shouldn't the header at least be includeable ? 
  Eg. setting __BSD_VISIBLE around xfile ?
 
 The same thing with sys/vmmeter.h
 
 My previous post about bubblemon-dockapp build failure was actually about this
 missing header sys/types.h

No, this is a completely different issue.  This port specifies no
standards.  This port depended on one of the headers it included to
include sys/types.h.  I'm not sure which header change caused this,
but it was a bad assumption on the application writer's part.  The
attached patch fixes the problem with the port.

Best regards,
Mike Barcroft

--- sys_freebsd.c.orig  Sun Dec  8 10:57:14 2002
+++ sys_freebsd.c   Sun Dec  8 10:56:19 2002
@@ -17,6 +17,7 @@
  *
  */
 
+#include sys/types.h
 #include kvm.h
 #include fcntl.h
 #include sys/dkstat.h



Re: sys/file.h and POSIX

2002-12-08 Thread Mike Barcroft
Marc Recht [EMAIL PROTECTED] writes:
 The standard is specified to get the standard functions. Eg. if i specify 
 _POSIX_C_SOURCE=200112L then I want (for example) POSIX's flockfile, if the 
 OS supports POSIX. This doesn't mean that I don't want rpc. This means that 
 I need to change third party code, which needs POSIX functions, not to 
 declare POSIX/POSIX_C_SOURCE/XSI to get BSD/other functions (and inderectly 
 the POSIX 200112 functions).

Again, I'll point you at section 2.2 of POSIX.1-2001:

: 2.2.1 Strictly Conforming POSIX Application
:
: A Strictly Conforming POSIX Application is an application that
: requires only the facilities described in IEEE Std 1003.1-2001.
[...]

A conforming application cannot make use of facilities outside the
scope of the standard.  This means that if you define
_POSIX_C_SOURCE=200112L you don't want RPC.

 Since it isn't that way on any UNIX (at least I know about) vendors are 
 forced to do special treatment for FreeBSD. Which is IMHO really bad and 
 may lead to less support for FreeBSD.

4.4BSD (and earlier?) and most derived systems have many conditionals
to prevent namespace pollution in the standards-case.

So why do we do this?  To prevent screwage of perfectly valid
applications that use the same keywords as system extentions to the
standard.  For instance, the major() macro in sys/types.h is a very
common and likely to be used word, so it is not defined in the
standards case to prevent POSIX applications that define a different
major() macro from failing to compile.

 IMHO this is bad and breaks compilation of much third-party code.

Not really.  Conforming applications have no trouble (obviously),
pseudo-conforming applications only need a little work (removing bogus
POSIX keywords that specify conformance), and non-conforming BSD
applications (the majority of software) have no problems.

 I've read/looked at the standard (see my posting to standards@) and I don't 
 think it forces FreeBSD's behaviour. I even think FreeBSD's behaviour isn't 
 the spirit of the standard.

FreeBSD's behaviour is consistent with BSD's behaviour.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: The great perl script rewrite - progress report

2002-12-02 Thread Mike Makonnen
On Mon, Dec 02, 2002 at 12:00:27AM -0500, Robert Watson wrote:
 Base system perl-based tools added to the TODO list.  We need to deal with
 these ASAP. 
 

I have already submitted adduser/rmuser to Mark.
http://www.identd.net/~mtm/adduser.tar.gz

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg47962/pgp0.pgp
Description: PGP signature


sparc64 tinderbox failure

2002-11-29 Thread Mike Barcroft
Fri Nov 29 09:15:00 GMT 2002
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
FAIL: Test failed: regression detected.  See above.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.

--
 Upgrading the installed make
--
install: /usr/bin/make: Text file busy
*** Error code 71

Stop in /tinderbox/sparc64/src/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-29 Thread Mike Barcroft
Fri Nov 29 15:15:00 GMT 2002
U share/man/man3/stdarg.3
U share/man/man4/ata.4
U share/man/man4/dummynet.4
U share/man/man4/ipfirewall.4
U share/man/man4/ktr.4
U share/man/man4/stf.4
U share/man/man4/tap.4
U share/man/man4/tcp.4
U share/man/man4/umass.4
U share/man/man4/usb.4
U share/man/man5/device.hints.5
U share/man/man5/drivers.conf.5
U share/man/man5/fs.5
U share/man/man5/make.conf.5
U share/man/man5/passwd.5
U share/man/man5/rc.conf.5
U share/man/man5/remote.5
U share/man/man7/clocks.7
U share/man/man7/firewall.7
U share/man/man7/hier.7
U share/man/man7/tuning.7
U share/man/man8/rc.8
U share/man/man8/rc.sendmail.8
U share/man/man9/VOP_IOCTL.9
U share/man/man9/VOP_LINK.9
U share/man/man9/VOP_RENAME.9
U share/man/man9/ifnet.9
U share/man/man9/mbuf.9
U share/man/man9/random.9
U share/man/man9/style.9
U share/man/man9/swi.9
U share/man/man9/zone.9
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
FAIL: Test failed: regression detected.  See above.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.

--
 Upgrading the installed make
--
install: /usr/bin/make: Text file busy
*** Error code 71

Stop in /tinderbox/sparc64/src/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-29 Thread Mike Barcroft
Fri Nov 29 21:15:00 GMT 2002
U games/factor/factor.6
U lib/libc/gen/fts.3
U lib/libc/locale/iswalnum.3
U lib/libc/locale/mbrlen.3
U lib/libc/locale/mbrtowc.3
U lib/libc/locale/mbsinit.3
U lib/libc/locale/mbsrtowcs.3
U lib/libc/locale/towlower.3
U lib/libc/locale/towupper.3
U lib/libc/locale/utf8.5
U lib/libc/locale/wcrtomb.3
U lib/libc/locale/wcsftime.3
U lib/libc/locale/wcsrtombs.3
U lib/libc/locale/wcstod.3
U lib/libc/locale/wcstol.3
U lib/libc/locale/wctrans.3
U lib/libc/locale/wctype.3
U lib/libc/locale/wcwidth.3
U lib/libc/net/rcmd.3
U lib/libc/stdio/fseek.3
U lib/libc/stdlib/atexit.3
U lib/libc/stdlib/insque.3
U lib/libc/stdlib/qsort.3
U lib/libc/stdlib/strfmon.3
U lib/libc/string/strcpy.3
U lib/libc/string/strsep.3
U lib/libc/sys/intro.2
U lib/libc/sys/kse.2
U lib/libc/sys/pathconf.2
U lib/libc/sys/sigaction.2
U lib/libc/sys/sigprocmask.2
U lib/libc/sys/socketpair.2
U lib/libc/sys/uuidgen.2
U lib/libcompat/4.3/rexec.3
U lib/libpam/modules/pam_radius/pam_radius.8
U lib/libpam/modules/pam_wheel/pam_wheel.8
U lib/libtacplus/libtacplus.3
U libexec/rtld-elf/rtld.c
U share/man/man4/cardbus.4
U share/man/man4/pccard.4
U sys/cam/scsi/scsi_da.c
U sys/ia64/ia64/pmap.c
U sys/ufs/ffs/ffs_vfsops.c
U usr.sbin/getfmac/getfmac.8
U usr.sbin/setfmac/setfmac.8
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
FAIL: Test failed: regression detected.  See above.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.

--
 Upgrading the installed make
--
install: /usr/bin/make: Text file busy
*** Error code 71

Stop in /tinderbox/sparc64/src/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Make regression tests and 4.x cross-builds

2002-11-29 Thread Mike Barcroft
Kris Kennaway [EMAIL PROTECTED] writes:
 I'm cross-building 5.0 on 4.x, and I get the following:
 
 bento# make buildworld -j4
 Running test variables
 PASS: Test variables detected no regression, output matches.
 Running test targets
 PASS: Test targets detected no regression.
 Running test sysvmatch
 PASS: Test sysvmatch detected no regression.
 Running test lhs_expn
 FAIL: Test failed: regression detected.  See above.
 *** Error code 1
 1 error
 *** Error code 2

The sparc64 tinderbox is running a stale world (about 3 months old),
so it's hitting the same problem.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Problem pulling particular directory from CVS

2002-11-29 Thread Mike Bristow

On Wednesday, November 27, 2002, at 11:34  pm, Paul A. Scott wrote:

Oh, #$%@. I'm so embarrassed. My terminal session was logged into Mac 
OSX
not FreeBSD, and I had mirrored the same directory structure, so I faked
myself out.

Bottom line is, cvs on Freebsd works like a champ. The cvs on MacOSX 
does
not. My mistake. And I humbly appolgize for the stupid user error.

CVS works just fine - it's just that the filesystem is case insensitive 
[1],
so when you check out src/contrib, the distinction between 
src/contrib/CVS [2]
src/contrib/cvs is lost, and Bad Shit happens.

Try using Disk Copy to setup and mount a blank (UFS) image, or having a 
separate
UFS partition.

[1] Unless your filesystem is UFS, rather than HFS+, in which case 
you'll have
lots of interesting other problmes.
[2] CVS keeps a shedload of metadata here

--
Am I getting older, or are these shows getting more entertaining?
-- Flash, on Children in Need.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message


systat -vmstat reports alternate system clock has died!

2002-11-28 Thread Mike Durian
I've filed a bug report on this
http://www.freebsd.org/cgi/query-pr.cgi?pr=45684
but was wondering if anyone else had seen this message on an SMP machine.
Is it a known problem with a know work around?  I'm running code from
11/24/02.  Load averages and related things also read 0.

You can find my dmesg output in the bug report.

mike


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-28 Thread Mike Barcroft
Thu Nov 28 21:15:00 GMT 2002
U lib/libc/net/if_nametoindex.c
U sys/sys/select.h
U sys/sys/signal.h
U tools/regression/usr.bin/make/Makefile
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
FAIL: Test failed: regression detected.  See above.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.

--
 Upgrading the installed make
--
install: /usr/bin/make: Text file busy
*** Error code 71

Stop in /tinderbox/sparc64/src/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-28 Thread Mike Barcroft
Fri Nov 29 03:15:00 GMT 2002
U lib/libpam/modules/pam_ksu/pam_ksu.c
U release/doc/en_US.ISO8859-1/early-adopter/article.sgml
Running test variables
PASS: Test variables detected no regression, output matches.
Running test targets
PASS: Test targets detected no regression.
Running test sysvmatch
PASS: Test sysvmatch detected no regression.
Running test lhs_expn
PASS: Test lhs_expn detected no regression.
Running test notdef
PASS: Test notdef detected no regression.
Running test modifiers
PASS: Test modifiers detected no regression.
Running test funny_targets
FAIL: Test failed: regression detected.  See above.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src/tools/regression/usr.bin/make.

--
 Upgrading the installed make
--
install: /usr/bin/make: Text file busy
*** Error code 71

Stop in /tinderbox/sparc64/src/usr.bin/make.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5

2002-11-27 Thread Mike Makonnen
On Wed, Nov 27, 2002 at 02:08:40AM +0300, Sergey Mokryshev wrote:
 
 Yes, I don't see these errors. But some scripts can change execution order
 without anchors like mountall
 
 For example, adding ldconfig dependancy directly into named brings
 this order:
 
 root@girvas-gw:/etc/rc.d# rcorder -k FreeBSD -s nostart * 2/dev/null
 ldconfig
 initdiskless
 initrandom
 dumpon
 vinum
 
 
 
 Isn't this wrong?

I'm not in front of a -current box right now so I can't test it, but
generally if you change the default order of the scripts you _may_ need to
modify one or more BEFORE or REQUIRE lines. That's what they are there
for after all.

Cheers.
-- 
Mike Makonnen   [EMAIL PROTECTED]
GPG Key-ID: 0xDBCC68B9   GPG-KEY: http://www.identd.net/~mtm/mtm.asc
Key fingerprint = D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg47596/pgp0.pgp
Description: PGP signature


Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5

2002-11-27 Thread Mike Makonnen
On Thu, Nov 28, 2002 at 01:31:26AM +0300, Sergey Mokryshev wrote:
[ snip ]

 ldconfig does not have proper anchor and is mistakenly ordered to run
 first (without any filesystems mounted (except R/O root) yet).

This is a good example of why I didn't support the removal of the NetBSD
scripts when it was done. However, I can also understand Gordon't point
of view and why he removed them: namely, because of rc.d bloat, confusing users,
and the implied suggestion that we support those scripts on our platform (correct
me if I'm wrong Gordon).


 * So I'm complaining mostly about removing files without fixing
 dependencies in the remaining scripts *

 Probably the best solution is to backout rev 1.5 of
 src/etc/rc.d/Makefile. It was tested before 5.0-DP2 and it just
 works.

The dependencies are fine for the default order. I don't think there
was any implicit or explicit guarantee that if you changed the order things
wouldn't break. For your particular situation I think the following will
give the desired order:
1. Leave rc.d/named alone
2. Modify rc.d/ldconfig :
# REQUIRE: SERVERS
# BEFORE: named


Cheers.
-- 
Mike Makonnen   [EMAIL PROTECTED]
GPG Key-ID: 0xDBCC68B9   GPG-KEY: http://www.identd.net/~mtm/mtm.asc
Key fingerprint = D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg47653/pgp0.pgp
Description: PGP signature


Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5

2002-11-26 Thread Mike Makonnen
These are benign. Those scripts are used by NetBSD only.
You don't see the errors on boot because of a 2/dev/null in /etc/rc.

Cheers.
-- 
Mike Makonnen   [EMAIL PROTECTED]
GPG Key-ID: 0xDBCC68B9   GPG-KEY: http://www.identd.net/~mtm/mtm.asc
Key fingerprint = D228 1A6F C64E 120A A1C9  A3AA DAE1 E2AF DBCC 68B9



msg47550/pgp0.pgp
Description: PGP signature


Re: select.h problem / posix / patch

2002-11-25 Thread Mike Barcroft
Marc Recht [EMAIL PROTECTED] writes:
 Hi!
 
 Following test programm
[...]
 
 gives me:
 x.c: In function `main':
 x.c:9: structure has no member named `fds_bits'
 
 when compiled with:
 gcc -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 
 -D_XOPEN_SOURCE_EXTENDED=1 x.c
 
 The attached patch fixes that, though I'm not quite sure if it's correct.

It needs a similar change for FD_CLR().  I'll get this fixed; thanks
for the patch.

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: Searching for users of netncp and nwfs to help debug 5.0 problems

2002-11-23 Thread Mike Barcroft
Nate Lawson [EMAIL PROTECTED] writes:
 On Sat, 23 Nov 2002, Brad Knowles wrote:
  At 2:31 PM -0800 2002/11/22, Terry Lambert wrote:
  
A bug-filing wizard would be useful.  The send-pr system
doesn't cut it, and most people are unaware of how to file a
decent bug report.  It doesn't help when the process involves
another computer, a serial cable, recompiling a kernel to use
a serial console and turn DDB support on, special configuration
for system dump images, and changing the size of your swap
partition to support the amount of RAM you have put into the
machine.
  
  Speaking as someone who is about to step off the deep end and 
  start trying to actually run and test -CURRENT on my system here at 
  home, I believe that this kind of resource would be vitally important.
  
  In contrast, I've had a few crashes this past week from other 
  programs here on my PowerBook G4 running MacOS X (primarily Chimera, 
  based on the Mozilla Gecko engine with native Aqua interface), and 
  they have made it very easy for me to report crashes.  They have 
  integrated tools to extract the maximum amount of information from 
  the system as to exactly what other programs were running, what the 
  program stack was, and a whole host of other things.  All I have to 
  do is type in my e-mail address, optionally describe what I was 
  trying to do at the time, and have a functioning Internet connection 
  so that they can upload the reports.  I'd share some examples with 
  you, but they are *huge*.
 
 For a while, there was a discussion about starting this capability with
 panic() reporting a stack trace.  I believe someone even did some
 implementation work.  Any ideas where this stands?

John Baldwin implemented something like this, but you need DDB
compiled in for it to work.  And if you have DDB compiled in, how hard
is it to type `trace'?

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: No entries in /proc :: feature or problem ??

2002-11-22 Thread Mike Barcroft
Dhee Reddy [EMAIL PROTECTED] writes:
 Hello all.
Just tried to look up some info and saw that the /proc filesystem doesn't
contain any files.
Shouldn't they contain entries correcponding to all the processes ?
 truely

This question was just asked a few days ago (yesterday?).  By default,
/proc is no longer mounted.  To reenable it (not recommended for
production systems because of procfs' poor security record) add the
following line to fstab:
proc/proc   procfs  rw  0   0

and run:
mount /proc

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-21 Thread Mike Barcroft
Thu Nov 21 15:15:00 GMT 2002
U MAINTAINERS
U include/Makefile
U secure/lib/libcrypto/Makefile
U secure/lib/libssl/Makefile
U secure/usr.bin/openssl/Makefile
U sys/kern/kern_proc.c
U sys/kern/kern_synch.c
U sys/kern/sched_4bsd.c
cvs [update aborted]: cannot make directory include: File exists

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-21 Thread Mike Barcroft
Fri Nov 22 03:15:00 GMT 2002
...
U release/doc/en_US.ISO8859-1/hardware/alpha/proc-alpha.sgml
U release/doc/ja_JP.eucJP/hardware/common/dev.sgml
U release/doc/ja_JP.eucJP/hardware/i386/proc-i386.sgml
U release/doc/ja_JP.eucJP/hardware/ia64/article.sgml
U release/doc/ja_JP.eucJP/relnotes/common/new.sgml
U release/doc/ja_JP.eucJP/share/sgml/release.dsl
U share/man/man8/Makefile
U share/man/man8/rc.8
U share/man/man8/rc.subr.8
cvs [update aborted]: cannot make directory tc: Permission denied

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-18 Thread Mike Barcroft
Mon Nov 18 15:15:00 GMT 2002
cvs [update aborted]: /home/ncvs/CVSROOT: Interrupted system call

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-17 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
=== lib/libc
/tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `getent':
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:251: warning: passing arg 3 of `cdbget' 
discards qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/getcap.c: In function `cgetmatch':
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:576: warning: assignment discards 
qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/getcap.c:581: warning: assignment discards 
qualifiers from pointer target type
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c: In function `sysconf':
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:259: syntax error before break
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:263: syntax error before break
/tinderbox/sparc64/src/lib/libc/gen/sysconf.c:267: syntax error before break
*** Error code 1

Stop in /tinderbox/sparc64/src/lib/libc.
*** Error code 1

Stop in /tinderbox/sparc64/src/lib.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-17 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Sun Nov 17 20:01:33 GMT 2002
--
=== ipfilter
/tinderbox/sparc64/src/sys/kern/kern_thread.c: In function `kse_create':
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: `mp_ncpus' undeclared (first use in 
this function)
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: (Each undeclared identifier is 
reported only once
/tinderbox/sparc64/src/sys/kern/kern_thread.c:498: for each function it appears in.)
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Nov 15 08:03:44 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' 
from incompatible pointer type
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh'
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Nov 15 14:04:21 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' 
from incompatible pointer type
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh'
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-15 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Fri Nov 15 20:03:41 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' 
from incompatible pointer type
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint':
/tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh'
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: addition to cdefs

2002-11-13 Thread Mike Barcroft
Bruce Evans [EMAIL PROTECTED] writes:
 Both have large namespace pollution (p and n are in the application
 namespace).  Both give huge code wih a copy of the function in every
 object file whose source file(s) include this header if inline functions
 are not actually inline (which happens if the compiler is gcc -O0 or
 non-gcc).

I fixed the namespace problems in the version I posted for review on
-standards.  Do you see any problems with changing FD_ZERO() to:

#define FD_ZERO(p)  do {\
fd_set *_p = (p);   \
__size_t _n = _howmany(FD_SETSIZE, _NFDBITS);   \
while (_n  0)  \
_p-__fds_bits[--_n] = 0;   \
} while (0);

...to overcome the issues with the inline version?

Best regards,
Mike Barcroft

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-13 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Wed Nov 13 20:02:02 GMT 2002
--
=== ipfilter
./aicasm: 877 instructions used
/tinderbox/sparc64/src/sys/dev/pci/pci_pci.c:50:21: opt_pci.h: No such file or 
directory
mkdep: compile failed
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-13 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
=== lib/libc
/tinderbox/sparc64/src/lib/libc/gen/_pthread_stubs.c:59: conflicting types for 
`__thr_jtable'
/tinderbox/sparc64/src/lib/libc/include/libc_private.h:106: previous declaration of 
`__thr_jtable'
*** Error code 1

Stop in /tinderbox/sparc64/src/lib/libc.
*** Error code 1

Stop in /tinderbox/sparc64/src/lib.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Disabling OPIE prevents FTP access

2002-11-13 Thread Mike Heffner
I've been playing around with OPIE in -current and have found that when I
disable OPIE for a user (opiepasswd -d) that I can no longer login to
ftpd with my normal unix password. However, I am able to login(1) when
it's disabled with my normal unix password.

 opiepasswd -c
...
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
 
ID spock OTP key is 499 cu0653
DIE HICK SKY SLEW HOB BOSE
 opiepasswd -d
Updating spock:
Disable spock's OTP access? (yes or no) yes
 
ID spock is disabled.
 ftp localhost
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
220 localhost FTP server (Version 6.00LS) ready.
Name (localhost:spock): spock
331 Response to otp-md5 498 cu65 ext required for spock.
Password:   --- entering normal unix password here
530 Login incorrect.
ftp: Login failed.
ftp quit
221 Goodbye.


Is this incorrect behavior? Or am I doing something wrong with OPIE?


Thanks,

Mike

-- 
  Mike Heffner   mheffner@[acm.]vt.edu
 [EMAIL PROTECTED]




msg46660/pgp0.pgp
Description: PGP signature


sparc64 tinderbox failure

2002-11-11 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Mon Nov 11 08:01:21 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/vm/uma_dbg.c: In function `uma_dbg_alloc':
/tinderbox/sparc64/src/sys/vm/uma_dbg.c:233: warning: implicit declaration of function 
`atomic_set_8'
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



sparc64 tinderbox failure

2002-11-11 Thread Mike Barcroft
--
 Rebuilding the temporary build tree
--
 stage 1: bootstrap tools
--
 stage 2: cleaning up the object tree
--
 stage 2: rebuilding the object tree
--
 stage 2: build tools
--
 stage 3: cross tools
--
 stage 4: populating 
/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
--
 stage 4: building libraries
--
 stage 4: make dependencies
--
 stage 4: building everything..
--
 Kernel build for GENERIC started on Mon Nov 11 14:01:31 GMT 2002
--
=== ipfilter
cc1: warnings being treated as errors
/tinderbox/sparc64/src/sys/vm/uma_dbg.c: In function `uma_dbg_alloc':
/tinderbox/sparc64/src/sys/vm/uma_dbg.c:233: warning: implicit declaration of function 
`atomic_set_8'
*** Error code 1

Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1

Stop in /tinderbox/sparc64/src.
*** Error code 1

Stop in /tinderbox/sparc64/src.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: addition to cdefs

2002-11-11 Thread Mike Barcroft
Marc Recht [EMAIL PROTECTED] writes:
 Hi!
 
 I've made a small patch to make it possible to enable BSD extensions
 although _POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE has been
 defined. This is made with a new define _BSD_SOURCE right after the 
 XOPEN_SOURCE handling. It sets __XSI_VISIBLE 600 and __BSD_VISIBLE 1.
 This is needed for some programs. For example for Python 2.3cvs sets
 (among others) _POSIX_C_SOURCE 199506L, but also expects to have chroot
 and friends.

It looks like unistd.h has some XSI bugs.  Is _XOPEN_SOURCE defined
anywhere?  If so, try the attached patch.  If not, this is a bug in
Python (since POSIX doesn't specify chroot()) and should be fixed at
their end and in the ports collection.

_BSD_SOURCE provides mostly the same visibility as not defining any
standards constants, so it isn't very useful.

Best regards,
Mike Barcroft

Index: unistd.h
===
RCS file: /work/repo/src/include/unistd.h,v
retrieving revision 1.63
diff -u -r1.63 unistd.h
--- unistd.h28 Oct 2002 00:15:43 -  1.63
+++ unistd.h11 Nov 2002 14:48:50 -
@@ -361,7 +361,7 @@
 ssize_t write(int, const void *, size_t);
 
 /* 1003.2-1992 */
-#if __POSIX_VISIBLE = 199209
+#if __POSIX_VISIBLE = 199209 || __XSI_VISIBLE
 size_t  confstr(int, char *, size_t);
 int getopt(int, char * const [], const char *);
 
@@ -370,7 +370,7 @@
 #endif
 
 /* ISO/IEC 9945-1: 1996 */
-#if __POSIX_VISIBLE = 199506
+#if __POSIX_VISIBLE = 199506 || __XSI_VISIBLE
 int fsync(int);
 
 /*
@@ -381,13 +381,18 @@
 #define_FTRUNCATE_DECLARED
 int ftruncate(int, off_t);
 #endif
+#endif
 
+#if __POSIX_VISIBLE = 199506
 int getlogin_r(char *, int);
 #endif
 
 /* 1003.1-2001 */
-#if __POSIX_VISIBLE = 200112
+#if __POSIX_VISIBLE = 200112 || __XSI_VISIBLE
 int fchown(int, uid_t, gid_t);
+int readlink(const char *, char *, int);
+#endif
+#if __POSIX_VISIBLE = 200112
 int gethostname(char *, int /* socklen_t */);
 int setegid(gid_t);
 int seteuid(uid_t);
@@ -408,6 +413,7 @@
 /* char*ctermid(char *); *//* XXX ??? */
 int encrypt(char *, int);
 int fchdir(int);
+longgethostid(void);
 int getpgid(pid_t _pid);
 int getsid(pid_t _pid);
 char   *getwd(char *); /* LEGACY: obsoleted by getcwd() */
@@ -432,13 +438,20 @@
 #endif
 #endif /* __XSI_VISIBLE */
 
+#if __XSI_VISIBLE = 500 || __BSD_VISIBLE
+int brk(const void *);
+int chroot(const char *);
+int getdtablesize(void);
+int getpagesize(void) __pure2;
+char   *getpass(const char *);
+void   *sbrk(intptr_t);
+#endif
+
 #if __BSD_VISIBLE
 struct timeval;/* select(2) */
 int acct(const char *);
 int async_daemon(void);
-int brk(const void *);
 int check_utility_compat(const char *);
-int chroot(const char *);
 const char *
 crypt_get_format(void);
 int crypt_set_format(const char *);
@@ -448,12 +461,8 @@
 int exect(const char *, char * const *, char * const *);
 char   *fflagstostr(u_long);
 int getdomainname(char *, int);
-int getdtablesize(void);
 int getgrouplist(const char *, gid_t, gid_t *, int *);
-longgethostid(void);
 mode_t  getmode(const void *, mode_t);
-int getpagesize(void) __pure2;
-char   *getpass(const char *);
 int getpeereid(int, uid_t *, gid_t *);
 int getresgid(gid_t *, gid_t *, gid_t *);
 int getresuid(uid_t *, uid_t *, uid_t *);
@@ -483,7 +492,6 @@
const char *, const char *, const char *);
 char   *re_comp(const char *);
 int re_exec(const char *);
-int readlink(const char *, char *, int);
 int reboot(int);
 int revoke(const char *);
 pid_t   rfork(int);
@@ -491,7 +499,6 @@
 int rresvport(int *);
 int rresvport_af(int *, int);
 int ruserok(const char *, int, const char *, const char *);
-void   *sbrk(intptr_t);
 #if __BSD_VISIBLE
 #ifndef _SELECT_DECLARED
 #define_SELECT_DECLARED



<    1   2   3   4   5   6   7   8   9   10   >