No Subject
Not sure if this is related to the recent commit of DEVFS code, but a build of both the GERNERIC kernel and a custom kernel from a very recent (last few hours) cvsup of -current failed during the 'make depend' with an error trying to include "opt_devfs.h". The following following is the ouput from a custom kernel (/usr/local/src/freebsd/src is the base of my src): === md @ - /usr/local/src/freebsd/src/sys machine - /usr/local/src/freebsd/src/sys/i386/include touch opt_mfs.h touch opt_md.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/include /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/local/src/freebsd/src/sys/modules/md. *** Error code 1 Commenting out the line: #include "opt_devfs.h" from src/sys/dev/md/md.c got rid of this error, although I am not sure that this is the correct fix. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Already told him. It is. On Sun, 20 Aug 2000, Tony Fleisher wrote: Not sure if this is related to the recent commit of DEVFS code, but a build of both the GERNERIC kernel and a custom kernel from a very recent (last few hours) cvsup of -current failed during the 'make depend' with an error trying to include "opt_devfs.h". The following following is the ouput from a custom kernel (/usr/local/src/freebsd/src is the base of my src): === md @ - /usr/local/src/freebsd/src/sys machine - /usr/local/src/freebsd/src/sys/i386/include touch opt_mfs.h touch opt_md.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/include /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/local/src/freebsd/src/sys/modules/md. *** Error code 1 Commenting out the line: #include "opt_devfs.h" from src/sys/dev/md/md.c got rid of this error, although I am not sure that this is the correct fix. Tony. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sound support in -CURRENT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi FreeBSD fans and developers... This is my first question in -CURRENT. Yesterday was the first time I tried to follow the -STABLE line. And I must admit that once again FreeBSD amazed me ;) Running -STABLE rite now (I used to run only -RELEASE before cause I'm haunted by the feeling that the upgrading process will be very complicated, but that's my mistake... The upgrading process was really simple and easy... ;) ) Now to the real question... I have a Compaq Deskpro EP system with onboard Intel 810e AGP VGA Card and onboard sound support (which maybe is AC97 or something similar). After running -STABLE I can use my VGA Card. How about the sound card? Does - -CURRENT support the sound card? Cause if -CURRENT can make my sound card sings, I'd love to give it a try. After all, this isn't a production machine. Regards, John Indra -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.2 (FreeBSD) Comment: Be the best! iD8DBQE5oNNhxcp0HIxafmQRAnm/AJsH99EctqjU2YukF3o0PfOIxNAx4ACgvmx0 YhugvQc/j2TtVcbHRvi6zrk= =wwoJ -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/modules/md opt_devfs.h Makefile
In article [EMAIL PROTECTED] you wrote: phk 2000/08/21 00:45:38 PDT Modified files: sys/modules/md Makefile Added files: sys/modules/md opt_devfs.h Log: Add dummy opt_devfs.h file. It seems to me that my patch is better ;-) N.Dudorov Index: src/sys/modules/md/Makefile === RCS file: /store/CVS/src/sys/modules/md/Makefile,v retrieving revision 1.5 diff -r1.5 Makefile 5c5 SRCS= md.c opt_mfs.h opt_md.h --- SRCS= md.c opt_mfs.h opt_md.h opt_devfs.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sysinstall trouble
I have trouble with sysinstall while installing bin destribution, sysinstall said Write failure on transfer ! wrote -1 bytes of 234567 bytes. i install from cdrom in single mode i DO mount / with wr mode! -- zev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: sysinstall trouble
Are you sure it's writable, try touching a file on the filesystem. mount -w /dev/ad0s1 / P.S. Before you mount it, do a fsck on it, whether it's clean or not, and then mount it. Hope it helps ... Good luck On 21-Aug-00 Zajcev Evgeny wrote: I have trouble with sysinstall while installing bin destribution, sysinstall said Write failure on transfer ! wrote -1 bytes of 234567 bytes. i install from cdrom in single mode i DO mount / with wr mode! -- zev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Unix Software Developer/Engineer E-Mail: Johan Kruger [EMAIL PROTECTED] Date: 21-Aug-00 Time: 11:34:36 All good things come to those who ... runs FreeBSD -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sound support in -CURRENT
On Mon, Aug 21, 2000 at 01:59:52PM +0700, John Indra wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi FreeBSD fans and developers... This is my first question in -CURRENT. Yesterday was the first time I tried to follow the -STABLE line. And I must admit that once again FreeBSD amazed me ;) Running -STABLE rite now (I used to run only -RELEASE before cause I'm haunted by the feeling that the upgrading process will be very complicated, but that's my mistake... The upgrading process was really simple and easy... ;) ) Now to the real question... I have a Compaq Deskpro EP system with onboard Intel 810e AGP VGA Card and onboard sound support (which maybe is AC97 or something similar). After running -STABLE I can use my VGA Card. How about the sound card? Does - -CURRENT support the sound card? Cause if -CURRENT can make my sound card sings, I'd love to give it a try. After all, this isn't a production machine. Not yet. Dan Moschuk [EMAIL PROTECTED] is working (?) on the driver. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Why no CDR ioctls for SCSI cds?
I'm curious - is there some reason that the CDR ioctls (in /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like doing them for MMC would be straightforward, it's the kind of thing that an OS is supposed to do, and it would allow people with MMC drives to cdrecord for the much (much, *much*) smaller burncd. Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote: I'm curious - is there some reason that the CDR ioctls (in /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like doing them for MMC would be straightforward, it's the kind of thing that an OS is supposed to do, and it would allow people with MMC drives to cdrecord for the much (much, *much*) smaller burncd. Well, doing that sort of thing for MMC-compliant CD-Rs will open the door to doing it for all CD-Rs. We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM supported with the cd(4) driver..." cdrecord supports a much wider variety of drives out of the box, it is actively supported, and it works. If we put all of cdrecord's functionality into the kernel and burncd, it would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck with maintaining it.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Question from a neophyte... Why isn't rc.local being read?
I've added startup commands to /etc/rc.local on my 3.4 Stable machine. /usr/local/etc/webmin/start # Start webmin /usr/local/sbin/sshd# Start open ssh /etc/init.d/apachectl start # Start apache web server Yet, these are not starting at reboot... What am I missing? Probably something obvious, but it escapes me... *** REPLY SEPARATOR *** On 8/21/00 at 9:53 AM Julian Elischer wrote: since config has changed.. where do I set the flags on my debug port (sio2?) the sio man page has no hints.. it looks to me as it if is now controlled differently unles I've made a mistake julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Question from a neophyte... Why isn't rc.local being read?
Gordon, This sort of question is better suited to [EMAIL PROTECTED] than [EMAIL PROTECTED] In the future, please ask there first. rc.local is deprecated. Drop a shell script in /usr/local/etc/rc.d ==ml The short answer I've added startup commands to /etc/rc.local on my 3.4 Stable machine. /usr/local/etc/webmin/start # Start webmin /usr/local/sbin/sshd# Start open ssh /etc/init.d/apachectl start # Start apache web server Yet, these are not starting at reboot... What am I missing? Probably something obvious, but it escapes me... *** REPLY SEPARATOR *** On 8/21/00 at 9:53 AM Julian Elischer wrote: since config has changed.. where do I set the flags on my debug port (sio2?) the sio man page has no hints.. it looks to me as it if is now controlled differently unles I've made a mistake julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld failed
I'll chime in here with a "me too". My make buildworld(s) failed with the *identical* error as originally posted by daniel [EMAIL PROTECTED] on 16-Aug-2000. I tried #make -j4 buildworld and another attempt of #make buildworld. Both attempts failed with the same error. I tried this on a 3.4-RELEASE system with -current cvsup'd on 20-Aug-2000 @ 07:00 (MST). OK, now there are 2 of us with the identical symptom. Where did we go astray? BoB KoT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how to set flags on sio2?
According to Julian Elischer: the sio man page has no hints.. it looks to me as it if is now controlled differently unles I've made a mistake Modify /boot/device.hints. hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.irq="4" just add a hint.sio.0.flags="0x20". -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how to set flags on sio2?
According to Julian Elischer: so I don;t have such file.. do I need to do anything special to make it beused if I create it? If you have current after around the 10th of June, you need it. It is created by running "gethints.pl THE_KERNEL /boot/device.hints" (gethints.pl is in /sys/i386/conf). Or you use the GENERIC.hints file at the same place (see GENERIC). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
compaq proliant
has anyone gotten freebsd (current or other) running on one of these? i've tried 4.0, 4.1, and -current, and the kernel panics on me with the following: sym0: 895a port 0x1000=0x10ff mem 0xb110-0xb1101fff,0xb140-0xb14003ff irq 11 at device 4.0 on pci1 sym0: failed to allocate RAM resources any ideas? - j Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Question from a neophyte... Why isn't rc.local being read?
Michael Lucas wrote: rc.local is deprecated. Drop a shell script in /usr/local/etc/rc.d Not really. Some of us prefer to have commands to start things in one nice list in /etc/rc.local, rather than loads of separate shell scripts in /usr/local/etc/rc.d. There's no reason I can see for rc.local not to get read at boot time. I'd recommend the original poster compare his other /etc/rc* files with those in /usr/src/etc to make sure there has been no local modification to remove the code which calls rc.local. -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compaq proliant
has anyone gotten freebsd (current or other) running on one of these? Which Proliant model are you talking about? i've tried 4.0, 4.1, and -current, and the kernel panics on me with the following: sym0: 895a port 0x1000=0x10ff mem 0xb110-0xb1101fff,0xb140-0xb14003ff irq 11 at device 4.0 on pci1 sym0: failed to allocate RAM resources We're running 3.4-STABLE on a Proliant 3000 here, and it's working great. Mind you, this has a Symbios 875 based controller, not 895a as in your case. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] -- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-2124-STABLE #0: Sat Feb 19 23:14:12 CET 2000 [EMAIL PROTECTED]:/local/freebsd/src/sys/compile/NEWSFEED1_SYM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 603979776 (589824K bytes) avail memory = 584105984 (570416K bytes) Programming 28 pins in IOAPIC #0 EISA INTCONTROL = 0620 IOAPIC #0 intpint 24 - irq 5 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 8, version: 0x001b0011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc02d6000. Pentium Pro MTRR support enabled eisa0: CPQ561 (System Board) Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: Ross (?) host to PCI bridge rev 0x03 on pci0.0.0 vga0: Cirrus Logic GD5430 SVGA controller rev 0x22 int a irq 255 on pci0.6.0 chip1: PCI to EISA bridge (vendor=0e11 device=0001) rev 0x07 on pci0.15.0 chip2: Ross (?) host to PCI bridge rev 0x03 on pci0.17.0 Probing for devices on PCI bus 1: sym0: 875 rev 0x14 int a irq 19 on pci1.4.0 sym0: No NVRAM, ID 7, Fast-20, parity checking sym1: 875 rev 0x14 int b irq 18 on pci1.4.1 sym1: No NVRAM, ID 7, Fast-20, parity checking fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 18 on pci1.7.0 fxp0: Ethernet address 00:90:27:13:f6:21 tl0: Compaq Netelligent 10/100 rev 0x10 int a irq 17 on pci1.8.0 tl0: Ethernet address: 00:08:c7:1e:a7:35 tl0: autoneg complete, link status good (full-duplex, 100Mbps) Probing for devices on PCI bus 2: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0: failed to get data. psm0 irq 12 on isa psm0: model IntelliMouse, device ID 3 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface APIC_IO: Testing 8254 interrupt delivery APIC_IO: Broken MP table detected: 8254 is not connected to IO APIC int pin 2 APIC_IO: routing 8254 via 8259 on pin 0 ccd0-3: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! da0 at sym0 bus 0 target 0 lun 0 da0: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da2 at sym0 bus 0 target 4 lun 0 da2: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da3 at sym0 bus 0 target 5 lun 0 da3: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da1 at sym0 bus 0 target 1 lun 0 da1: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: devfs mkIII test review please.
In message [EMAIL PROTECTED], Sheldon Hearn writes: On Sat, 19 Aug 2000 21:26:24 +0200, Poul-Henning Kamp wrote: Ahh, right, this is something else than I thought: These are symlinks in the normal case, for instance: /dev/audio - /dev/audio0 What's the plan for things like these? Are we going to take the soft option and teach /etc/rc to create symlinks for device nodes found on startup and require folks to make the rest themselves? Or can this be handled gracefully in the kernel? DEVFS supports symlinks. Symlinks can be made from userland with the normal "ln -s" They can also be made by the driver using make_dev_alias(). Who makes the symlinks and when should be decided by the driver writer. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: random module no longer loaded by default
Hi folks, The logic for seeding the random device on start-up in /etc/rc has changed slightly. Between revs 1.221 and 1.229 inclusive, the randomdev module was automatically loaded if the write of the entropy seed file to /dev/random failed. After chatting to Mark Murray, I agree that this isn't such a hot plan. If the random device isn't present, it may very well be because it's not wanted. There are several things on the horizon that will moot this point, so there's no need to jump up and down about it. The bottom line is this: If you do NOT have ``options RANDOMDEV'' in your kernel and you DO want the random device then add randomdev_load="YES" to /boot/loader.conf . Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Kenneth D. Merry writes: On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote: I'm curious - is there some reason that the CDR ioctls (in /usr/include/sys/cdrio.h) aren't supported for MMC cds? It looks like doing them for MMC would be straightforward, it's the kind of thing that an OS is supposed to do, and it would allow people with MMC drives to cdrecord for the much (much, *much*) smaller burncd. Well, doing that sort of thing for MMC-compliant CD-Rs will open the door to doing it for all CD-Rs. No more so than has already been done by supporting SCSI cdrom at all. We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM supported with the cd(4) driver..." Which should actually be smaller than the flood of mail saying things like "why doesn't burncd support my nice, standard-compliant CD-R?" In fact, according to the documentation that comes with cdrecord, it would be *much* smaller, because all the SCSI CD-Rs released in the last few years have been MMC. cdrecord supports a much wider variety of drives out of the box, it is actively supported, and it works. Yup. Since it's native OS isn't FreeBSD, it wouldn't vanish even if we *did* put all of cdrecord in the kernel. I don't even see the port vanishing, because of the need to support legacy hardware. If we put all of cdrecord's functionality into the kernel and burncd, it would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck with maintaining it.) Correct. I'm not asking why cdrecord's functionality isn't in the kernel, and wouldn't argue that it should be. I'm asking why there isn't support for a widely deployed standard interface to this functionality when there's already a kernel API for it. If it's a matter of not wanting to maintain that little bit of code, I'm willing to do that. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 17:01:20 -0500, Mike Meyer wrote:
Kenneth D. Merry writes:
On Mon, Aug 21, 2000 at 10:54:49 -0500, Mike Meyer wrote:
We'd get a flood of mail saying things like "why isn't my froboz CD-R/WORM
supported with the cd(4) driver..."
Which should actually be smaller than the flood of mail saying things
like "why doesn't burncd support my nice, standard-compliant CD-R?" In
fact, according to the documentation that comes with cdrecord, it
would be *much* smaller, because all the SCSI CD-Rs released in the
last few years have been MMC.
I think it would generate a fair amount of mail, certainly a lot more than
the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs.
(which is very, very little)
If we put all of cdrecord's functionality into the kernel and burncd, it
would be just as big, or bigger than cdrecord is now. (Plus we'd be stuck
with maintaining it.)
Correct. I'm not asking why cdrecord's functionality isn't in the
kernel, and wouldn't argue that it should be. I'm asking why there
isn't support for a widely deployed standard interface to this
functionality when there's already a kernel API for it.
If it's a matter of not wanting to maintain that little bit of code,
I'm willing to do that.
It's not there because I'd rather not do a halfway solution. Adding
support for only MMC drives will mean that users with non-MMC SCSI CD
burners will just get confused when burncd doesn't work. ("But it worked
for my friend Joe...")
Just because the API is there doesn't mean we should go through the work
to support that API when we have something else that already works.
It would be a duplication of functionality. Why reinvent the wheel
when the wheel we have works very well?
If you want standard burner support with the OS (isn't that what you're
really getting at here?), why not just import cdrecord into the contrib
tree and be done with it? It's GPLed, so it wouldn't be any more onerous
license-wise than many of the other tools we have in the tree.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Kenneth D. Merry writes:
Which should actually be smaller than the flood of mail saying things
like "why doesn't burncd support my nice, standard-compliant CD-R?" In
fact, according to the documentation that comes with cdrecord, it
would be *much* smaller, because all the SCSI CD-Rs released in the
last few years have been MMC.
I think it would generate a fair amount of mail, certainly a lot more than
the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs.
(which is very, very little)
What evidence do you have that it would generate a fair amount of
mail? I agree that there's very little about burncd - probably because
most people get dual pointers when they ask what to use to record
cds. Improving what burncd works for shouldn't change that, especially
if the kernel boot sequence said whether or not the drive supported
MMC.
Correct. I'm not asking why cdrecord's functionality isn't in the
kernel, and wouldn't argue that it should be. I'm asking why there
isn't support for a widely deployed standard interface to this
functionality when there's already a kernel API for it.
If it's a matter of not wanting to maintain that little bit of code,
I'm willing to do that.
It's not there because I'd rather not do a halfway solution. Adding
support for only MMC drives will mean that users with non-MMC SCSI CD
burners will just get confused when burncd doesn't work. ("But it worked
for my friend Joe...")
I'd say that you've *already* got a halfway solution, in that you only
support half the functionality of the standard.
Just curious - do you feel that you have to support old disk drives
that don't properly adhere to the SCSI standard, or otherwise behave
in strange ways? Say some of DEC's old drives that don't spin up on
power on, but have to be told to do so by the OS? A quick check
doesn't reveal any support for such things, but I may have missed it.
Just because the API is there doesn't mean we should go through the work
to support that API when we have something else that already works.
It would be a duplication of functionality. Why reinvent the wheel
when the wheel we have works very well?
For the same reason that CAM replaced the old SCSI system - because
the replacement is an improvement! Sure, it won't work with
non-standard devices, but those should be a shrinking minority.
This also solves the problem of keeping the two in sync. I've been bit
more than once by the system and cdrecord being out of sync.
If you want standard burner support with the OS (isn't that what you're
really getting at here?), why not just import cdrecord into the contrib
tree and be done with it? It's GPLed, so it wouldn't be any more onerous
license-wise than many of the other tools we have in the tree.
Well, that would certainly solve the sync problem - but I'm not
willing to support cdrecord; it's an ugly mess. I'd rather support
(including write) the MMC code. I just don't want to write it if it
will never go in the distribution.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote:
Kenneth D. Merry writes:
Which should actually be smaller than the flood of mail saying things
like "why doesn't burncd support my nice, standard-compliant CD-R?" In
fact, according to the documentation that comes with cdrecord, it
would be *much* smaller, because all the SCSI CD-Rs released in the
last few years have been MMC.
I think it would generate a fair amount of mail, certainly a lot more than
the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs.
(which is very, very little)
What evidence do you have that it would generate a fair amount of
mail?
Prior experience. People get confused relatively easily, no matter how many
places something is documented and no matter how many times you explain
something on a mailing list.
It might not be that bad, though, since cdrecord would still be available
and still work.
Correct. I'm not asking why cdrecord's functionality isn't in the
kernel, and wouldn't argue that it should be. I'm asking why there
isn't support for a widely deployed standard interface to this
functionality when there's already a kernel API for it.
If it's a matter of not wanting to maintain that little bit of code,
I'm willing to do that.
It's not there because I'd rather not do a halfway solution. Adding
support for only MMC drives will mean that users with non-MMC SCSI CD
burners will just get confused when burncd doesn't work. ("But it worked
for my friend Joe...")
I'd say that you've *already* got a halfway solution, in that you only
support half the functionality of the standard.
You mean reading and not writing?
One piece of writing functionality I *do* intend to put in the kernel is
support for DVD-RAM drives. (It's mainly hung up with disklabel problems
at the moment.)
Just curious - do you feel that you have to support old disk drives
that don't properly adhere to the SCSI standard, or otherwise behave
in strange ways? Say some of DEC's old drives that don't spin up on
power on, but have to be told to do so by the OS? A quick check
doesn't reveal any support for such things, but I may have missed it.
You missed it. In the error recovery code. If a drive returns an error
code that we understand to mean "spin me up", we send a start unit command
to the disk. (No more than four start units may be oustanding at one time,
to avoid overloading power supplies.)
We also have various quirk tables for devices that do odd things. So yes,
I think we do need to support older and/or quirky hardware, to a certain
point.
Just because the API is there doesn't mean we should go through the work
to support that API when we have something else that already works.
It would be a duplication of functionality. Why reinvent the wheel
when the wheel we have works very well?
For the same reason that CAM replaced the old SCSI system - because
the replacement is an improvement! Sure, it won't work with
non-standard devices, but those should be a shrinking minority.
I don't think you've made the case that the replacement is an improvement.
cdrecord at the moment has more features than burncd, and seems to work
well.
The only thing you've said about cdrecord is that the code is a mess
(below). I don't think it's that bad. I might do things differently,
but things are going to be more complicated when you try to support a large
number of OSes.
This also solves the problem of keeping the two in sync. I've been bit
more than once by the system and cdrecord being out of sync.
If you want standard burner support with the OS (isn't that what you're
really getting at here?), why not just import cdrecord into the contrib
tree and be done with it? It's GPLed, so it wouldn't be any more onerous
license-wise than many of the other tools we have in the tree.
Well, that would certainly solve the sync problem - but I'm not
willing to support cdrecord; it's an ugly mess. I'd rather support
(including write) the MMC code. I just don't want to write it if it
will never go in the distribution.
What you're willing to support isn't the whole picture here. As the driver
author, I'd rather not support a solution that only goes halfway.
If doing burncd support for MMC drives were a step on the way for getting
support for the various other types of drives that cdrecord supports, it
would be a different story. (We'd also want to see what features were
available in cdrecord but not burncd and look into adding those as well.)
As it is, importing cdrecord into the tree would solve what seem to be
your major objections -- that cdrecord gets out of sync with the OS because
it isn't built with the OS, and that we don't ship a way of burning SCSI
CDs with the OS.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
error sysinstall
hi, when i execute sysinstall i have this error: Device char-major=254 minor=0x0 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x0 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x0 failed attempt t o open in block mode Device char-major=254 minor=0x1 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x1 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x1 failed attempt t o open in block mode Device char-major=254 minor=0x2 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x2 failed attempt t o open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x2 failed attempt t o open in block mode Device char-major=254 minor=0x3 failed attempt to open in block mode Aug 22 00:30:43 daemon /kernel: Device char-major=254 minor=0x3 failed attempt to open in block mode anyone help me please? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Kenneth D. Merry writes:
On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote:
Kenneth D. Merry writes:
Which should actually be smaller than the flood of mail saying things
like "why doesn't burncd support my nice, standard-compliant CD-R?" In
fact, according to the documentation that comes with cdrecord, it
would be *much* smaller, because all the SCSI CD-Rs released in the
last few years have been MMC.
I think it would generate a fair amount of mail, certainly a lot more than
the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs.
(which is very, very little)
What evidence do you have that it would generate a fair amount of
mail?
Prior experience. People get confused relatively easily, no matter how many
places something is documented and no matter how many times you explain
something on a mailing list.
Um - that's not evidence, that's an argument. But prior experience
shows that having two tools for burning cd's generates - in your own
words - "very, very little" mail. By the same argument, including some
drives in both sets of tools shouldn't raise the confusion level.
Correct. I'm not asking why cdrecord's functionality isn't in the
kernel, and wouldn't argue that it should be. I'm asking why there
isn't support for a widely deployed standard interface to this
functionality when there's already a kernel API for it.
If it's a matter of not wanting to maintain that little bit of code,
I'm willing to do that.
It's not there because I'd rather not do a halfway solution. Adding
support for only MMC drives will mean that users with non-MMC SCSI CD
burners will just get confused when burncd doesn't work. ("But it worked
for my friend Joe...")
I'd say that you've *already* got a halfway solution, in that you only
support half the functionality of the standard.
You mean reading and not writing?
Yes.
One piece of writing functionality I *do* intend to put in the kernel is
support for DVD-RAM drives. (It's mainly hung up with disklabel problems
at the moment.)
Why those and not CD-R drives? Especially when, from what I can tell,
the situation with those is even *more* confused than it is with
CD-Rs, as there are multiple writable DVD formats, and they are
changing.
Or are you talking about support for the non-9660 file system that
some of them use?
Just curious - do you feel that you have to support old disk drives
that don't properly adhere to the SCSI standard, or otherwise behave
in strange ways? Say some of DEC's old drives that don't spin up on
power on, but have to be told to do so by the OS? A quick check
doesn't reveal any support for such things, but I may have missed it.
You missed it. In the error recovery code. If a drive returns an error
code that we understand to mean "spin me up", we send a start unit command
to the disk. (No more than four start units may be oustanding at one time,
to avoid overloading power supplies.)
We also have various quirk tables for devices that do odd things. So yes,
I think we do need to support older and/or quirky hardware, to a certain
point.
Does this extend to the point of supporting things that happen to
share a physical connector with SCSI, but otherwise aren't SCSI?
Because that's what supporting non-MMC CD-R drives would amount to.
Supporting quirky MMC drives should be done just like most other
hardware, though.
Just because the API is there doesn't mean we should go through the work
to support that API when we have something else that already works.
It would be a duplication of functionality. Why reinvent the wheel
when the wheel we have works very well?
For the same reason that CAM replaced the old SCSI system - because
the replacement is an improvement! Sure, it won't work with
non-standard devices, but those should be a shrinking minority.
I don't think you've made the case that the replacement is an improvement.
cdrecord at the moment has more features than burncd, and seems to work
well.
Well, I don't agree on that assesment about how well cdrecord
works. I've found it to be finicky and a PITA.
The only thing you've said about cdrecord is that the code is a mess
(below). I don't think it's that bad. I might do things differently,
but things are going to be more complicated when you try to support a large
number of OSes.
You forgot the problems of it staying in sync with the OS. I've had
both build breakages, and binaries that quit working after starting to
write a blank (thus ruining it) after doing an OS upgrade.
If you want standard burner support with the OS (isn't that what you're
really getting at here?), why not just import cdrecord into the contrib
tree and be done with it? It's GPLed, so it wouldn't be any more onerous
license-wise than many of the other tools we have in the tree.
Well, that would certainly solve the sync problem - but I'm not
willing to
problems with /usr/bin/awk
I have been running cvsup nightly to grab -current and -ports,
and noticed some strangeness with awk that seemed to start last
week sometime.
When building /usr/ports/lang/guile, the build exited with an
awk 'internal error' and a log on the console that awk had
exited on signal 6. To test my theory that the problem was
indeed awk (rather than the guile port), I copied over a copy
of awk from a 4.1-R system. After doing so, the guile port was able to
build and install without any problems.
Here is the output from the make build:
PATH=.:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
:/usr/X11R6/bin:/root/bin ./guile-doc-snarf eval.c -DHAVE_CONFIG_H
-I.. -I./.. -I../libltdl -O
-pipe -Wall -Wmissing-prototypes eval.c eval.x || { rm eval.x; false; }
awk: ./guile-snarf.awk:17: (FILENAME=- FNR=9680) fatal error: internal
error
Abort trap - core dumped
*** Error code 1
Regards,
Tony.
#include ".sig"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 19:17:37 -0500, Mike Meyer wrote: Kenneth D. Merry writes: On Mon, Aug 21, 2000 at 18:19:47 -0500, Mike Meyer wrote: Kenneth D. Merry writes: Which should actually be smaller than the flood of mail saying things like "why doesn't burncd support my nice, standard-compliant CD-R?" In fact, according to the documentation that comes with cdrecord, it would be *much* smaller, because all the SCSI CD-Rs released in the last few years have been MMC. I think it would generate a fair amount of mail, certainly a lot more than the amount of mail I've seen asking why burncd doesn't support SCSI CD-Rs. (which is very, very little) What evidence do you have that it would generate a fair amount of mail? Prior experience. People get confused relatively easily, no matter how many places something is documented and no matter how many times you explain something on a mailing list. Um - that's not evidence, that's an argument. But prior experience shows that having two tools for burning cd's generates - in your own words - "very, very little" mail. By the same argument, including some drives in both sets of tools shouldn't raise the confusion level. Hopefully not, but people have a tendency to make simple things complicated. :) One piece of writing functionality I *do* intend to put in the kernel is support for DVD-RAM drives. (It's mainly hung up with disklabel problems at the moment.) Why those and not CD-R drives? Especially when, from what I can tell, the situation with those is even *more* confused than it is with CD-Rs, as there are multiple writable DVD formats, and they are changing. Or are you talking about support for the non-9660 file system that some of them use? Well, DVD-RAM drives have a totally different read/write model than CD-R or CD-RW drives. They function pretty much like a MO disk, at least when there is a writable disk in them. Supporting them, at least minimally, is a one line change. (To add write support to the cdevsw in the driver. They really are that much like disks. There's really no additional detection required, since the drive will spit out the command if the media isn't writeable.) CD-R's don't fit within the normal Unix read/write semantics, thus the reason that we have to use userland programs and an ioctl mechanism (whether with burncd or cdrecord) in order to go through the different states required to get the data written. You can't just say "write" and be done. You have to fixate, etc. I'm not working on filesystems at all. Several other folks have talked about doing UDF support, and I'm not really up for tackling that anyway. You can put a UFS filesystem on a DVD-RAM, or you can put an ISO9660 filesystem on one, or whatever other filesystem you want. All I'm working on is the driver-level mechanism to enable write support. Just curious - do you feel that you have to support old disk drives that don't properly adhere to the SCSI standard, or otherwise behave in strange ways? Say some of DEC's old drives that don't spin up on power on, but have to be told to do so by the OS? A quick check doesn't reveal any support for such things, but I may have missed it. You missed it. In the error recovery code. If a drive returns an error code that we understand to mean "spin me up", we send a start unit command to the disk. (No more than four start units may be oustanding at one time, to avoid overloading power supplies.) We also have various quirk tables for devices that do odd things. So yes, I think we do need to support older and/or quirky hardware, to a certain point. Does this extend to the point of supporting things that happen to share a physical connector with SCSI, but otherwise aren't SCSI? Because that's what supporting non-MMC CD-R drives would amount to. Not really. Non-MMC CD-Rs not only use the same connectors and cables, they also comply with the SCSI standard. They use the same bus protocol, respond to inquiries and test unit ready commands just like everything else. They also act like standard CDROM drives when you're reading data. They primarily differ in the mechanisms and quirks needed to do writes. Supporting quirky MMC drives should be done just like most other hardware, though. Just because the API is there doesn't mean we should go through the work to support that API when we have something else that already works. It would be a duplication of functionality. Why reinvent the wheel when the wheel we have works very well? For the same reason that CAM replaced the old SCSI system - because the replacement is an improvement! Sure, it won't work with non-standard devices, but those should be a shrinking minority. I don't think you've made the case that the replacement is an improvement. cdrecord at the moment has more features than burncd, and seems to work well. Well, I don't
Re: Why no CDR ioctls for SCSI cds?
Kenneth D. Merry writes: Does this extend to the point of supporting things that happen to share a physical connector with SCSI, but otherwise aren't SCSI? Because that's what supporting non-MMC CD-R drives would amount to. Not really. Non-MMC CD-Rs not only use the same connectors and cables, they also comply with the SCSI standard. They use the same bus protocol, respond to inquiries and test unit ready commands just like everything else. They also act like standard CDROM drives when you're reading data. They primarily differ in the mechanisms and quirks needed to do writes. No, they comply with *part* of the SCSI standard - the part needed to do reads. But drives with the same connectors comply with *part* of the standard - the part that defines the connector. Of course that isn't the entire picture - that's why I asked. Again, arguing about this solution being "halfway" when you're ignoring half the functionality of the standard seems hypocritical. Not really. We've had a solution for supporting the other (writing) half of the standard from the beginning -- cdrecord. That solution has also covered non-MMC drives from the beginning. I've been told (repeatedly) that ports are *not* part of FreeBSD. Therefore, we don't have a solution. We have a pointer to one provided by someone else. If doing burncd support for MMC drives were a step on the way for getting support for the various other types of drives that cdrecord supports, it would be a different story. (We'd also want to see what features were available in cdrecord but not burncd and look into adding those as well.) In other words, supporting the standard would only be reasonable if it's a start towards embedding cdrecord in the kernel, which we have already agreed is unreasonable. Yes. That sounds like "I don't want to do it for religious reasons" to me. As it is, importing cdrecord into the tree would solve what seem to be your major objections -- that cdrecord gets out of sync with the OS because it isn't built with the OS, and that we don't ship a way of burning SCSI CDs with the OS. Your doing that would certainly be a step in the right direction. Well, I didn't say I wanted to be the one to do it. :) I really know very little about vendor branch imports, etc. Well, you have someone willing to fix the problem - but you object to the fix for religious reasons. The fix you're willing to accept you're not willing to implement. Sounds like a bureaucracy to me. Do you claim ownership of all the drivers in cam/scsi, or can someone with more tolerant religious convictions add a driver that's a clone of the CD driver + MMC extensions that gets first crack at CDROM drives, and recognizes MMC drives, but not others? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. As cdrecord isn't part of FreeBSD, this is clearly the wrong place to ask about that. Joe Schilling watches [EMAIL PROTECTED], and that's the place to ask. I've been told that ATAPI CD-Rs use the same basic command set (MMC) as SCSI ones, only they don't have legacy problems - so it should be possible. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 22:38:11 -0500, Mike Meyer wrote: Kenneth D. Merry writes: Of course that isn't the entire picture - that's why I asked. Again, arguing about this solution being "halfway" when you're ignoring half the functionality of the standard seems hypocritical. Not really. We've had a solution for supporting the other (writing) half of the standard from the beginning -- cdrecord. That solution has also covered non-MMC drives from the beginning. I've been told (repeatedly) that ports are *not* part of FreeBSD. Therefore, we don't have a solution. We have a pointer to one provided by someone else. That's been good enough for most everyone else I said I'm open to having it in the contrib tree, what more do you want here??? If doing burncd support for MMC drives were a step on the way for getting support for the various other types of drives that cdrecord supports, it would be a different story. (We'd also want to see what features were available in cdrecord but not burncd and look into adding those as well.) In other words, supporting the standard would only be reasonable if it's a start towards embedding cdrecord in the kernel, which we have already agreed is unreasonable. Yes. That sounds like "I don't want to do it for religious reasons" to me. *sigh* As it is, importing cdrecord into the tree would solve what seem to be your major objections -- that cdrecord gets out of sync with the OS because it isn't built with the OS, and that we don't ship a way of burning SCSI CDs with the OS. Your doing that would certainly be a step in the right direction. Well, I didn't say I wanted to be the one to do it. :) I really know very little about vendor branch imports, etc. Well, you have someone willing to fix the problem - but you object to the fix for religious reasons. The fix you're willing to accept you're not willing to implement. Sounds like a bureaucracy to me. There are over 200 committers, and there are plenty of them who are capable of doing it. I'm willing to support its inclusion in the tree, but what I'm not willing to do is commit to spending the time to put cdrecord in the tree and keep it up to date. Would you rather I stick it in the tree and then never update it for lack of time? Do you claim ownership of all the drivers in cam/scsi, or can someone with more tolerant religious convictions add a driver that's a clone of the CD driver + MMC extensions that gets first crack at CDROM drives, and recognizes MMC drives, but not others? Talk to Matt [EMAIL PROTECTED], or Justin [EMAIL PROTECTED], and see what they have to say. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
I'm sorry- I really haven't been paying much attention to this, but it seems it's sort of on the wrong mailing list, isn't it? Mike- can you take a deep breath and send a summary of what you see the techical problems/requirements are to the freebsd-scsi alias? I'll admit that I'm not up on a lot of this...oops- I just saw mail from you... taking offline To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. Spoke to soon - according to the pkg/DESCR file, it should work on them now. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
On Mon, Aug 21, 2000 at 23:18:50 -0500, Mike Meyer wrote: Christopher Masto writes: I'd rather see cdrecord work on ATAPI CD-Rs. burncd gives me a lot of trouble. Spoke to soon - according to the pkg/DESCR file, it should work on them now. It needs an ATAPI passthrough mechanism to work. (FreeBSD doesn't have one at the moment.) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(no subject)
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
People running with LOCALBASE set to something other than /usr/local?
I'm curious - are there any committers who regularly use a system with LOCALBASE set to something other than /usr/local? Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
