NS DP83932 SONIC driver for pc98
Hi. I updated 'snc' driver for -current. This driver is only for NEC pc98 machines. http://triaez.kaisei.org/~mzaki/sonic/ This is very stable for usual operation. I hope this will be merged into the tree. -- Motomichi Matsuzaki <[EMAIL PROTECTED]> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mtree again
On Sat, Sep 23, 2000 at 09:44:21PM -0400, Garrett Wollman wrote: > < said: > > > Is their any harm in just keeping the -P flag as a no-op and optionally > > remove it at some later time (for backward compatibility)? > > We should try to be consistent with POSIX.1-200x as much as possible. What POSIX.1-200x says about this thing? I don't have this book in hand. -- Andrey A. Chernov <[EMAIL PROTECTED]> http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ahc and SMP
On Sun, Sep 24, 2000 at 00:04:38 +0200, German Tischler wrote:
[ problems with SMP, but not UP kernels, I don't know anything about that ]
> Is anyone else seeing this ?
>
> Another strange thing is that cdrecord -scanbus tells me
>
> scsibus0:
> 0,0,0 0) *
> 0,1,0 1) *
> 0,2,0 2) 'IBM ' 'DORS-32160 ' 'S82C' Disk
> 0,3,0 3) 'IBM ' 'DCAS-34330 ' 'S65A' Disk
> 0,4,0 4) *
> 0,5,0 5) *
> 0,6,0 6) *
> 0,7,0 7) *
> 0,8,0 8) 'IBM ' 'DDYS-T18350N' 'S80D' Disk
> scsibus1:
> 1,0,0 100) 'YAMAHA ' 'CRW4260 ' '1.0h' Removable CD-ROM
> 1,1,0 101) *
> 1,2,0 102) *
> 1,3,0 103) *
> 1,4,0 104) *
> 1,5,0 105) *
> 1,6,0 106) *
> 1,7,0 107) *
>
> While camcontrol devlist says
>
> at scbus0 target 2 lun 0 (pass0,da0)
> at scbus0 target 3 lun 0 (pass1,da1)
> at scbus0 target 8 lun 0 (pass2,da2)
> at scbus1 target 0 lun 0 (pass3,cd0)
> at scbus1 target 1 lun 0 (pass4,cd1)
>
> Maybe just a bug in cdrecord.
IIRC, cdrecord opens up each device to do an inquiry on it.
So if you don't have enough pass(4) devices in /dev, you may not see some
of the devices that are there.
So make sure you have /dev/pass{0-4}.
Another way to make sure you have a pass device for cd1 is to do:
camcontrol tur cd1 -v
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mtree again
< said: > Is their any harm in just keeping the -P flag as a no-op and optionally > remove it at some later time (for backward compatibility)? We should try to be consistent with POSIX.1-200x as much as possible. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Compilation Errors
On 24-Sep-00 Justin Thomas wrote: > I am trying to compile (make buildworld) the latest CURRENT version of > FreeBSD (5). I keep getting an error when it trys to build "libdisk" > about something being redefined or something. This is quite a ways into > the build process. Is anyone familiar with this error? Your sources are a bit old. update and try again. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compilation Errors (libdisk)
Attached is the end of the .out file where my error occurs. Thanks for any help. ~Justin ===> libdevstat cc -O -pipe -I/usr/src/lib/libdevstat -I/usr/src/lib/libdevstat/../../sys -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libdevstat/devstat.c -o devstat.o building standard devstat library ranlib libdevstat.a cc -fpic -DPIC -O -pipe -I/usr/src/lib/libdevstat -I/usr/src/lib/libdevstat/../../sys -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libdevstat/devstat.c -o devstat.So building shared library libdevstat.so.2 ===> libdisk cc -O -pipe -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libdisk/blocks.c -o blocks.o cc -O -pipe -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libdisk/disklabel.c -o disklabel.o cc -O -pipe -Wall -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libdisk/../../sbin/disklabel/dkcksum.c -o dkcksum.o /usr/src/lib/libdisk/../../sbin/disklabel/dkcksum.c:47: redefinition of `dkcksum' /usr/obj/usr/src/i386/usr/include/sys/disklabel.h:183: `dkcksum' previously defined here *** Error code 1 Stop in /usr/src/lib/libdisk. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. unix#
Compilation Errors
I am trying to compile (make buildworld) the latest CURRENT version of FreeBSD (5). I keep getting an error when it trys to build "libdisk" about something being redefined or something. This is quite a ways into the build process. Is anyone familiar with this error? Thanks, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mtree again
In message <[EMAIL PROTECTED]> Marcel Moolenaar writes: : Is their any harm in just keeping the -P flag as a no-op and optionally : remove it at some later time (for backward compatibility)? -P is non-standard, was introduced only in July and therefore we don't need to keep it around for any reason at all. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mtree again
"Andrey A. Chernov" wrote: > > --- usr.sbin/mtree/mtree.c.orig Thu Jul 27 07:36:02 2000 > +++ usr.sbin/mtree/mtree.c Fri Sep 15 04:00:46 2000 [snip] > @@ -115,10 +119,6 @@ > case 'q': > qflag = 1; > break; > - case 'P': > - ftsoptions ^= FTS_LOGICAL; > - ftsoptions |= FTS_PHYSICAL; > - break; > case 'r': > rflag = 1; > break; Is their any harm in just keeping the -P flag as a no-op and optionally remove it at some later time (for backward compatibility)? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -Current + X 4.0.1 = mouse problems
David Siebörger wrote:
> I've experienced the (apparently common) problem of switching from X
> to console and back to X and getting an unresponsive mouse pointer in
> X. This occurs when I use protocol "Auto", or don't specify a
> protocol.
Someone was kind enough to send me the attached patch. With
Option "Protocol""Auto"
Option "Device" "/dev/sysmouse"
it works with moused. I tried protocol sysmouse, but it didn't work.
Neither did Christian's advice about the mousesystems protocol. I also
have a wheeled mouse, logitech specifically.
It would be nice to include this patch in our X4 port.
Doug
--
"The dead cannot be seduced."
- Kai, "Lexx"
Do YOU Yahoo!?
--- programs/Xserver/hw/xfree86/input/mouse/mouse.c.origSun Jul 23 17:50:10
2000
+++ programs/Xserver/hw/xfree86/input/mouse/mouse.c Sun Jul 23 17:54:22 2000
@@ -692,10 +692,15 @@
pMse->protocolID = protocolID;
}
}
+#ifndef __FreeBSD__
memcpy(pMse->protoPara, proto[pMse->protocolID], sizeof(pMse->protoPara));
+#endif
if (automatic) {
if (name) {
+#ifdef __FreeBSD__
+ memcpy(pMse->protoPara, proto[pMse->protocolID], sizeof(pMse->protoPara));
+#endif
/* Possible protoPara overrides from SetupAuto. */
for (i = 0; i < sizeof(pMse->protoPara); i++)
if (protoPara[i] != -1)
--- programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c.orig Sat Feb 12 22:45:41
2000
+++ programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c Sun Jul 23 17:50:10
+2000
@@ -165,7 +165,11 @@
mode.rate = rate > 0 ? rate : -1;
mode.resolution = res > 0 ? res : -1;
mode.accelfactor = -1;
+#ifdef __FreeBSD__
+mode.level = 1;
+#else
mode.level = -1;
+#endif
ioctl(pInfo->fd, MOUSE_SETMODE, &mode);
}
#endif
ahc and SMP
Hi. On my machine the ahc (aic) driver times out while probing for devices on SMP, while it is working on UP. dmesg says ahc0: port 0xd000-0xd0ff mem 0xe100 -0xe1000fff irq 15 at device 6.0 on pci0 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs while booting the SMP kernel it says (probe0:ahc0:0:0:0) Timedout SCB 9 handled by another timeout (probe1:ahc0:0:1:0) SCB 0x8 - timed out while idle, SEQADDR == 0x167 sg[0] - Addr 0x7f2f684 : Length -2147483612 (probe1:ahc0:0:1:0) Queuing a BDR SCB (probe1:ahc0:0:1:0) no longer in timeout, status = 34a and after some more time will print more timeout messages and will not (at least not for a few minutes) finish probing or announce any SCSI devices. devices connected are da0 at ahc0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 3 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da2 at ahc0 bus 0 target 8 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Is anyone else seeing this ? Another strange thing is that cdrecord -scanbus tells me scsibus0: 0,0,0 0) * 0,1,0 1) * 0,2,0 2) 'IBM ' 'DORS-32160 ' 'S82C' Disk 0,3,0 3) 'IBM ' 'DCAS-34330 ' 'S65A' Disk 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * 0,8,0 8) 'IBM ' 'DDYS-T18350N' 'S80D' Disk scsibus1: 1,0,0 100) 'YAMAHA ' 'CRW4260 ' '1.0h' Removable CD-ROM 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * While camcontrol devlist says at scbus0 target 2 lun 0 (pass0,da0) at scbus0 target 3 lun 0 (pass1,da1) at scbus0 target 8 lun 0 (pass2,da2) at scbus1 target 0 lun 0 (pass3,cd0) at scbus1 target 1 lun 0 (pass4,cd1) Maybe just a bug in cdrecord. --gt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -Current + X 4.0.1 = mouse problems
[EMAIL PROTECTED] (Christian Weisgerber) wrote: > > Doug Barton <[EMAIL PROTECTED]> wrote: > >> Previously I had X + moused working just fine, so I had the best >> of both worlds. With X 4.0.1 if I use moused I get no response from the >> mouse in X at all. > > Make sure you use > > Option "Protocol" "MouseSystems" > > Protocol "Auto" is not reliable. Switching from "Auto" to "MouseSystems" is no panacea, however. I've experienced the (apparently common) problem of switching from X to console and back to X and getting an unresponsive mouse pointer in X. This occurs when I use protocol "Auto", or don't specify a protocol. Switching to "MouseSystems" protocol fixes the above problem, but it introduces a problem: the wheels on my mice no longer work in X. While there may be a way to get the wheel working under MouseSystems protocol, I've not found it. I experience this problem with both my FreeBSD workstations: one running 5.0-CURRENT (circa end-of-August) with a Microsoft IntelliMouse 1.1A for PS/2, and a second running 4.1-STABLE (of 19th September) with a Mitsumi PS/2 Scroll Mouse. Both run XFree86 4.0.1. -drs To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ppp.linkdown
On Fri, Sep 22, 2000 at 23:43 +0200, Leif Neland wrote: > > On Sat, 12 Aug 2000, Brian Somers wrote: > > > > Is ppp.linkdown executed before or after the link is down? > > > > > > I'd like to change a dyndns, but will link activity done in > > > linkdown defeat the timeout, or start a new call? > > > > It'll start a new call in auto mode. > > > So any ideas how to use dyndns? Simply the way it was designed -- with short TTLs (in a few minutes' order). Have your entry expire instead of "logging off". Your dyndns provider should support such a feature. This means to refresh the entry periodically when you're online -- with a refresh cycle longer than your idle timeout. Doing network actions and damaging your idle timeout by "waving good bye" is just as bad as turning timeouts off close to idlehup time and unconditionally hanging up -- this will collide with "regular" traffic which might have occured by chance (or due to the service's nature? Think of how long it takes to read a webpage and follow the next link). Even hacking a "pre hup hook" into ppp will have the latter problem. The only way out I could see it to have a clear way of recognizing what's data and what's logon/logoff traffic. Then you could teach your ppp not to take into account the dyndns traffic when calculating idlehup times. This could be done by looking at the ports or ipnumbers or whatever ppp(8)'s filter allows for. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -Current + X 4.0.1 = mouse problems
Doug Barton <[EMAIL PROTECTED]> wrote: > Previously I had X + moused working just fine, so I had the best > of both worlds. With X 4.0.1 if I use moused I get no response from the > mouse in X at all. Make sure you use Option "Protocol" "MouseSystems" Protocol "Auto" is not reliable. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting ssh back to work?
On Sat, 23 Sep 2000, Mark Huizer wrote: > I thought I had read the interesting stuff on ssh recently in -current, > but I can't get ssh to work again on the machine I switched to > yesterday's current :-( device random in your kernel. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting ssh back to work?
Hello! On Sat, Sep 23, 2000 at 02:01:21PM +0200, Mark Huizer wrote: > tiggr 1:31pm [~/.ssh] ssh eeyore > ssh: no RSA support in libssl and libcrypto. See ssl(8). > Disabling protocol version 1 > DH_generate_key > > That's with USA_RESIDENT=NO, and with rsaref port installed. ?? Can you give me a reason for doing this?:-) Rsaref (was) only for USA_RESIDENT=yes. If you are using a recent -CURRENT, crypto stuff is no longer separate, but comes with the base system. So you can basically just install the CRYPTO collection (and sources if you like) in sysinstall, or do a 'make world' with full sources. (a cvsup beforehand will take care of this.) Hope this helps... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Getting ssh back to work?
Hmm... I thought I had read the interesting stuff on ssh recently in -current, but I can't get ssh to work again on the machine I switched to yesterday's current :-( tiggr 1:31pm [~/.ssh] ssh eeyore ssh: no RSA support in libssl and libcrypto. See ssl(8). Disabling protocol version 1 DH_generate_key That's with USA_RESIDENT=NO, and with rsaref port installed. doing a ssh-keygen -d will just give me: tiggr 1:32pm [~/.ssh] ssh-keygen -d Generating DSA parameter and key. DSA_generate_keys failed That helps :-( Is there anything I've forgotten to do to make it work? mark -- Nice testing in little China... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fdc0 and ata1 issues
It seems Donn Miller wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > > I am also seeing the fdc0 problem "fdc0: cannot reserve I/O port range". > > What's up with the fdc driver? I'm seeing the exact same thing. There was > never any heads-up about this. Surely, the person who broke it knows about > it. :-( It's nice to have a warning before I go and recompile my kernel. > But then again, I wouldn't be running -current if I didn't expect problems. Its not the fdc driver, its the ata driver. The reason is I usr the altport address no in a different manner, that causes the conflict. I'm working on a solution -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fdc0 and ata1 issues
In article <[EMAIL PROTECTED]> you wrote: > I am also seeing the fdc0 problem "fdc0: cannot reserve I/O port range". What's up with the fdc driver? I'm seeing the exact same thing. There was never any heads-up about this. Surely, the person who broke it knows about it. :-( It's nice to have a warning before I go and recompile my kernel. But then again, I wouldn't be running -current if I didn't expect problems. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Thu Sep 21 18:23:45 EDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (166.45-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 62914560 (61440K bytes) avail memory = 57683968 (56332K bytes) Preloaded elf kernel "kernel" at 0xc038c000. Intel Pentium detected, installing workaround for F00F bug apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f,0xd400-0xd403,0xd800-0xd807,0xe000-0xe003,0xe400-0xe407 irq 11 at device 1.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ed0: port 0xb800-0xb81f irq 12 at device 10.0 on pci0 ed0: address 00:c0:df:ed:0b:17, type NE2000 (16 bit) pci0: at 19.0 irq 11 fdc0: cannot reserve I/O port range atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x2e8-0x2ef irq 10 flags 0x10 on isa0 sio0: type 16550A sio2 at port 0x3e8-0x3ef irq 4 on isa0 sio2: type 16550A mse0: at port 0x23c-0x23f irq 3 on isa0 sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: on sbc0 ppc0: at port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 3093MB [6704/15/63] at ata0-master UDMA33 ad1: 1040MB [2114/16/63] at ata0-slave WDMA2 acd0: CDROM at ata1-master using WDMA2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crashes under heavy disk activity
On Fri, 22 Sep 2000, Kenneth Wayne Culver wrote: ... > Alright, I think I may just do that too... I was going to try to tough it > out... but it looks like that just won't work I wish there was some Thats not correct. You have to upper kern.vm.kmem.size as a workaround. Please read the thread for more information. BTW: The increased memoryconsumption (and leak?) looks like a bug to me. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
smp and gdt
Compiling a kernel with gdt: /home/src/sys/i386/i386/machdep.c:1183: `MAXCPU' undeclared here (not in a funct ion) /home/src/sys/i386/i386/machdep.c:1183: size of array `gdt' has non-integer type BK said MAXCPU is defined on machine/smp.h. Well, machdep.c includes smp.h only if SMP is defined. -- Daniel C. Sobral (8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] PAIN: Sliding down a 50-foot razor blade into a bucket of alcohol. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fsck wrappers, revisited
On Sat, Sep 23, 2000, Bruce Evans wrote: > On Sat, 23 Dec 2000, Adrian Chadd wrote: > > > Here's the patch: > > > > --- fsck.c.orig Sat Dec 23 11:13:30 2000 > > +++ fsck.c Sat Dec 23 11:13:34 2000 > > @@ -501,7 +501,7 @@ > > errx(1, "partition `%s' is not of a legal vfstype", > > str); > > - if ((vfstype = dktypenames[t]) == NULL) > > + if ((vfstype = fstypenames[t]) == NULL) > > errx(1, "vfstype `%s' on partition `%s' is not supported", > > fstypenames[t], str); > > > > > > So now is a problem which I'm sure the NetBSD people came up against. > > The fstypenames are names like 4.2BSD, vinum, ISO9660, etc. NetBSD fixed > > this by creating a new list 'mountnames[]', which maps the fs type to > > a string. > > fs typenames are already strings in FreeBSD (the kernel's vfc_index is an > implementation detail which should not be visible in applications). Oh, wait. I understand what you're talking about now. There isn't any mapping to partition type (p_fstype) to fs typename string. > > http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/sys/disklabel.h.diff?r1=1.60&r2=1.61 > > > > What do people think about doing this as well? It would certainly make things > > a little tidier, but every time a new fs comes in the magic autodetection code > > will need to be updated (if appropriate, of course.) > > This would be a bug. Well, if you have any suggestions, I'm all for it. :-) Adrian -- Adrian Chadd"The main reason Santa is so jolly is <[EMAIL PROTECTED]> because he knows where all the bad girls live." -- Random IRC quote To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Permissions for /var/mail
hi, there! On Sat, 23 Sep 2000, Leif Neland wrote: > Pine 4.21 complains that /var/mail is vulnerable, that the perms should be > 1777 > > Would this be less vulnerable than 775 which make world restores it to? this happens because ports/mail/pine4/patches/patch-aw was not merged when libc-client was moved to separate port /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
