Re: umass/memory stick
On Tue, Mar 26, 2002 at 12:01:38AM +, Josef Karthauser wrote:
The patch applies cleanly, but the problem persists. Do I have to wibble a
knob or something?
No; if it doesn't work then we'll probably need a code quirk in there.
Okay, I've got the quirk, and it works now, although the pattern is rather coarse:
{T_DIRECT, SIP_MEDIA_REMOVABLE, RiteLink*, *,*},
/*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
Where do I derive the second pattern from?
Another thing: If the stick is connected at boot time, I get:
umass0: BBB reset failed, TIMEOUT
umass0: BBB bulk-in clear stall failed, TIMEOUT
umass0: BBB bulk-out clear stall failed, TIMEOUT
umass0: BBB reset failed, TIMEOUT
and then the port got disabled :-/
--
Wonderful \hbox (0.80312pt too nice) in paragraph at lines 16--18
Volker Stolz * [EMAIL PROTECTED]
Please use PGP or S/MIME for correspondence!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: burncd can't/won't write from pipe?
On Mon, 25 Mar 2002, Andrew Heybey wrote: AH I'm trying 4.5-RELEASE plus Soren's patches for the new ata driver and AH burncd. I just got a CD-RW drive, so I don't know if this used to AH work or not. AH AH The following does not work: AH AH mkisofs -R some_directory | burncd -s 8 data - fixate AH AH mkisofs exits fairly quickly without any error messages that I saw (it AH did print some messages to stderr about files names that it was AH using). AH AH burncd prints: AH AH next writeable LBA 0 AH writing from stdin AH AH fixating CD, please wait.. AH AH and then sits there for a long time, with no activity from the CD-RW. AH I can Ctrl-C out of it. AH AH If I do the steps separately, everything works fine: AH AH mkisofs -R dir ~/dir.iso AH burncd -s 8 data ~/dir.iso fixate AH AH Am I doing something dumb? What am I missing? It doesn't write from pipe on STABLE too. PR 36299. -- Alexei Evdokimov [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: newsyslog.conf - sudden error
Crist J. Clark (cjc) writes: That error message means it's having trouble reading the $W0D2. But I believe that is valid syntax. I can't see any recent changes to newsyslog(8) that might be making problems. Is there something special about that time? There wasn't some kind of DST-Standard time switch in the local timezone, was there (kind of early in the year for that)? Well, the one box that do work (4.4-STABLE) is located in the UK (hence another timezone -1) - whereas the other boxes are located in Italy and France. Could that be the problem ? Thanks. -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
One more serious ATA crash
Hi After cvsupping 4.5-STABLE yesterday my system didn't boot anymore. The ATA-mirror was defective and couldn't be rebuilt. I reinstalled the machine, cvsupped again and the same thing happened again. Booting the old kernel doesn't help either, the new ATA drivers seem to have crashed the disk. Here are the error messages (I had to type them down, so it's only the relevant things, I hope it's enough information.) [...] atapci0: VIA 82C686 ATA66 controller port ... on pci0 ata0: at [...] on atapci0 ata1: at [...] on atapci0 [...] atapci1: Promise ATA100 controller [...] on pci0 ata2: at [...] on atapci1 ata3: at [...] on atapci1 [...] ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed stray irq 7 ar0: 58610MB ATA RAID0 array [7471/255/63] status READY subdisks: 0 READY ad4: 58610MB Maxtor 4W060H4 [119081/16/63] at ata2-master UDMA100 acd0: CDROM SR243T at ata1-master PIO4 Mounting root from ufs:/dev/ar0s1a ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. ad4: removed from configuration ar0: ERROR - array broken ad4: deleted from ar0 disk0 ar0: ERROR - array broken done ar0: reading primary partition table: error reading fsbn 0 Root mount failed: 5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
stable breaks HighPoint support
It looks like something in stable seem to break High Point 404 support
using the vendor's drivers and RAID administrator software.
http://www.highpoint-tech.com/rr404_down.htm
raidtest2# gdb -k kernel.debug vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
SMP 2 cpus
IdlePTD at phsyical address 0x004d3000
initial pcb at physical address 0x00412b80
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id =
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc1e101ec
stack pointer = 0x10:0xd2d44da4
frame pointer = 0x10:0xd2d44da8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 165 (hptsvr)
interrupt mask = none - SMP: XXX
trap number = 12
panic: page fault
mp_lock = 0102; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 17
done
Uptime: 3m51s
twed0: detached
dumping to dev #ad/0x20001, offset 647192
dump ata0: resetting devices .. done
383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365
364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346
345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327
326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308
307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289
288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270
269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251
250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232
231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213
212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194
193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175
174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137
136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118
117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99
98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74
73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49
48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24
23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc01d833c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc01d87a4 in poweroff_wait (junk=0xc03b8d79, howto=-1069840305) at
/usr/src/sys/kern/kern_shutdown.c:595
#3 0xc034b1f5 in trap_fatal (frame=0xd2d44d64, eva=0) at
/usr/src/sys/i386/i386/trap.c:966
#4 0xc034ae6d in trap_pfault (frame=0xd2d44d64, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:859
#5 0xc034a9cb in trap (frame={tf_fs = -797835240, tf_es = 16, tf_ds = 16,
tf_edi = -757838092, tf_esi = 2, tf_ebp = -757838424,
tf_isp = -757838448, tf_ebx = -757838228, tf_edx = -1042194560,
tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1042218516, tf_cs = 8, tf_eflags = 66178, tf_esp = 0,
tf_ss = -757838384}) at /usr/src/sys/i386/i386/trap.c:458
#6 0xc1e101ec in ?? ()
#7 0xc1e0fbb7 in ?? ()
#8 0xc1e05066 in ?? ()
#9 0xc1e05a61 in ?? ()
#10 0xc01dd3e8 in sysctl_root (oidp=0x0, arg1=0xd2d44ef4, arg2=2,
req=0xd2d44e6c) at /usr/src/sys/kern/kern_sysctl.c:1041
#11 0xc01dd5a1 in userland_sysctl (p=0xd0727d40, name=0xd2d44ef4,
namelen=2, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfad,
newlen=28, retval=0xd2d44ef0) at /usr/src/sys/kern/kern_sysctl.c:1134
#12 0xc01dd457 in __sysctl (p=0xd0727d40, uap=0xd2d44f80) at
/usr/src/sys/kern/kern_sysctl.c:1070
#13 0xc034b539 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1079129004, tf_esi = -1079128884,
tf_ebp = -1079129076, tf_isp = -757837868, tf_ebx = 672168644,
tf_edx = 0, tf_ecx = 0, tf_eax = 202, tf_trapno = 22,
tf_err = 2, tf_eip = 671794456, tf_cs = 31, tf_eflags = 643, tf_esp
= -1079129136, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1167
#14 0xc0335a6b in Xint0x80_syscall ()
cannot read proc at 0
(kgdb) up
#1 0xc01d833c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
316
syslogd stopping to work
After upgrade from 4.2-REL to 4.4-SECURITY syslogd stops logging after several days of operation. I use it to log routers and such and it's pretty important for me. I don't want to use some different syslogd unless absolutelly necessary. It has happened already several times. 'ps axO wchan' gives '49083 sbwait ?? Is 0:06.07 /usr/sbin/syslogd -a '. CPU usage is 0% and the daemon stays like this forever. I have built the binary with debug information and have the coredump. The backtrace (I sent the daemon ABORT signal) is: #0 0x280a7674 in recvfrom () from /usr/lib/libc.so.4 #1 0x280b4cb4 in res_send () from /usr/lib/libc.so.4 #2 0x280b7e7d in res_query () from /usr/lib/libc.so.4 #3 0x280b7bd3 in freehostent () from /usr/lib/libc.so.4 #4 0x280b5d91 in getipnodebyaddr () from /usr/lib/libc.so.4 #5 0x280b5494 in getnameinfo () from /usr/lib/libc.so.4 #6 0x804b4e2 in cvthname (f=0xbfbff9e0) at /data/src/usr.sbin/syslogd/syslogd.c:1215 #7 0x804a18d in main (argc=9, argv=0xbfbffb8c) at /data/src/usr.sbin/syslogd/syslogd.c:546 #8 0x8049745 in _start () From my reading of it it seems syslogd tries to do reverse DNS loookup (will be disabled by -n ?) and hangs in it. It's quite possible that there was interminent problem with DNS. May be the problem isn't in syslogd but in resolver. Any suggestion as to what else to check? What to do when next time I catch syslogd frozen? I installed cron script which checks the syslog state and for about 14 days it didn't happen :-(. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: stable breaks HighPoint support
It seems Mike Tancsa wrote: It looks like something in stable seem to break High Point 404 support using the vendor's drivers and RAID administrator software. http://www.highpoint-tech.com/rr404_down.htm Highpoint's driver are for FreeBSD-4.5. They wont work with -stable and what is to become 4.6. The bright side is you wont even need them :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: stable breaks HighPoint support
At 02:21 PM 3/26/02 +0100, Søren Schmidt wrote: It seems Mike Tancsa wrote: It looks like something in stable seem to break High Point 404 support using the vendor's drivers and RAID administrator software. http://www.highpoint-tech.com/rr404_down.htm Highpoint's driver are for FreeBSD-4.5. They wont work with -stable and what is to become 4.6. The bright side is you wont even need them :) :-) True, but there is no equivalent RAID management software. ---Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: S/Key Password?
No, it is not Kerberos Related, it is a separate authentication scheme. Colin Legendre CCNP, MCP [EMAIL PROTECTED] http://www.ns3g.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of William Michael Grim Sent: Tuesday, March 26, 2002 12:44 AM To: 'Yann Ramin' Cc: [EMAIL PROTECTED] Subject: RE: S/Key Password? Yes, man skey really helped me out. I now think I understand the possible usefulness of it. Do you happen to know if that thing is Kerberos related? Thanks, Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Yann Ramin Sent: Monday, March 25, 2002 11:34 PM To: William Michael Grim Cc: [EMAIL PROTECTED] Subject: Re: S/Key Password? S/Key is a one-time password scheme. Do a 'man skey' for more info. I'm not sure why its been default enabled in pam.conf, but I'm the wrong person to talk to for that :) Yann William Michael Grim wrote: Hi, I just upgraded to FreeBSD 4.5 and figured out how to finally get rid of S/Key Passwd: when I try to login through ssh. But what the hell was that? I don't know that password or anything. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: xdm problem after making world..
Bob Vaughan wrote:
A couple days ago, I did an upgrade from a -stable build of earlier this
month, and since then I have not been able to get xdm to work at all.
When xdm is started, I get a quick flash of a background screen, and then
it goes blank. this repeats until xdm is killed.
when starting, xdm chown's the console, which was breaking on one of my
machines, where the user name contains a period ('.'). chown still
thinks the dot is the separator between the user name and the group
name.
My cure was to rebuild chown from the src tree (in src/usr.sbin/chown/),
with the option CFLAGS+=-DSUPPORT_DOT commented out of the Makefile
HTH
TfH
PS : FreeBSD supports dots in user names since 3.0 - chown still does
not !!!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: xdm problem after making world..
Date: Wed, 27 Mar 2002 07:34:24 +0100
From: Thierry Herbelot [EMAIL PROTECTED]
To: Bob Vaughan [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: xdm problem after making world..
Bob Vaughan wrote:
A couple days ago, I did an upgrade from a -stable build of earlier this
month, and since then I have not been able to get xdm to work at all.
When xdm is started, I get a quick flash of a background screen, and then
it goes blank. this repeats until xdm is killed.
when starting, xdm chown's the console, which was breaking on one of my
machines, where the user name contains a period ('.'). chown still
thinks the dot is the separator between the user name and the group
name.
My cure was to rebuild chown from the src tree (in src/usr.sbin/chown/),
with the option CFLAGS+=-DSUPPORT_DOT commented out of the Makefile
HTH
TfH
PS : FreeBSD supports dots in user names since 3.0 - chown still does
not !!!
This dosen't explain why it suddenly broke.. (3.0 is quite old by now :-)
This was an upgrade from a 4.5-stable of around 3/6/02 or so..
This is also a one user machine.. no dots in userids..
-- Welcome My Son, Welcome To The Machine --
Bob Vaughan | techie@{w6yx|tantivy}.stanford.edu | [EMAIL PROTECTED]
| P.O. Box 19792, Stanford, Ca 94309
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Helge Oldach([EMAIL PROTECTED])@2002.03.26 23:26:57 +: [...] standard, well- and widely-known piece of software around. You may not like it but both S*** and B*** are the de facto standards. Period. they are not, but this is not the issue. it is just convenient to have emacs in the base system, it's a de facto standard, it's widely known and i guess it's much more widespread than the use of sendmail. but, again, this is not the issue here. why not have apache in the base dist? (to quote one part of the original again). You have all hooks to throw them away and substitute them with something different, so please don't bother the world if they don't grok your personal taste. this isn't about my personal taste, this is about philosophy, just as i stated in the other pragraph you generously deleted. thank you. Not another sendmail-versus-whatever discussion please... Please! this isn't it neither. re-read the original mail and think about it again. P.S. Get rid of vi; cat should be enough for everyone! do you really expect me to comment on this? btw, guessing from the domain part of you mail address, you should actually be interested in straightforwardness and stability of implementations in the field your company operates in, shouldn't you? btw2, it's very hard to make a point if the first sentence of an email ends with period., even harder if you fail to make a point in your whole argumentation. btw3, if you didn't still did not understand what i meant in the original mail (i know, i'm not a native english speaker, so are you, so the chosen language might not be as efficient due to my deficiencies), please think about it _again_. it is about simplicity of implementation. straighforwardness. ease of administration. this in context to what i see as the basic paradigms in bsd's design. and this all in relation to how-it-is-done in -RELEASE. i don't want to change somebody's lifestyle. i don't want to change the release engineer's way of thinking. i want the people involved to think about the questions i posed in the original mail and i _know_ that this is a good idea. with people like you, guarding the borders of their sandlot, of course, there's not as much probability to come to a point of _discussion_, because you appear to _insist_ on the correctness of your view of the world. fwiw, let me tell you one thing my friend: when the catholic church around 1490 AD taught a picture of a world being flat as a dish, columbus was apparently the only one idealistic enough to prove them wrong. this was not the result of saying we did this since 1300, why should we think different now?. you get my point. have a nice day, /k -- Coders do it with a routine. KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ Please do not remove my address from To: and Cc: fields in mailing lists. 10x msg43137/pgp0.pgp Description: PGP signature
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Karsten W. Rohrbach: the question is: why the hell are complex (or rather complicated) subsystems that often stay unused still in the base distribution? it is simply not consequent, not following the main paradigm of bsd's design, to have subsystems like sendmail or bind in the base dist, Because they don't ...stay unused. It's just convenient to have a standard, well- and widely-known piece of software around. You may not like it but both Sendmail and BIND are the de facto standards. Period. You have all hooks to throw them away and substitute them with something different, so please don't bother the world if they don't grok your personal taste. Not another sendmail-versus-whatever discussion please... Please! Helge P.S. Get rid of vi; cat should be enough for everyone! When did it become a sendmail-versus-whatever discussion? The question is simply this: why are there large, complex, non-BSD packages in src-contrib that are not critical to the running of many types of systems, and not strictly a dependency of the system proper? (Before you jump and say that some local mail delivery tool should be system-mandatory, note that the original suggestion was that if there is to be a default mail tool, it should be some very simple binmail style thing, not a whole full blown sendmail implementation.) I don't buy the argument that the software is there so that you can use it when you finally find a need for it. That could be said about much of the generally useful software that has found a home in the ports collection. Nor does the fact that sendmail and bind are de facto standards mean they should be afforded any different treatment than the many other de facto services that live in the ports tree. I'd guess that there are a similar number of BSD machines running apache as there are running sendmail, and probably substantially more than are running BIND -- but you don't find that piece of de facto web serving software in src-contrib, do you? The suggestion that moving sendmail or bind into the ports tree is tantamount to doing the same to vi is interesting, but I see a major difference between the two: I can hardly contrive an example where vi wouldn't be useful to have, whereas I have actually encountered many cases in my work where a DNS server and an MTA are both unwanted and even needed to be removed due to constraints unrelated to name resolution or mail transport. And, as Helge prematurely pointed out, there are perfectly functional alternatives to both of those packages, too. It seems analagous to opt-in (ports) versus opt-out (src) for software, except that the opt-out procedure is more involved (alter make.conf, buildworld) than the opt-in procedure (install the port), and is more difficult to manage (especially if you want to manage the software independent of the rest of the OS.) Given those characteristics, why would one prefer the opt-out method? Actually, when you start to think along those lines, it starts to take a Microsoft-esque bundled software favoritism shape, which might be why the sendmail-versus-whatever flag was raised prematurely. But I'm assuming that there are actual good reasons for this software being in the main tree, not simply for the advocacy of some particular software, as that seems pointless. (Also because the idea gives me the creeps.) My best guess for why they remain there is the momentum generated by their very presence -- if many or most people use that software, and moving it out would break their setups, it's not likely to change any time soon, eh? I've noticed that there are, in fact, sendmail and bind ports -- does anybody use them? if so, why, and do they interact poorly with their src-contrib counterparts? If not, why are they there? Is there some political struggle afoot to cleave these packages from the BSD sources proper? Are these old, deprecated ports? In fact, it seems like about 50% of the packages in src-contrib can also be found in the ports collection. That's pretty confusing, actually. Apparently, I have the bzip2 package installed for no reason, as it's part of stable. Pulled in as a logical dependency of tar's -y option, maybe? Are there plans to eventually deprecate the duplicated ports, or the packages in src-contrib, or neither? Is there any sort of rough policy on how to decide where to put a piece of non-BSD software? Anyway, I just wanted to say that some of Karsten's comments resonated with my own experiences, and while perhaps a little harshly worded, I think the questions deserve some thought. /Yeasah To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: newsyslog.conf - sudden error
Crist J. Clark (cjc) writes: On Tue, Mar 26, 2002 at 10:26:56AM +0100, Michael Hostbaek wrote: Well, the one box that do work (4.4-STABLE) is located in the UK (hence another timezone -1) - whereas the other boxes are located in Italy and France. Could that be the problem ? Looking for a reason mktime(3) may have failed. That's the only reason you would get that error other than the syntax being no good. Hmmm.. well - I changed the syntax to '@T00' - and now it gives no problems ! Thanks for the help. -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: sendmail 8.12.2 MFC'ed
Karsten W. Rohrbach: Helge Oldach([EMAIL PROTECTED])@2002.03.26 23:26:57 +: [...] standard, well- and widely-known piece of software around. You may not like it but both S*** and B*** are the de facto standards. Period. Please quote correctly and don't falsify my words here. I am not willing to discuss with you showing this unacceptable attitude. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
