alpha cross-compiler hosed
Hi!
Some background first.
I am currently working on cleaning up the false dependencies
issue for secure/. The attached patch p1 fixes this. This is
done by moving the false dependencies from secure/ utilities
directly to libssh.so. This also requires a alight re-ordering
in `libraries' target of Makefile.inc1, which is done by the
attached patch p2.
So far it's OK. Now the problem. I was testing these patches
on an i386 -CURRENT box that does nightly make worlds for
both i386 and alpha. i386 world built OK, alpha cross-world
broke trying to link secure/libexec/sftp-server as follows:
: Script started on Fri Jan 25 10:09:41 2002
: --
: Building everything..
: --
: cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/alpha MACHINE_ARCH=alpha MACHINE=alpha
:COMPILER_PATH=/usr/obj/alpha/usr/src/i386/usr/libexec:/usr/obj/alpha/usr/src/i386/usr/bin
:
:LIBRARY_PATH=/usr/obj/alpha/usr/src/i386/usr/lib:/usr/obj/alpha/usr/src/i386/usr/lib
:OBJFORMAT_PATH=/usr/obj/alpha/usr/src/i386/usr/libexec CINCLUDES=-nostdinc
:CXXINCLUDES=-nostdinc++
:PERL5LIB=/usr/obj/alpha/usr/src/i386/usr/libdata/perl/5.6.0
:GROFF_BIN_PATH=/usr/obj/alpha/usr/src/i386/usr/bin
:GROFF_FONT_PATH=/usr/obj/alpha/usr/src/i386/usr/share/groff_font
:GROFF_TMAC_PATH=/usr/obj/alpha/usr/src/i386/usr/share/tmac
:DESTDIR=/usr/obj/alpha/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh
:PATH=/usr/obj/alpha/usr/src/i386/usr/sbin:/usr/obj/alpha/usr/src/i386/usr/bin:/usr/obj/alpha/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
: make -f Makefile.inc1 all
: === secure/libexec/sftp-server
: cc -O -pipe -nostdinc -mcpu=ev4 -DNO_IDEA
:-I/usr/obj/alpha/usr/src/i386/usr/include -o sftp-server sftp-server.o
:sftp-common.o -lssh -lcrypto
: /usr/obj/alpha/usr/src/i386/usr/libexec/elf/ld: warning: libz.so.2, needed by
:/usr/obj/alpha/usr/src/i386/usr/lib/libssh.so, not found (try using -rpath or
:-rpath-link)
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `deflate'
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `inflate'
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `inflateInit_'
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `deflateInit_'
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `inflateEnd'
: /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so: undefined reference to `deflateEnd'
: *** Error code 1
:
: Stop in /usr/src/secure/libexec/sftp-server.
: *** Error code 1
:
: Script done on Fri Jan 25 10:09:42 2002
The ld(1) error message above says (formatted by fmt(1)):
: /usr/obj/alpha/usr/src/i386/usr/libexec/elf/ld: warning: libz.so.2,
: needed by /usr/obj/alpha/usr/src/i386/usr/lib/libssh.so, not found
: (try using -rpath or -rpath-link)
But the library _is_ there, and it was built even earlier than libssh:
: # cd /usr/obj/alpha/usr/src/i386/usr/lib
: # ls -l libssh.so* libz.so*
: lrwxr-xr-x 1 root wheel 11 Jan 25 06:19 libssh.so - libssh.so.2
: -rwxr-xr-x 1 root wheel 295859 Jan 25 06:19 libssh.so.2
: lrwxr-xr-x 1 root wheel 9 Jan 25 06:34 libz.so - libz.so.2
: -rwxr-xr-x 1 root wheel 80017 Jan 25 06:11 libz.so.2
Now about the bug. Here's the interesting output from both i386 and
alpha versions of cross-compiler built tonight:
: # /usr/obj/usr/src/i386/usr/bin/gcc -print-search-dirs
: install: /usr/obj/usr/src/i386/usr/libexec/(null)
: programs: /usr/obj/usr/src/i386/usr/libexec/elf/:/usr/obj/usr/src/i386/usr/libexec/
: libraries: /usr/obj/usr/src/i386/usr/libexec/:/usr/obj/usr/src/i386/usr/lib/
: # /usr/obj/alpha/usr/src/i386/usr/bin/gcc -print-search-dirs
: install: /usr/obj/alpha/usr/src/i386/usr/libexec/(null)
: programs: /usr/obj/alpha/usr/src/i386/usr/libexec/elf/
: libraries:
Note the empty libraries: for the alpha version. I think this
is the bug.
I will see if I can fix this bug myself, but I thought David could
fix it quicker than me. :-)
Cheers,
--
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
Index: secure/lib/libssh/Makefile
===
RCS file: /home/ncvs/src/secure/lib/libssh/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- secure/lib/libssh/Makefile 2002/01/23 15:54:09 1.12
+++ secure/lib/libssh/Makefile 2002/01/25 08:16:18
@@ -24,6 +24,9 @@
CFLAGS+= -DKRB5
.endif # MAKE_KERBEROS5
+DPADD= ${LIBCRYPTO} ${LIBZ}
+LDADD= -lcrypto -lz
+
.include bsd.lib.mk
.PATH: ${SSHDIR} ${SSHDIR}/lib
Index: secure/libexec/sftp-server/Makefile
===
RCS file:
No buffer space available
Is anyone still seeing the No buffer space availabe message in 5.0-CURRENT? I have checked the mail archieve and saw several replies, but none worked in my case. I have a Thinkpad 600X with a Melco cardbus 10/100 ethernet card (a Realtek 8139B) running 5.0 NEWCARD kernel with NMBCLUSTERS=16384. No buffer space available occurred when I tried to ftp a file in my Thinkpad from other client. ifconfig rl0 down and then ifconfig rl0 up resumed the operation for awhile until the error happened again. Setting media to 10baseT/UTP did not suffer from this error and got about 900Kbytes/s throughput. Would that be a bug in the driver that ftp server is delivering too much traffic to the NIC? Any suggestion that I can try? Thanks __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GDB maintainer?
On Sun, 20 Jan 2002 17:18:30 PST, k Macy wrote: Who is the current GDB maintainer? Not sure there's a single maintainer, but I know these two gentlemen take a keen interest in the beast: Bruce Evans [EMAIL PROTECTED] Brian Dean [EMAIL PROTECTED] Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No buffer space available
Shizuka Kudo wrote: Is anyone still seeing the No buffer space availabe message in 5.0-CURRENT? I have checked the mail archieve and saw several replies, but none worked in my case. I have a Thinkpad 600X with a Melco cardbus 10/100 ethernet card (a Realtek 8139B) running 5.0 NEWCARD kernel with NMBCLUSTERS=16384. No buffer space available occurred when I tried to ftp a file in my Thinkpad from other client. ifconfig rl0 down and then ifconfig rl0 up resumed the operation for awhile until the error happened again. Setting media to 10baseT/UTP did not suffer from this error and got about 900Kbytes/s throughput. Would that be a bug in the driver that ftp server is delivering too much traffic to the NIC? Any suggestion that I can try? That downing and reupping it worked indicates that you are losing a transmit interrupt draining the write queue. I'm pretty sure that this has to be related to the use of interrupt threads in -current, as I do not have the problem with the 8139B's I have, with an older, stable version of FreeBSD. The downing and reupping it resets the card (this is an intentional side effect, designed to make Tigon II cards suck^W^W^W^W^Wallow recovery from a hosed driver that people would rather hack around than fix^W^W^W^W^W^W^W^W, which should never happen in practice). The normal workaround for this is to have a software watchdog timer that resets the card when it loses its mind like this (transmit interrupt pending, no transmit interrupt seen for timeout period). You could add similar code the the RealTek driver pretty easily, using the Tigon II or another driver as a template, if you wanted to work around the problem instead of actually fixing it^W^W^W^W^W. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems with Apache1.3.22+php4
Hi, since around mid of december I have problems to get an apache with mod_ssl and php4 running on -current. With php4 loaded, apache is in a fcntl loop after executing an primitive cgi-script. The output of a simple printenv cgi is printed to the screen (netscape or telnet on 80) and then the connection don't get closed, it hangs around for 15 minutes finally reaching the timeout. There are no surch problems on our -stable machines, but three -current boxes are all doing the same. On my workstation, current is from today, apache is 1.3.23+modssl for the 1.3.22 (no difference in the behavior here). The mod_php is 4.1.1 Is anyone seeing something like this too, or it's only me ? Have I missed something ? I can provide more informaion if you wish, TIA, Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher Partnerfax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
snd_maestro3 on Current laptop begining on Wednesday morning.
My laptop sound seems to have quit working after some changes that were submitted, between my Tuesday morning +-4:30 am PST and wednesday 4:30 am PST. I assumed that I had not cvsuped all the changes but today's build still doesn't work. The module loads but no sound. /root # cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: ESS Technology Allegro-1 at io 0x1800 irq 5 (4p/1r/0v channels duplex default) and pciconf shows: pcm0@pci0:10:0: class=0x040100 card=0x002e0e11 chip=0x1988125d rev=0x12 hdr=0x00 vendor = 'ESS Technology' device = 'ES1989 Allegro-1 Audiodrive' class= multimedia subclass = audio if I try a cat file.au/dev/audioX.X, I get a cannot create /dev/audioX.X I really looks like it should work but it doesn't. I can boot with Tuesdays kernel and it works fine. Is anyone else seeing this? Thanks, ed --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
Processes hanging in ``inode' state
Recent -current on my system at work exhibits processes getting stuck in the ``inode'' state, causing the system to become unusable and requiring a reboot. I have been seeing this for about a week now; anyone else? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in ufs_dirbad()
On Thu, Jan 24, 2002 at 02:53:32PM -0800, Alfred Perlstein wrote:
* Maxim Sobolev [EMAIL PROTECTED] [020124 13:44] wrote:
Any ideas? This is a reasonably recent 5-CURRENT (last
makeworld/makekernel 7 days ago).
This may be fallout from my initial fdlocking work, please try
an update or get a debug traceback and we'll see.
I have actually seen this panic very recently on -STABLE. Matt
Dillon suspected an issue with the RAID controller I was using
(aac) after some debugging work.
I am still waiting on the results of diagnostic testing on the
RAID controller, but I just wanted to offer an additional data
point.
I have attached dmesg and some of the results of our debugging
session below. The panic occurred during heavy file create/delete
activity. I referred to PR kern/13150, which may or may not be
related.
We determined that *ep in ufs_lookup contained garbage (from a file
name). ep-d_name contained file data.
Doug Swarin
[EMAIL PROTECTED]
(kgdb) back
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:473
#1 0xc01705df in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:313
#2 0xc0170a01 in panic (fmt=0xc0276207 ufs_dirbad: bad dir)
at /usr/src/sys/kern/kern_shutdown.c:581
#3 0xc01e8ef6 in ufs_dirbad (ip=0xc8154200, offset=31,
how=0xc02761b0 mangled entry) at /usr/src/sys/ufs/ufs/ufs_lookup.c:641
#4 0xc01e8714 in ufs_lookup (ap=0xef25ad14)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:291
#5 0xc01ed715 in ufs_vnoperate (ap=0xef25ad14)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2423
#6 0xc019a04a in vfs_cache_lookup (ap=0xef25ad6c) at vnode_if.h:77
#7 0xc01ed715 in ufs_vnoperate (ap=0xef25ad6c)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2423
#8 0xc019cfb9 in lookup (ndp=0xef25aec4) at vnode_if.h:52
#9 0xc019cab4 in namei (ndp=0xef25aec4)
at /usr/src/sys/kern/vfs_lookup.c:153
#10 0xc01a580a in vn_open (ndp=0xef25aec4, fmode=514, cmode=420)
at /usr/src/sys/kern/vfs_vnops.c:99
#11 0xc01a1a8c in open (p=0xef1b8560, uap=0xef25af80)
at /usr/src/sys/kern/vfs_syscalls.c:999
#12 0xc023ebbd in syscall2 (frame={tf_fs = -1078001617, tf_es = 47,
tf_ds = -1078001617, tf_edi = 513, tf_esi = 134645918,
tf_ebp = -1077945588, tf_isp = -282742828, tf_ebx = -1077946616,
tf_edx = 68, tf_ecx = -1077946780, tf_eax = 5, tf_trapno = 0,
tf_err = 2, tf_eip = 672953588, tf_cs = 31, tf_eflags = 663,
tf_esp = -1077946656, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1157
#13 0xc022b8eb in Xint0x80_syscall ()
(kgdb) frame 4
(kgdb) print ep-d_reclen
$4 = 0x6f63
(kgdb) print entryoffsetinblock
$5 = 0x1f
(kgdb) print dirchk
$6 = 0x0
(kgdb) print *ep
$7 = {
d_ino = 0x2e797567,
d_reclen = 0x6f63,
d_type = 0x6d,
d_namlen = 0x3e,
d_name = '\000' repeats 41 times, Assorted -...
}
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.5-RC #0: Wed Jan 16 11:37:55 CST 2002
root@localhost:/usr/obj/usr/src/sys/NEWS2450
Timecounter i8254 frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (993.33-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x686 Stepping = 6
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory = 2147475456 (2097144K bytes)
config q
avail memory = 2088914944 (2039956K bytes)
Changing APIC ID for IO APIC #0 from 2 to 0 in MP table
Changing APIC ID for IO APIC #1 from 0 to 3 on chip
Programming 16 pins in IOAPIC #0
Programming 16 pins in IOAPIC #1
FreeBSD/SMP: Multiprocessor motherboard
cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0
io0 (APIC): apic id: 0, version: 0x000f0011, at 0xfec0
io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000
Preloaded elf kernel kernel at 0xc032b000.
Preloaded userconfig_script /boot/kernel.conf at 0xc032b09c.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 7 entries at 0xc00fc2c0
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pci0: ATI model 4759 graphics accelerator at 14.0
isab0: ServerWorks IB6566 PCI to ISA bridge at device 15.0 on pci0
isa0: ISA bus on isab0
atapci0: ServerWorks ROSB4 ATA33 controller port 0x8b0-0x8bf at device 15.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: OHCI USB controller at 15.2 irq 11
pcib1: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard
IOAPIC #1 intpin 15 - irq 2
IOAPIC #1 intpin 0 - irq 5
pci1: PCI bus on pcib1
pcib2: PCI to PCI bridge (vendor=8086 device=0962) at device 2.0 on pci1
IOAPIC #1 intpin 14 - irq 10
pci2: PCI bus on pcib2
pci2: unknown card (vendor=0x9005, dev=0x00c5) at 4.0 irq 2
ahc0: Adaptec aic7899 Ultra160 SCSI adapter port 0xd800-0xd8ff mem
0xf7ffe000-0xf7ffefff irq 10 at device 4.1 on pci2
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255
Re: Panic in ufs_dirbad()
On Fri, 25 Jan 2002, Doug Swarin wrote: I have actually seen this panic very recently on -STABLE. Matt Dillon suspected an issue with the RAID controller I was using (aac) after some debugging work. I am still waiting on the results of diagnostic testing on the RAID controller, but I just wanted to offer an additional data point. I have attached dmesg and some of the results of our debugging session below. The panic occurred during heavy file create/delete activity. I referred to PR kern/13150, which may or may not be related. We determined that *ep in ufs_lookup contained garbage (from a file name). ep-d_name contained file data. Alternatively, if it's only recent -STABLE, maybe it's something to do with the recent enabling of UFS_DIRHASH in -STABLE by default? If so, this might require immediate action before 4.5-RELEASE goes out the door (very, very soon). Has anyone managed to track it down anymore? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic in ufs_dirbad()
On Fri, Jan 25, 2002 at 07:48:09PM -0500, Robert Watson wrote: On Fri, 25 Jan 2002, Doug Swarin wrote: I have actually seen this panic very recently on -STABLE. Matt Dillon suspected an issue with the RAID controller I was using (aac) after some debugging work. I am still waiting on the results of diagnostic testing on the RAID controller, but I just wanted to offer an additional data point. I have attached dmesg and some of the results of our debugging session below. The panic occurred during heavy file create/delete activity. I referred to PR kern/13150, which may or may not be related. We determined that *ep in ufs_lookup contained garbage (from a file name). ep-d_name contained file data. Alternatively, if it's only recent -STABLE, maybe it's something to do with the recent enabling of UFS_DIRHASH in -STABLE by default? If so, this might require immediate action before 4.5-RELEASE goes out the door (very, very soon). Has anyone managed to track it down anymore? I do not have UFS_DIRHASH enabled in my kernel. -- Doug Swarin, Programmer doug (at) texas dot net To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic in bioqdisksort()
I got another panic with yesterday's kernel.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0xc9256040
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01ccf1b
stack pointer = 0x10:0xf12bb828
frame pointer = 0x10:0xf12bb834
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 = 458 (fsck_ufs)
kernel: type 12 trap, code=0
Stopped at bioqdisksort+0x2b: movl0xc0(%ebx),%eax
db trace
bioqdisksort(c8eab4a8,c9255f80,c8eaa000,f12bb880,c014e3ce) at bioqdisksort+0x2b
adstrategy(c9255f80) at adstrategy+0x39
arstrategy(d5472908,d5472908,ec3638c0,f12bb8ac,c01a0093) at arstrategy+0x2de
diskstrategy(d5472908,c8eb3000,d5472908,c901f000,f12bb8b8) at diskstrategy+0xa1
spec_strategy(f12bb8d0,f12bb8dc,c02911cd,f12bb8d0,d5472908) at spec_strategy+0x19b
spec_vnoperate(f12bb8d0,d5472908,c901f000,200a4,c0334ce0) at spec_vnoperate+0x15
ufs_strategy(f12bb900,f12bb90c,c01ed1d7,f12bb900,800) at ufs_strategy+0xa9
ufs_vnoperate(f12bb900) at ufs_vnoperate+0x15
bwrite(d5472908,f12bb950,c027f195,d5472908,c901f000) at bwrite+0x25f
bawrite(d5472908,c901f000,c9020f00,f13eed00,2) at bawrite+0x16
cgaccount(12,f13eed00,d55b2d78,1,c901f000) at cgaccount+0x26d
ffs_snapshot(c9014400,80b20e0,0,c9014400,0) at ffs_snapshot+0x939
ffs_mount(c9014400,c9138380,bfbffcb4,f12bbc18,f11a8104) at ffs_mount+0x458
vfs_mount(f11a8104,c902bd40,c9138380,1211100,bfbffcb4) at vfs_mount+0x622
mount(f11a8104,f12bbd20,80b66a6,80b6600,bfbffdc8) at mount+0x6a
syscall(2f,2f,2f,bfbffdc8,80b6600) at syscall+0x25f
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
(kgdb) up 11
#11 0xc01ccf1b in bioqdisksort (bioq=0xc8eab4a8, bp=0xc9255f80)
at ../../../kern/subr_disklabel.c:91
91 TAILQ_FOREACH(bn, bioq-queue, bio_queue)
(kgdb) list
86 struct bio *bn;
87 struct bio *be;
88 struct thread *td = curthread;
89
90 if (td td-td_ksegrp-kg_nice 0) {
91 TAILQ_FOREACH(bn, bioq-queue, bio_queue)
92 if (BIOTOBUF(bp)-b_vp !=
BIOTOBUF(bn)-b_vp)
93 break;
94 if (bn != NULL) {
95 mtx_lock(dksort_mtx);
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
make release failed
I'm running virgin 4-5.RC #0 from cvsup at today midnight. make relase fails: install-info ... binutils.info $CHROOTDIR/usr/share/info/dir *** Error code 1 Yep, for this moment i yet have in my $CHROOTDIR/usr/share/info a plain file dir. Is it ok ??? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
