proposed pkg_delete change
I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. If nobody is interested in doing this, I can do it when I have some spare time (finals here at school). And then submit patches. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
The Pyramid series of machines used to have block tape devices, such that one was able to boot a repair kernel and ro root fs off the 1600bpi reel-to-reel deck. Not unaturally, one was discouraged from doing a recursive find on that fs. Stephen (who used to have thoughts of doing the same with his old QIC-150) -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world breakage in usr.bin/kdump
Got the following with up to the minute sources: cc -O -pipe -I/usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/../ktrace -I/usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/../.. -c /usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/kdump.c sh /usr/amd/realmounts/slave/usr/current/src/usr.bin/kdump/mkioctls /usr/include ioctl.c In file included from :55: /usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition In file included from :66: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the previous definition make: don't know how to make /usr/obj/usr/amd/realmounts/slave/usr/current/src/i386/usr/include/machine/random.h. Stop -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Abit BP6 - UDMA66 and non IBM disks
I have the following disk: ad4: 9787MB WDC AC310200R [19885/16/63] at ata2-master using UDMA33 and am experiencing hangs when I run it with UDMA66. I originally suspected this to be a cooling problem. But uncommenting the hlt instruction and reducing the temperature by 10 deg C, didn't help it. I read the threads from Feb, where it was said that non IBM disks had problems with the UDMA66 code in FreeBSD. Some of you said that the disks worked just fine with other OSes. I'd like to know if there has been a change in status of the UDMA66 code. The specific error messages before the hang: ad4: READ command timeout - resetting ata2: resetting devices hang -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
[Charset ISO-8859-1 unsupported, filtering to ASCII...] It seems Arun Sharma wrote: I have the following disk: ad4: 9787MB WDC AC310200R [19885/16/63] at ata2-master using UDMA33 and am experiencing hangs when I run it with UDMA66. That exact disk model cant do UDMA66 reliably, even Linux has it on the blacklist in the driver I read the threads from Feb, where it was said that non IBM disks had problems with the UDMA66 code in FreeBSD. Some of you said that the disks worked just fine with other OSes. Not all non IBM disks has problems, that was not the message back then, at least not from me. What I said, and still says, is that Maxtor and WDC has a bad reputation on making drives that can't work reliably with UDMA66, quantum has its share too but not so bad. IBM's on the other hand works as expected... Perhaps that is why Western Digital has gotten the nick name around here of ``We Don't Care''. :-) In all seriousness we stopped using WD drives in the retail store front computers over 2 years ago due to they problems we have had with them. Been using Fujitsu with very good luck, and IBM on the higher end and been very happy with them. We use to be big in Quantum scsi drives, but with IBM finally getting it's supplier side act togeather as far as channel avaliability of the SCSI products we've switched the AAI commercial server side over to them. I can't remeber when the last problem was, ohh.. yea... 1 doa unit out of 32 drives, probably caused during the assembly process of stuffing them in the kingston canisters (a not too gental operation). Infact now that I think about it that is the only problem we have had with IBM drives in over 500 units sold. Not bad, thats a .2% AQL, something I don't recall seeing in any disk drive product line we have used over the last 8 years !! -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. That would be cool, yes. If you've got the time to do it, I think it would be well-worth the effort. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
On Mon, May 08, 2000 at 02:10:28AM -0400, Kenneth Wayne Culver wrote: I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. If nobody is interested in doing this, I can do it when I have some spare time (finals here at school). And then submit patches. That would have saved me a *lot* of time about a month ago when I went and weeded out all of my packages when my /usr filled up. I basically did what you are proposing by hand and it took forever. e.g. pkg_delete some_package - oops, it depends on pkg_xxx, delete that, oops, it depends on pkg_xxx2, and so on, when in reality that only reason any of those additional packages were installed were for the original package. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
* From: Kenneth Wayne Culver [EMAIL PROTECTED] * dependancies, I think it would be a nice idea to add an option to * pkg_delete to automatically delete all dependancies that aren't currently * used by anything else. If nobody is interested in doing this, I can do it Be careful about that "aren't currently used by anything else" part. If you already had a port A installed, and then later installed B (which just happens to depend on A), you could get A erased when you erase B. You probably need to change pkg_add too, so that it will note somewhere on A's dependency list that it was installed by which port, and let pkg_delete check it. It usually goes like this: @ install B, pkg_add installs A too, and mark A that it was "installed by B" @ deinstall B, pkg_delete checks A, finds the mark and deletes it too While, if you had installed A beforehand, it will be like: @ install A (...few months pass...) @ install B, nothing special happens re the flag @ deinstall B, pkg_delete checks A and doesn't find the flag, so doesn't delete it You can also add a flag to pkg_delete to override said check in case you know you installed A just for the purpose of installing B. If you come up with the file format and patches to pkg_*, I'll modify bsd.port.mk so it will DTRT on dependencies installed by "make install". Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
On Mon, May 08, 2000 at 02:30:59AM -0700, Jordan K. Hubbard wrote: (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the [...] That would be cool, yes. If you've got the time to do it, I think it would be well-worth the effort. Even cooler: A tree-like drawing of the dependency graph, allowing me to do right-click--toggle keep/erase for given port left-click--select port and all dependencies for erasure (excluding dependencies shared by another port not previously left-clicked) -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
"Rodney W. Grimes" wrote: [Charset ISO-8859-1 unsupported, filtering to ASCII...] It seems Arun Sharma wrote: I have the following disk: ad4: 9787MB WDC AC310200R [19885/16/63] at ata2-master using UDMA33 and am experiencing hangs when I run it with UDMA66. That exact disk model cant do UDMA66 reliably, even Linux has it on the blacklist in the driver I read the threads from Feb, where it was said that non IBM disks had problems with the UDMA66 code in FreeBSD. Some of you said that the disks worked just fine with other OSes. Not all non IBM disks has problems, that was not the message back then, at least not from me. What I said, and still says, is that Maxtor and WDC has a bad reputation on making drives that can't work reliably with UDMA66, quantum has its share too but not so bad. IBM's on the other hand works as expected... Perhaps that is why Western Digital has gotten the nick name around here of ``We Don't Care''. :-) In all seriousness we stopped using WD drives in the retail store front computers over 2 years ago due to they problems we have had with them. Been using Fujitsu with very good luck, and IBM on the higher end and been very happy with them. We use to be big in Quantum scsi drives, but with IBM finally getting it's supplier side act togeather as far as channel avaliability of the SCSI products we've switched the AAI commercial server side over to them. I can't remeber when the last problem was, ohh.. yea... 1 doa unit out of 32 drives, probably caused during the assembly process of stuffing them in the kingston canisters (a not too gental operation). Infact now that I think about it that is the only problem we have had with IBM drives in over 500 units sold. Not bad, thats a .2% AQL, something I don't recall seeing in any disk drive product line we have used over the last 8 years !! We have had the same luck with IBM also. Maxtor(Diamond Max Plus) is also very close. Except for several 15GB models(we since have dropped that model) we have seen a 0 failure rate with them. I don't recall ever seeing quality, price and performance like we do now. The same goes for several brands of motherboards too. This has to be the PC's golden age. Look at memory prices and quality. 1GB of PC133 can be had for under $900 and again with the assurance that a failure would be pretty rare. Regards, -- Ted Sikora Jtl Development Group [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Deai press
$B!!!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B $BF|K\0l$N=P2q$$%5%$%H$rC5$9%a!%k?7J9$G$9(B $B!!!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A!A(B $B:#2s$O!"=w@-$,4IM}$7$F$$$k#3%5%$%H$r$4R2p$$$?$7$^$9!#(B $B$=$l$$l$N9-JsC4EvT$+$i$N@$rJ9$$$F$/$@$5$$!#(B $B:#8e$3$N=P2q$$?7J9$,$4ITMW$JJ}$O!"(B $B62$lF~$j$^$9$,$3$A$i$K$3$N$^$^$4EAw$/$@$5$$!#(B [EMAIL PROTECTED] --- $B(.(/(B $B(-(B $B(-!Z#1![(B $B(-$3$s$K$A$O!#=w@-MQ#W#e#b%^%,%8%s$N:dK\$5$($j$G$9!#(B $B(-=P2q$$%5%$%H(Bhttp://www.aimail.co.jp$B$K$D$$$F$G$9!#(B $B(-;Ke=i!"%A%c%C%H$+$i%H!%/$,$G$-$k?7%7%9%F%`!*(B $B(-(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B $B(-!!=w@-MQ#W#e#b%^%,%8%s$,=w@-FIT$N0U8+$rJ9$$$F(B $B(-!!A4$/?7$7$$??LLL\$J=P2q$$%5%$%H!V(Baimail$B!W$r:n$j$^$7$?!#(B $B(-!!$@$+$i!"B$N=P2q$$%5%$%H$H$OA4$/0c$$$^$9!*(B $B(-!!Kh7n#2#0#0K|1_AjEv$N%W%l%%s%HIU$-!*(B $B(-(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B(-(Bhttp://www.aimail.co.jp $B(-(B $B(-(,(,!D!D!E!%M%C%H;Ke=i!*%A%c%C%H$+$i%H!%/$,$G$-$^$9(B $B(-(Baimail$B$G$O!"%m%0%$%sCf$N%a%s%P!$,o$KI=($5$l$F$$$^$9$N$G(B $B(-#2%7%g%C%H%A%c%C%H!J%Q%=%3%s!K$d#2%7%g%C%H%H!%/!JEEOC!K$,!"(B $B(-?=$79~$s$G$9$0$K$G$-$k$h$$K$J$C$F$$$^$9!#(B $B(-(B $B(-EEOC$GAjj$HB:]$K$*$7$c$Y$j$9$k$3$H$K$h$C$F!"(B $B(-Ajj$N$3$H$r$h$j?H6a$K46$8$k$3$H$,$G$-$k$G$7$g$!#(B $B(-(B aimail$B$G$O!"$3$N%7%9%F%`$rB8=$9$k$?$a$K!"(B $B(-A49q#62U=j$K@lMQ$NEEOC%;%s%?!$r@_$1$^$7$?!#(B $B(-(B $B(-(,(,!D!D!E!6C0[E*$JCK=wHf$G!"CK@-05E]E*M-Mx$G$9(B $B(-8=:_$NCK=wHf#3!'#7!*05E]E*$K=w@-$,B?$$$N$O!"=w@-MQ%%'%V(B $B(-%^%,%8%s$r#9#7G/$+$iH/9T$7$F$$$kJ@R$@$+$i$3$=$G$9!#(B $B(-$^$?!"Kh7n#2#0#0K|1_AjEv$N%V%i%s%IIJ$J$I$N%W%l%%s%H$r(B $B(-B;\$7$F$$$k$?$a!"$?$/$5$s$N=w@-$,=8$^$j$^$9!#(B $B(-%W%l%%s%H$K$O!":#$G$OF~j:$Fq$J(BSONY$B$N$"$N@.D9$9$k%m%\%C%H8$!"(B $B(-(Baibo$B$bKh7n#3Bf$:$D=P$F$$$^$9!#(B $B(-(B $B(-=w@-2q0wMM$NJ}$,B?$$$N$G!VCK@-$+$i%a!%k$,$3$J$$!W$H(B $B(-%/%l!%`$,Mh$k$[$I$G$9!#(B $B(-(B $B(-(,(,!D!D!E!$=$3$G$3$N$?$S!"=w@-2q0w$N0Y$KCK@-2q0w$rA}$d$9%i%s%/$r(B $B(-:n$j$^$7$?!#CK@-$b!"%2%9%H2q0w$H$7$FL5NA$G$4F~l$G$-$^$9!#(B $B(-?tB?$/$N5!G=$rMQ0U$7$F$"$J$?$N=P2q$$$r%5%]!%H$$$?$7$^$9!#(B $B(-$$R0lEY!"$=$NB?:L$J5!G=$K6C$$$F$/$@$5$$!*!*!*(B $B(-(B $B(1(0(B $B!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v(B $B(.(/(B $B(-(B $B(-!Z#2![(B $B(-$O$8$a$^$7$F!#!H%a%kM'C5$=!*!I#A#Q#C$N(BAYA$B$G$9!#(B $B(-=P2q$$7G(HD(Bhttp://www.aqc.co.jp$B$r!"(B $B(-#2#0#0#0G/#47n$K%*!%W%s$7$?$P$+$j$G$9!*(B $B(-(B $B(-(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B $B(-=w@-4IM}T$K$h$k!"=w@-$N$?$a$N%Z!%8$G$9!#(B $B(-!!%*!%W%s$7$?$F$N%5%$%H$@$+$i!"(B $B(-=q$-9~$_$7$F$$$k=w@-$b%K%e!%U%'!%9$P$+$j!*(B $B(-(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B(-(Bhttp://www.aqc.co.jp $B(-(B $B(-(,(,!D!D!E!CO0h$r#2$D$K8BDj$7$?7G(HD!#(B $B(-$?$/$5$s$"$l$P!"NI$$$Hb$N$G$O$"$j$^$;$s!#(B $B(-%*!%W%s$7$?$F$@$+$i$3$=!"4X@CO6h!?4XElCO6h$N#2$D$r8BDj!#(B $B(-%a!%kM'C#$rC5$7$F$k?M$O!"$$R=q$-9~$_$KMh$F$/$@$5$$!*!*!*(B $B(-$=$7$F!"%a!%kM'C#$+$i$N!"%9%F%C%W!%"%C%W$O:#$do1!*(B $B(-(B $B(1(0(B $B!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v!v(B $B(.(/(B $B(-(B $B(-!Z#3![(B $B(-$"$j$,$H$$4$6$$$^$9!#(BFORTUNE$B$G$9!#(B $B(-8D?M$N%5%$%H$J$N$K$b$+$+$o$i$:!"h$je$2$F$/$@$5$C$F(B $B(-46U$7$F$^$9!*(B $B(-7G(HD$r;H$C$F!"2F$^$G$KH`;a!H`=w$r%2%C%H$7$^$7$g"v(B $B(-(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B $B(-#2#0:M@lLg3X9;@8$G!"#H#P$b:n$j$?$F!#!#!#(B $B(-$*$O$:$+$7$$8B$j$G$9$,!"$_$J$5$s$N@$r%P%M$K(B $B(-$I$s$I$s2~NI$7$F$$$/$N$G$h$m$7$/!*(B $B(-(1(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(0(B $B(-(Bhttp://machikado.gaiax.com/home/fortune/ $B(-(B $B(-(,(,!D!D!E!7G(HD$O#1$D$@$1$I!#!#!#!#(B $B(-=w$N;R$,5$7Z$K=q$1$k7G(HD$,$[$7$$$M!"$H3X9;$NM'C#$HOC$7$F$$$?$3$H$+$i!"(B $B(-%*!%W%s$7$F$_$^$7$?!#(B $B(-%a%kM'!Nx?MJg=8Cf$N?M$K!"9,$;$,K,$l$k$h$$K(BFORTUNE$B$HLIU$1$^$7$?!#(B $B(-KhF|$NCB@82V$H$=$N2V8@MU$b(BCALENDAR$B$K$N$;$F$^$9!#$$RM7$S$KMh$F$/$@$5$$!*(B $B(-(B $B(1(0(B $B:G8e$^$G$*FI$_$$$?$@$$$F$"$j$,$H$$4$6$$$^$7$?(B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: proposed pkg_delete change
I have a suggestion for pkg_delete: Very often when I'm deleting a package (such as kde, after testing the port) I want to delete that package, and all it's dependancies; instead of going around looking for the dependancies, I think it would be a nice idea to add an option to pkg_delete to automatically delete all dependancies that aren't currently used by anything else. That would be cool, yes. If you've got the time to do it, I think it would be well-worth the effort. Alright, I'll get on it probably in 2 weeks when finals are over. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp request that we send. The above is achieved by virtue of sending the ARP request (anyone watching ARP messages will learn that we are the address in the "tell x.x.x.x" field). What we're trying to provoke is someone else saying x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message on our system informing the administrator that someone else is already using that IP address. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
In message [EMAIL PROTECTED], "David O'Brien" writes: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. Make it MAKEDEV -num_of_devs dev_name and there will be no ambiguity. -- 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
Re: gratuituous arp for multiple IP addresses
I stand corrected again, as needed. The gratuituous arp should be formatted in whatever the correct way is. The machine that encountered loss of connectivity due to interface IPs being swapped is running 3.4-STABLE that was cvsup'd on January 7, 2000. If in fact some change was made in the sending of gratuituous arp since them to correct the problem, then nothing more needs to be done. Perhaps it would be useful for 'ifconfig' to have an option to send a gratuituous arp upon request by the user, without having to reconfigure any IP address. Rahul On Mon, 8 May 2000, Mike Smith wrote: By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul That won't achieve the desired result, which is to complain if someone _else_ replies to the arp request that we send. The above is achieved by virtue of sending the ARP request (anyone watching ARP messages will learn that we are the address in the "tell x.x.x.x" field). What we're trying to provoke is someone else saying x.x.x.x is-at xx.xx.xx.xx.xx.xx, which will result in a console message on our system informing the administrator that someone else is already using that IP address. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
David O'Brien wrote: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. The good part of this solution is that it's backwards compatible. If the first argument is an integer and the second a device name without a suffix we do the new thing, if not we revert to the traditional behaviour. bde: what do you think? Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. (the CLOBBER ability should not have been ripped out). wormio.h is no longer an active file, so you need to manually delete it from /usr/include. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LINT broken. (in_cksum changes)
I sent a note to the committer on these last night. LINT must need some modification, because the error is also present in netinet6/ipsec.c. There are some ifdef's around it that point to LINT needing some extra options. On Sun, 7 May 2000, Nick Hibma wrote: Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I just couldn't be bothered to fix it. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release failure during ports
On Sun, May 07, 2000 at 07:15:56PM -0400, John W. DeBoskey wrote: fyi... === Creating README.html for tkrat-1.2 === mail/tkrat2 This belongs in [EMAIL PROTECTED], NOT [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Sun, May 07, 2000 at 02:56:17PM -0700, Mike Smith wrote: We had this argument the other day, and you clearly didn't understand. Yes I did. We agreed to not agree and to not argue it. :-) Which is why I've never brought it up with you again. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
David O'Brien wrote: On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. (the CLOBBER ability should not have been ripped out). wormio.h is no longer an active file, so you need to manually delete it from /usr/include. It should have been deleted by the appropriate makefile before the new headers are installed. Obsoleting header files can create as much backward compatibility problems as obsoleting functions or options can. It should have been dealt with accordingly... -- 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: proposed pkg_delete change
On 8 May 2000, Satoshi - Ports Wraith - Asami wrote: Be careful about that "aren't currently used by anything else" part. If you already had a port A installed, and then later installed B (which just happens to depend on A), you could get A erased when you erase B. Have a -n mode (-nothing) which prints a list of actions it would take so you can review. You probably need to change pkg_add too, so that it will note somewhere on A's dependency list that it was installed by which port, and let pkg_delete check it. This could be done with an extra binary field in +REQUIRED_BY showing whether the package was installed by a parent. pkg_delete would recursively remove it if 1) There was only a single +REQUIRED_BY entry, and 2) The parent package bit is set. 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: a better idea for package dependencies
On Mon, 8 May 2000, Kenneth Wayne Culver wrote: pkg_delete -d package-version (or some other unused switch for dependancy) This might be a good option, but there should also be an automatic mode, whether or not it's the default. remove pkg_version_dependant [Y] ? y removed! remove pkg_version_dependant2 [Y] ? y error: some_other_package depends on pkg_version_dependant2! pkg_version_dependant2 is required by the following packages: foo-1.0 bar-2.0a blee-0.0001 remove pkg_version_dependant2 [Y] ? y 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: Small MAKEDEV bug
On Mon, 8 May 2000, David O'Brien wrote: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. I don't buy it :-). This syntax is similar to a special case of the syntax of jot(1). It's better to use jot(1) directly, e.g.: MAKEDEV $(jot -w da 2 0)# make 2 acd devices beginning at acd0 Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MAKEDEV warning with sysinstall ?
I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and when I first launch /stand/sysinstall after the system has start, the following message appears : ... /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices I searched the list archives and find some informations about this, but nothing that helps me understand why I get this message. The only time it happens is when I use sysinstall for the first time after the PC has start. If I'm using sysinstall again without prior reboot, there's no such message. But if I reboot and use sysinstall again, the message shows up again. I ran MAKEDEV all, but the message still appear. The messages I found about this on the archives says to do a 'ls -l /dev | grep ^b', and to remake all devices listed, but there's no device listed when I'm doing the 'ls -l /dev | grep ^b'. Any idea about what could cause this message to come up ? Thanks, Erik de Zeeuw To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning with sysinstall ?
On Mon, May 08, 2000 at 03:41:55PM -0500, Erik de Zeeuw wrote: I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and when I first launch /stand/sysinstall after the system has start, the following message appears : ... /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices I searched the list archives and find some informations about this, but nothing that helps me understand why I get this message. This is because -current no longer has any block devices so /dev/MAKEDEV needs (well, it is cleaner) to remove the old device nodes. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning with sysinstall ?
In message [EMAIL PROTECTED], Erik de Zeeuw writes: I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and when I first launch /stand/sysinstall after the system has start, the following message appears : ... /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices I searched the list archives and find some informations about this, but nothing that helps me understand why I get this message. Any idea about what could cause this message to come up ? No, I havn't tracked down the last couple of causes of this, but I will try to reproduce it as you describe it with some debugging added. Thanks for the hint! -- 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
Re: rc.d startup scripts
On Sun, 7 May 2000, Doug Barton wrote: I'm going to reply to the system part of this too, replies to this thread should split off to -current. I have a design in mind for a new rc system that uses scripts with "start, stop, status" operators to both upgrade and downgrade services, where "services" are defined as groups of daemons/programs that work together. For example, "nfs" would be an example of a service, which would be subdivided into client and server, etc. Eivind Eklund made a prototype some time back which addressed this issue - you'd do well to take a look at that one first before reinventing the wheel :) 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: MAKEDEV warning with sysinstall ?
In the last episode (May 08), Poul-Henning Kamp said: In message [EMAIL PROTECTED], Erik de Zeeuw writes: I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and when I first launch /stand/sysinstall after the system has start, the following message appears : ... /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of block devices I searched the list archives and find some informations about this, but nothing that helps me understand why I get this message. Any idea about what could cause this message to come up ? No, I havn't tracked down the last couple of causes of this, but I will try to reproduce it as you describe it with some debugging added. How hard would it be to print the filename (or the device/inode) that triggers the warning? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV warning with sysinstall ?
In message [EMAIL PROTECTED], Dan Nelson writes:
In the last episode (May 08), Poul-Henning Kamp said:
In message [EMAIL PROTECTED], Erik de Zeeuw writes:
I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and
when I first launch /stand/sysinstall after the system has start, the
following message appears :
... /kernel: WARNING: run /dev/MAKEDEV before 2000-06-01 to get rid of
block devices
I searched the list archives and find some informations about this, but
nothing that helps me understand why I get this message.
Any idea about what could cause this message to come up ?
No, I havn't tracked down the last couple of causes of this, but I
will try to reproduce it as you describe it with some debugging added.
How hard would it be to print the filename (or the device/inode) that
triggers the warning?
Not at all (warning: cutpasted patch, tabs are screwed up!)
Index: kern_conf.c
===
RCS file: /home/ncvs/src/sys/kern/kern_conf.c,v
retrieving revision 1.75
diff -u -r1.75 kern_conf.c
--- kern_conf.c 2000/03/25 21:10:20 1.75
+++ kern_conf.c 2000/05/06 15:06:33
@@ -270,7 +270,8 @@
if (!whine) {
printf("WARNING: run /dev/MAKEDEV before 2000-06-01 to
get rid of block devices\n");
whine++;
}
+ printf("Whine: %d/%d\n", umajor(x), uminor(x));
return makebdev(umajor(x), uminor(x));
default:
Debugger("udev2dev(...,X)");
--
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
Re: Undocumented tape devices in pax(1)
In message [EMAIL PROTECTED] "David O'Brien" writes:
: On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
: OpenBSD only changed "rmt" to "rst" ("rsa" for us)
:
: Just "sa" for us -- "sa" is now a raw device and "rFOO" use is
: depreciated.
Leaving aside the 'r' question for the moment...
Should that be sa or ast? sa is the scsi device for any tape device
(formerly st or mt), while ast is for ide/atapi based tape drives.
The wt and wst devices referenced in our man pages are just plain
bogus. I think we've killed all ft references in the tree...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
In message [EMAIL PROTECTED] Matthew Jacob writes: : Oh, and in the updating of this, don't forget the FreeBSD usage of .ctl for : tape devices- as far as I know this is the only *BSD that has this. Which devices use .ctl? sa and ast don't seem to use them now (at the very least they aren't created by MAKEDEV by default). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
In the last episode (May 08), Warner Losh said: In message [EMAIL PROTECTED] Matthew Jacob writes: : Oh, and in the updating of this, don't forget the FreeBSD usage of : .ctl for tape devices- as far as I know this is the only *BSD that : has this. Which devices use .ctl? sa and ast don't seem to use them now (at the very least they aren't created by MAKEDEV by default). *.ctl is handy for getting status on a device that another process has open; if I'm dumping to /dev/nrsa0, I can run "mt -f /dev/rsa0.ctl status" on another tty and see what file/block position the tape is at. Dunno if it has any other use :) -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, May 08, 2000 at 15:42:01 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Matthew Jacob writes: : Oh, and in the updating of this, don't forget the FreeBSD usage of .ctl for : tape devices- as far as I know this is the only *BSD that has this. Which devices use .ctl? sa and ast don't seem to use them now (at the very least they aren't created by MAKEDEV by default). The sa driver does use the control nodes, whether or not they're actually created by MAKEDEV. (Look in saopen().) It's useful to be able to get status on your tape drive while a backup is going on via the control node, e.g.: mt -f /dev/rsa0.ctl status Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
In message [EMAIL PROTECTED] "Kenneth D. Merry" writes: : The sa driver does use the control nodes, whether or not they're actually : created by MAKEDEV. (Look in saopen().) It's useful to be able to get : status on your tape drive while a backup is going on via the control node, : e.g.: : : mt -f /dev/rsa0.ctl status OK. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
Actually, it has to do with the pkg_ commands, which I believe are built when you make world... and aren't part of the ports, so I assumed that since these are part of -current, and changes would be made to -current, it's better to send to -current. Sorry for any inconvenience. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 8 May 2000, David O'Brien wrote: On Mon, May 08, 2000 at 02:26:42PM -0400, Kenneth Wayne Culver wrote: Instead of automatically deleteing the dependencies, I think maybe it This belongs on [EMAIL PROTECTED], not [EMAIL PROTECTED] has it has *nothing* to do with -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: a better idea for package dependencies
Alright, I'll try to do it after I get something working. = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 8 May 2000, Kris Kennaway wrote: On Mon, 8 May 2000, Kenneth Wayne Culver wrote: pkg_delete -d package-version (or some other unused switch for dependancy) This might be a good option, but there should also be an automatic mode, whether or not it's the default. remove pkg_version_dependant [Y] ? y removed! remove pkg_version_dependant2 [Y] ? y error: some_other_package depends on pkg_version_dependant2! pkg_version_dependant2 is required by the following packages: foo-1.0 bar-2.0a blee-0.0001 remove pkg_version_dependant2 [Y] ? y 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: Small MAKEDEV bug
Bruce Evans wrote: On Mon, 8 May 2000, David O'Brien wrote: On Sun, May 07, 2000 at 03:27:07PM -0400, Jeroen C. van Gelderen wrote: Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" I agree with this syntax and after sending my message to you, was sitting there thinking "MAKEDEV num_of_devs dev_name" would make a really nice clear syntax. If you can get BDE's buy-in and other BSD traditionalists I think this would be great. I don't buy it :-). This syntax is similar to a special case of the syntax of jot(1). It's better to use jot(1) directly, e.g.: MAKEDEV $(jot -w da 2 0)# make 2 acd devices beginning at acd0 From this it follows that MAKEDEV should be modified to create just it's argument: MAKEDEV dev8 creates just dev8, not dev0-dev7. Otherwise MAKEDEV $(jot -w da 6 4) wouldn't work or violate POLA. Agreed? Now it's a question of "the UNIX way" vs. convenience/userfriendlyness :-) Is it acceptable to have all users juggle with jot(1) or can we build in a convenience syntax that covers 95% of all uses? I'd think the latter, otherwise we might as well force our users to use mknod(8) and chmod(1) directly instead of MAKEDEV; After all, MAKEDEV is just a convenient wrapper around those commands. So I'd still propose: MAKEDEV count device_name_without_suffix MAKEDEV device_name_with_suffix ... As a consolation, added such a special syntax can be added in a few lines at the top of MAKEDEV, after which it recursively calls MAKEDEV with the appropriate jot(1)-expanded device list. So it doesn't clobber the code. Thoughts? Cheers, Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
On Mon, May 08, 2000 at 06:56:03PM -0400, Jeroen C. van Gelderen wrote: I don't buy it :-). This syntax is similar to a special case of the syntax of jot(1). It's better to use jot(1) directly, e.g.: MAKEDEV $(jot -w da 2 0)# make 2 acd devices beginning at acd0 b$ which jot /usr/bin/jot b$ The jot utility doesn't appear to be in /bin. b$ echo '$(jot -w da 2 0)' | wc 1 5 17 b$ echo $(jot -w da 2 0) | wc 1 2 8 b$ Heh. /me mumbles something about the prototypical UNIX hacker... :-) -- Signature withheld by request of author. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, 8 May 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew Jacob
writes:
: Oh, and in the updating of this, don't forget the FreeBSD usage of .ctl for
: tape devices- as far as I know this is the only *BSD that has this.
Which devices use .ctl? sa and ast don't seem to use them now (at the
very least they aren't created by MAKEDEV by default).
Should be:
sa*)
umask $tape_umask
unit=`expr $i : '..\(.*\)'`
chr=14
case $unit in
[0-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9])
mknod rsa${unit}.ctl c $chr `saminor 1 ${unit} 0 0`
for m in 0 1 2 3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Abit BP6 - UDMA66 and non IBM disks
On Monday, 8 May 2000 at 9:57:54 +0200, [EMAIL PROTECTED] wrote: Not all non IBM disks has problems, that was not the message back then, at least not from me. What I said, and still says, is that Maxtor and WDC has a bad reputation on making drives that can't work reliably with UDMA66, quantum has its share too but not so bad. There are some WDC disks that work nicely. This is from a BP6 board too: ad0: 26105MB WDC WD273BA [53040/16/63] at ata0-master using UDMA33 ad1: 26105MB WDC WD273BA [53040/16/63] at ata1-master using UDMA33 ad2: 26105MB IBM-DPTA-372730 [53040/16/63] at ata2-master using UDMA66 ad3: 26105MB WDC WD273BA [53040/16/63] at ata3-master using UDMA66 As far as I know, the WD273BA is in reality a DPTA-372730 in disguise, so I guess I shouldn't be surprised. Anybody know if it's possible to put the original IBM firmware on these disks? I've been having trouble with this one in UDMA66 mode, also on a BP6. The system just hangs solid at random: ad4: 13042MB WDC WD136BA [26500/16/63] at ata2-master using UDMA66 It works fine on UDMA33. I notice that you have ad2 and ad3 running in UDMA66 mode. I didn't realise this was possible; I'll experiment. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, 8 May 2000, Dan Nelson wrote: In the last episode (May 08), Warner Losh said: In message [EMAIL PROTECTED] Matthew Jacob writes: : Oh, and in the updating of this, don't forget the FreeBSD usage of : .ctl for tape devices- as far as I know this is the only *BSD that : has this. Which devices use .ctl? sa and ast don't seem to use them now (at the very least they aren't created by MAKEDEV by default). *.ctl is handy for getting status on a device that another process has open; if I'm dumping to /dev/nrsa0, I can run "mt -f /dev/rsa0.ctl status" on another tty and see what file/block position the tape is at. Dunno if it has any other use :) Eventually it will have/set more extended error information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world breakage in usr.bin/kdump
On Mon, 8 May 2000, David O'Brien wrote: On Sun, May 07, 2000 at 11:36:45PM -0700, Doug Barton wrote: /usr/include/sys/wormio.h:102: warning: `CDRIOCBLANK' redefined /usr/include/sys/cdrio.h:59: warning: this is the location of the In the old days cd /usr/src ; make -DCLOBBER includes would do what needs to be done. Cool. I figured it was something like that, but with all the header file stuff going around I guess the other question related to this is, why is the world build using the system's header files? Thanks, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
psm with SBLive == processor reset
Hi all, I (and a couple of other people as I recall) reported this some time back. My current kernel as of 5/1/00 still *resets* (not panics, does not pass go, does not collect $200) whenever I access a sound device. This goes for "realaudio plugin" from the linux netscape, mp3blaster, and a couple of other audio things I've tried. The exception is "cdplayer", which is quiet. Any progress on this front? Anything I can do to help? Thanks all. Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm with SBLive - processor reset
(Sorry all, I of course mistyped psm for pcm in the last message -- (I repeat for those with filtering software...) Hi all, I (and a couple of other people as I recall) reported this some time back. My current kernel as of 5/1/00 still *resets* (not panics, does not pass go, does not collect $200) whenever I access a sound device. This goes for "realaudio plugin" from the linux netscape, mp3blaster, and a couple of other audio things I've tried. The exception is "cdplayer", which is quiet. Any progress on this front? Anything I can do to help? Thanks all. Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, 7 May 2000, Doug Barton wrote: I'm going to reply to the system part of this too, replies to this thread should split off to -current. I have a design in mind for a new rc system that uses scripts with "start, stop, status" operators to both upgrade and downgrade services, where "services" are defined as groups of daemons/programs that work together. For example, "nfs" would be an example of a service, which would be subdivided into client and server, etc. Eivind Eklund made a prototype some time back which addressed this issue - you'd do well to take a look at that one first before reinventing the wheel :) Or you could use the system that NetBSD already has working. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] 381 plastic fruit for a starving nation To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Just curious, but wouldn't this be FreeSVR4??? :-) = | Kenneth Culver | FreeBSD: The best OS around.| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Tue, 9 May 2000, Tony Finch wrote: Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, 7 May 2000, Doug Barton wrote: I'm going to reply to the system part of this too, replies to this thread should split off to -current. I have a design in mind for a new rc system that uses scripts with "start, stop, status" operators to both upgrade and downgrade services, where "services" are defined as groups of daemons/programs that work together. For example, "nfs" would be an example of a service, which would be subdivided into client and server, etc. Eivind Eklund made a prototype some time back which addressed this issue - you'd do well to take a look at that one first before reinventing the wheel :) Or you could use the system that NetBSD already has working. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] 381 plastic fruit for a starving nation 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
