Re: usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.cpp:15:10: fatal error: 'llvm/TableGen/Error.h' file not found, #include llvm/TableGen/Error.h
On 05/24/12 21:29, Dimitry Andric wrote:
On 2012-05-24 18:53, O. Hartmann wrote:
Trying to build buildworld on FreeBSD 10-CURRENT/amd64 with CLANG today
ends up in the following error:
=== lib/clang/libllvmtablegen (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmtablegen created for
/usr/src/lib/clang/libllvmtablegen
rm -f .depend
CC='clang' mkdep -f .depend -a
-I/usr/obj/usr/src/tmp/legacy/usr/include
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenAction.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenBackend.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGLexer.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGParser.cpp
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.cpp:15:10:
fatal error: 'llvm/TableGen/Error.h' file not found
#include llvm/TableGen/Error.h
Something is going wrong with your include paths; most likely your
CFLAGS gets mangled. The actual mkdep command line should have been
similar to (wrapped for clarity):
CC='clang' \
mkdep \
-f .depend \
-a \
-I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include \
-I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include
\
-I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen \
-I. \
-I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include
\
-DLLVM_ON_UNIX \
-DLLVM_ON_FREEBSD \
-D__STDC_LIMIT_MACROS \
-D__STDC_CONSTANT_MACROS \
-DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd10.0\ \
-DDEFAULT_SYSROOT=\\ \
-I/usr/obj/usr/src/tmp/legacy/usr/include \
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenAction.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TableGenBackend.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGLexer.cpp
\
/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGParser.cpp
Are you appending or assigning to CFLAGS in make.conf/src.conf?
Yes,
I do. This very moment, I got rid of those messages. I think it is not
very clear to me (and maybe others) anymore, what goes into
/etc/src.conf and what is to be remaining in /etc/make.conf.
Since I wrecked all my FreeBSD 10-0-CURRENT boxes around the 15th of May
by simply building a world (on a daily baisis, so they got affected
all), but was luckily able to repair, I guess I need to figure out
what's really necessary to go in /etc/src.conf and in /etc/make.conf.
There are some mails in this list claiming that setting CC=, CXX= and
CPP= needs also to be done in /etc/src.conf. I have those already set in
/etc/make.conf using a knob for checking to build with CLANG or not.
Well, am I right that first /etc/make.conf gets read and then
/etc/src.conf? By mistake I set CFLAGS= instead of CFLAGS+= in
/etc/src.conf, so all settings performed prior to the sucking in of
/etc/src.conf got banned from the options - and ended up in not finding
even includes anymore (due to missing -Ifoo/bar options). Very tricky
and a large pithole to step into if not carefully thought about.
Regards,
Oliver
P.S. Most of the confusion is due to the fact I want the base OS be
built by CLANG as well as all ports which can bear being built by CLANG.
But there are those which can't yet and somehow I try to sort them out
and build them with prefereably the gcc46 or gcc47 (I use the base
systems USE_GCC=4.6+ option).
For this purpose, I include at the end of /etc/make.conf a file named
ports.conf like this:
.include /usr/local/etc/ports.conf
The content of ports.conf is like:
[...]
# mail/thunderbird
.if ${.CURDIR:M/usr/ports/mail/thunderbird}
USE_GCC=4.6+
#CC=cc
#CXX= c++
#CPP= cpp
CFLAGS+=-DLDAP_DEPRECATED
CXXFLAGS+= -DLDAP_DEPRECATED
.endif
[...]
This approach does only work, if the not well documented knob
WITH_CLANG_IS_CC is not set, so cc stays with the legacy gcc 4.2.1.
By the way, I would like to see a much more restrictive way to separate
the FreeBSD core system from ports in a logical way. Either I have a
great misunderstanding and this is already the fact, or ...
signature.asc
Description: OpenPGP
KDE 3.5.10 10-CURRENT r235646 (May 19)
Hello, The Good message first: KDE 3.5.10 compiles clean in 10-CURRENT; thanks! With a recent 10-CURRENT and clean ports from CVS (both from May 19) I encounter some crashes on KDE start or stop; there are messages from 'startkde': Warning: kbuildsycoca is unable to register with DCOP. kbuildsycoca running... kbuildsycoca running... Reusing existing ksycoca ... startkde: Starting up... kbuildsycoca running... running as realtime process now (priority 15) kdecore (KProcess): WARNING: Can't open a pseudo teletype QSocketNotifier: Invalid socket specified QSocketNotifier: Socket descriptor too large for select() QSocketNotifier: Internal error kbuildsycoca running... Reusing existing ksycoca and on KDE exit it says: Segmentation fault (core dumped) startkde: Shutting down... startkde: Running shutdown scripts... startkde: Done. and a file dcop.core is written; What does this mean? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SMP/i386 suspend/resume
Hi, +1. I've really liked to use more than one CPU on my netbook for a while :). A basic suspend test worked on my netbook. I'll have to see about some edgecases I've run into in the past where UP wouldn't resume if the system had been sitting for an extensive period of time, etc. Very cool though -- thanks for your work so far on this ;)! I'm glad to hear this :) I'll try to fix suspend/resume related problems when I have spare time. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFT][CFR] Resurrect handling of VersionAddendum in OpenSSH
Good day.
I had created patches for OpenSSH to resurrect handling of
VersionAddendum and, additionally, enable/disable advertisements
for HPN feature in sshd version banner. des@, bz@ and brooks@
are aware of this patch, Bjoern even reviewed the first version
of the patch, but the second one isn't yet reviewed.
Can anyone who uses SSH test this patch and report their findings
to the respective PR. Also, code reviews are welcome too.
Thanks!
PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=163843
Patches:
* 8-STABLE,
http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling-8-STABLE.diff
* 9-STABLE,
http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling-9-STABLE.diff
* 10-CURRENT,
http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling.diff
Instructions:
{{{
cd /usr/src
fetch -o ssh-addendum.diff
http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling.diff
patch -p1 ssh-addendum.diff
cd secure/lib/libssh
make make install
cd ../../usr.sbin/sshd
make make install service sshd restart
cd ../..//usr.bin/ssh
make make install
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpSRvvgrwBwo.pgp
Description: PGP signature
Re: WARNING - DO NOT test: IPv6 offload support in HEAD + patch for stable/9
On 25. May 2012, at 16:55 , Bjoern A. Zeeb wrote: Hey, last night I pushed in the essential offloading support changes for IPv6 along with quite a bit of other noise into HEAD. There is more locking improvements etc. to come once I have looped things back to my working tree and Michael Tuexen will improve SCTP/v6 on loopback as well soonish. This is a call for testing. The in-tree cxgb(4) and ixgbe(4) drivers WARNING - please refrain from testing IPv6 or updating your HEAD if you do not have any of the above two NICs and rely on IPv6, or if you have updated and are experiencing problems. Disabling -txcsum -tso for the moment should be an often unhelpful workaround. It seems I was just lucky with my choice of other NICs I tested but I cannot say which once are affected in the tree and which once aren't. Andrew Gallatin has pointed out that I missed an essential IPv4 header parsing thing beyond TSO in some (most?) NIC drivers and it went unnoticed in review. I'll post an update in a few hours once I know how many drivers are affected, or have the proper fix as it might also be a question in which (old/cheap) silicon might not do what is expected. have been updated to make use of the new features (TSO6/LRO6), and more drivers will follow (I already have cxgbe done, talking about mxge, ..) but others should also see improvements for at least upper layer protocol checksum calculations and I'd love people to test with as many drivers as possible, as I plan to merge it for the upcoming 9.1-RELEASE cycle and wouldn't want to ship broken IPv6 in a few months;-) Here's the patch that should just apply to stable/9 matching what I put into HEAD (+ an earlier cxgb change) (untested): http://people.freebsd.org/~bz/20120525-01-ipv6-offload-mfc9.diff If you need a patch for a specific release please drop me a private email and I'll try to publish one (8.2 and up only though most likely). Please test and report to me or net@. Thanks /bz PS: we now also disallow LRO automatically if forwarding is turned on, just in case you wonder; a change that should have been done years ago;-) -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
10-CURRENT r235646 open-vm-tools-8.6.0-425873
Hi, The port ports/emulators/open-vm-tools does not compile in 10-CURRENT: # make install clean ... make VM_UNAME=10.0-CURRENT MV=mv RM=rm OVT_SOURCE_DIR=/usr/ports/emulators/open-vm-tools/work/open-vm-tools-8.6.0-425873 MODULEBUILDDIR=/usr/ports/emulators/open-vm-tools/work/open-vm-tools-8.6.0-425873/modules/freebsd -C /usr/ports/emulators/open-vm-tools/work/open-vm-tools-8.6.0-425873/modules/freebsd/vmxnet @ - /usr/src/sys machine - /usr/src/sys/i386/include x86 - /usr/src/sys/x86/include : opt_bdg.h awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/u sr/ports/emulators/open-vm-tools/work/open-vm-tools-8.6.0-425873/lib/include -I/usr/ports/emulators/open-vm-tools/work/open-vm-tools-8.6.0-425873/modules/shared/vmxnet -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mp referred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack- protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-e xterns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast -qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fd iagnostics-show-option -c if_vxn.c cc1: warnings being treated as errors if_vxn.c: In function 'vxn_load_multicast': if_vxn.c:719: warning: implicit declaration of function 'IF_ADDR_LOCK' if_vxn.c:719: warning: nested extern declaration of 'IF_ADDR_LOCK' [-Wnested-ext erns] if_vxn.c:746: warning: implicit declaration of function 'IF_ADDR_UNLOCK' if_vxn.c:746: warning: nested extern declaration of 'IF_ADDR_UNLOCK' [-Wnested-e xterns] *** [if_vxn.o] Error code 1 Let me know if you need more information. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
NFS panic
Hey, SVN as of a few days ago. On reboot. Do not have a core or further debugging information. The machine was running of a nfs root. May 26 17:10:06 panic: mtx_lock() of destroyed mutex @ /zoo/bz/HEAD.svn/sys/kern/uipc_socket.c:1025 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 _mtx_lock_flags() at _mtx_lock_flags+0x13f sosend_dgram() at sosend_dgram+0xbb sosend() at sosend+0x82 clnt_dg_call() at clnt_dg_call+0xb81 clnt_call_private() at clnt_call_private+0xe8 nlm4_unlock_4() at nlm4_unlock_4+0x45 nlm_clearlock() at nlm_clearlock+0x294 nlm_advlock_internal() at nlm_advlock_internal+0x64f nlm_advlock() at nlm_advlock+0x2a nfs_advlock() at nfs_advlock+0x130 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 vn_closefile() at vn_closefile+0xea _fdrop() at _fdrop+0x23 closef() at closef+0x5c fdfree() at fdfree+0x1b4 exit1() at exit1+0x319 sigexit() at sigexit+0x8f cursig() at cursig ast() at ast+0x1b9 doreti_ast() at doreti_ast+0x1f KDB: enter: panic [ thread pid 1475 tid 100121 ] Stopped at kdb_enter+0x3b: movq$0,0x864762(%rip) -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS panic
On 26. May 2012, at 17:13 , Bjoern A. Zeeb wrote: Hey, SVN as of a few days ago. On reboot. Do not have a core or further debugging information. The machine was running of a nfs root. May 26 17:10:06 panic: mtx_lock() of destroyed mutex @ /zoo/bz/HEAD.svn/sys/kern/uipc_socket.c:1025 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 _mtx_lock_flags() at _mtx_lock_flags+0x13f sosend_dgram() at sosend_dgram+0xbb sosend() at sosend+0x82 clnt_dg_call() at clnt_dg_call+0xb81 clnt_call_private() at clnt_call_private+0xe8 nlm4_unlock_4() at nlm4_unlock_4+0x45 nlm_clearlock() at nlm_clearlock+0x294 nlm_advlock_internal() at nlm_advlock_internal+0x64f nlm_advlock() at nlm_advlock+0x2a nfs_advlock() at nfs_advlock+0x130 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 vn_closefile() at vn_closefile+0xea _fdrop() at _fdrop+0x23 closef() at closef+0x5c fdfree() at fdfree+0x1b4 exit1() at exit1+0x319 sigexit() at sigexit+0x8f cursig() at cursig ast() at ast+0x1b9 doreti_ast() at doreti_ast+0x1f KDB: enter: panic [ thread pid 1475 tid 100121 ] Stopped at kdb_enter+0x3b: movq$0,0x864762(%rip) got one more at make install(kernel) reboot May 26 20:22:05 panic: mtx_lock() of destroyed mutex @ /zoo/bz/HEAD.svn/sys/kern/uipc_socket.c:1025 cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 _mtx_lock_flags() at _mtx_lock_flags+0x13f sosend_dgram() at sosend_dgram+0xbb sosend() at sosend+0x82 clnt_dg_call() at clnt_dg_call+0xb81 clnt_call_private() at clnt_call_private+0xe8 nlm4_unlock_4() at nlm4_unlock_4+0x45 nlm_clearlock() at nlm_clearlock+0x294 nlm_advlock_internal() at nlm_advlock_internal+0x64f nlm_advlock() at nlm_advlock+0x2a nfs_advlock() at nfs_advlock+0x130 VOP_ADVLOCK_APV() at VOP_ADVLOCK_APV+0xb7 vn_closefile() at vn_closefile+0xea _fdrop() at _fdrop+0x23 closef() at closef+0x5c fdfree() at fdfree+0x1b4 exit1() at exit1+0x319 sigexit() at sigexit+0x8f cursig() at cursig ast() at ast+0x1b9 doreti_ast() at doreti_ast+0x1f KDB: enter: panic [ thread pid 1154 tid 100135 ] Stopped at kdb_enter+0x3b: movq$0,0x869872(%rip) db show reg cs0x20 ds0x3b es0x3b003b fs0x1b0013 gs0x1b ss0x28 rax 0x12 rcx 0x1fc rdx 0 rbx 0x80abbedd __func__.3468+0x113 rsp 0xff860e4f08d0 rbp 0xff860e4f08f0 rsi 0x80 rdi 0xff860e4f0750 r8 0x34b7 r9 0xff860e4f0800 r10 0xfe007691b8e0 r11 0x34b6 r120x1 r13 0xfe007691b8e0 r14 0x401 r15 0x80ac9d70 __func__.7790+0x2d0 rip 0x806873eb kdb_enter+0x3b rflags0x86 kdb_enter+0x3b: movq$0,0x869872(%rip) db show alllocks Process 1345 (tcpdump) thread 0xfe000b039470 (100105) exclusive sleep mutex page lock (page lock) r = 0 (0x8109e180) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:1881 exclusive sleep mutex vm object (standard object) r = 0 (0xfe01ec4843a0) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_map.c:2724 exclusive sx user map (user map) r = 0 (0xfe005cdb6200) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_map.c:2866 Process 1296 (su) thread 0xfe00769578e0 (100132) exclusive sleep mutex page lock (page lock) r = 0 (0x8109fd00) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:728 exclusive sleep mutex vm object (standard object) r = 0 (0xfe01ec34e570) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:487 Process 1291 (sshd) thread 0xfe000b60d8e0 (100074) exclusive sleep mutex page lock (page lock) r = 0 (0x8109cc00) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:728 exclusive sleep mutex vm object (standard object) r = 0 (0xfe0076889000) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:487 Process 1203 (su) thread 0xfe0076cf6470 (100152) exclusive sleep mutex page lock (page lock) r = 0 (0x8109ee00) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:728 exclusive sleep mutex vm object (standard object) r = 0 (0xfe0076bf8488) locked @ /zoo/bz/HEAD.svn/sys/vm/vm_object.c:487 Process 1196 (sshd) thread 0xfe000b61c000 (100124) shared lockmgr newnfs (newnfs) r = 0 (0xfe0009f8ad80) locked @ /zoo/bz/HEAD.svn/sys/kern/vfs_subr.c:2159 Process 1191 (csh) thread 0xfe000b6628e0 (100081) exclusive lockmgr bufwait (bufwait) r = 0 (0xff85c9f5df58) locked @ /zoo/bz/HEAD.svn/sys/kern/vfs_bio.c:1905 shared lockmgr newnfs (newnfs) r = 0 (0xfe00b1957270) locked @ /zoo/bz/HEAD.svn/sys/kern/vfs_vnops.c:562 Process 1150 (sshd) thread 0xfe000b0388e0 (100107) shared lockmgr newnfs (newnfs) r = 0 (0xfe0009f8ad80) locked @ /zoo/bz/HEAD.svn/sys/kern/vfs_subr.c:2159 Process 1016 (rpc.lockd)
Latest PAM seems to break su
su Segmentation fault: 11 no core is produced. Currently broken: r236118 Previous r235567 sudo works. -- This .signature sanitized for your protection ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest PAM seems to break su
Doug Barton do...@freebsd.org writes: su Segmentation fault: 11 Weird, I've been running it for months... I'll look into it right away. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
WARNING: su(1) broken in head
probably due to an issue in the latest openpam; sudo is not affected DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WARNING: su(1) broken in head
Dag-Erling Smørgrav d...@des.no writes: probably due to an issue in the latest openpam; sudo is not affected should be fixed now. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
