Re: Import libyaml into base
On 2 Mar 2013 16:52, Baptiste Daroussin b...@freebsd.org wrote: I want to import libyaml into base as libbsdyml so that no ports will use it like we do for expat. I need it for the pkg bootstrap, so it it can parse pkg.conf. I know that some of the bhyve people will also be glad to use it. libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. Does anyone have an objection? I don't but please add a stub manual page telling people not to use it outside base. Simon ___ 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
r246916 probably broke amd64 build
Hey, I think r246916 broke the build. I get the following when building amd64 kernel: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/x86/isa/clock.c cc1: warnings being treated as errors /usr/src/sys/x86/isa/clock.c: In function 'set_i8254_freq': /usr/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used uninitialized in this function Could you have a look? Thanks. -- Simon L. B. Nielsen ___ 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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))
On 1 December 2012 21:06, Andreas Tobler andreast-l...@fgznet.ch wrote: On 01.12.12 16:15, Robert Watson wrote: Dear all: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit trails to a central audit server for review and safe keeping. Part of the goal is to ensure that a host submitting trail data can't later modify the trails. Pawel uses a variety of useful security- and resilience-related features such as TLS, Capsicum, etc, in auditdistd. As the recent security incident in the FreeBSD.org cluster illustrated, having reliable and detailed audit trails makes a big difference in forensic work, and hopefully this will allow the FreeBSD Project (and our users) to do that better in the future. Aehm, hope it is ok to 'complain' here. Happens when installing world. cd /export/devel/fbsd/head/src; /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1 LOCAL_MTREE= hierarchy cd /export/devel/fbsd/head/src/etc; /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p / mtree -eU -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var mtree: line 22: unknown user auditdistd *** [distrib-dirs] Error code 1 Did you remember mergemaster -p before installworld? -- Simon L. B. Nielsen ___ 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: [HEADSUP] current switched by default to pkgng
On Wed, Oct 10, 2012 at 2:44 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, If you are using the ports tree on a FreeBSD current setup, then you are concerned by the announce. As nvidia-drivers has been fixed and is now properly working with pkgng, the ports tree as been switch by default to use pkgng on FreeBSD Current based on version = 117 which was the version when we tested the switch code. Make sure to read UPDATING (from ports) to correctly migrate your system or find instruction to make your system still running with legacy pkg_install tools. I read UPDATING, but I'm still not sure what this means when I use ports and not packages. Does it mean that I should install pkg to have /var/db/pkg managed, but otherwise ports keeps working the same way, or? -- Simon L. B. Nielsen ___ 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: pkg (aka pkgng) 1.0 released
On 7 Sep 2012, at 13:02, Ivan Voras ivo...@freebsd.org wrote:
On 7 September 2012 13:54, Matthew Seaman
m.sea...@infracaninophile.co.uk wrote:
On 09/07/12 12:30, Ivan Voras wrote:
On 06/09/2012 18:44, Matthew Seaman wrote:
On 06/09/2012 16:37, Ivan Voras wrote:
Hi,
It looks like the pkg port installs pkg.conf.sample with the line:
PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest
... which is finally a good step in the direction of making pkgng
working by default, except that the pkg.freebsd.org site doesn't exist
in DNS. Instead, pkgbeta.freebsd.org still exists. I suppose one should
be a DNS CNAME for the other?
It's a SRV record:
seedling:~:% dig +short IN SRV _http._tcp.pkg.freebsd.org
10 10 80 pkgbeta.FreeBSD.org.
Hi,
What are the benefits of doing it this way?
Yeah -- it's a bit OTT right now given there's just the one publicly
available pkg repository available. It will pay off later when there
are more pkg repositories available -- repositories can be added to (or
removed from) the list in the SRV record without end-users having to
know the details.
It may also be possible to replicate what portupdate has done and use
geolocation based services to steer end users to a nearby repository
site automatically.
Ok, but all that can be done the normal way with A records.
As far as I can tell, the intended benefits of the SRV record system
is to disentangle services and hosts, so that, e.g. the same
user-visible DNS name (e.g. pkg.freebsd.org) resolves to a different
host if asked for the HTTP service and the FTP service.
That is one feature of SRV, but that part isn't really something we use for
anything, nor plan to (other than the fact that you specify SRV records that
way).
I suppose this could work in FreeBSD's case if the record was created
differently, instad of the normal _http._tcp record, introduce a new
one, e.g. _pkgng._tcp, so when a web browser visits pkg.freebsd.org
it gets a regular web page or some other user-visible content, and the
There is no plan to add an A record to pkg.freebsd.org, so a browser would
never be able to resolve it. Adding an A record there would IMO be more likely
to mislead people to think that pkg(8) (is it section 8?) fetches packages from
there.
specially made pkg client will resolve it to another service and
another (possibly) server. This also can be done without the SRV
record, by e.g. inspecting client's HTTP headers.
I'm not saying that the SRV record is technically wrong in this case,
I just don't see how is it useful (and surely there will be others
trying to ping pkg.freebsd.org and complaining when it fails to
resolve).
As Chip Marshall mentions, SRV records allow us to load balancing and failover.
Both are rather important in allowing us to scale pkg distribution and changing
it without requiring client side changes. The fallback handling of SRV allows
us, among other things, to have thin frontend servers which only have a subset
of packages, and then automatic fallback to the full mirrors.
Once the initial pkg distribution sites are set up, we will also create some
more SRV records, so the people who want can prioritize mirrors close to them
based on regions while still falling back to mirrors longer away from them.
Oh, and anyone using portsnap or freebsd-update are already using SRV records.
For anyone interested in more details, they can read my document describing the
system, which bapt implemented the SRV support in pkgng from:
https://docs.google.com/document/d/1MmQOV2IUfRtdlzd1i63SJQgngjPJ8eERaSa68Xydyc0/edit
--
Simon L. B. Nielsen
___
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: [HEADSUP] geli(4) weak master key generation on -CURRENT
On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Spörlein u...@freebsd.org wrote: On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: Hello, If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely ignore this mail. If you are, please read on! -CURRENT users of geli(4) should be advised that, a geli(4) device may have weak master key, if the provider is created on -CURRENT system built against source code between r238116 (Jul 4 17:54:17 2012 UTC) and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). One can verify if its provider was created with weak keys by running: # geli dump provider | grep version If the version is 7 and the system did not include this fix (r239184) when provider was initialized, then the data has to be backed up, underlying provider overwritten with random data, system upgraded and provider recreated. Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for fixing it, and Xin Li for drafting this text. PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't supported by the FreeBSD Security Team, we are not releasing an advisory, just this heads up. I haven't read commit mails in a very long time, but is there code in place that will issue a warning upon geli attach if version 7 is detected? While -CURRENT is not supported, there might be a lot of disks initialized with version 7 and they'll eventually be upgraded to 10.0-RELEASE (the OS, not necessarily the geli volumes). No, the bad code was only in head for about a month. I'm fine with having a warning, but somebody has to code it. -- Simon L. B. Nielsen ___ 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
[HEADSUP] geli(4) weak master key generation on -CURRENT
Hello, If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely ignore this mail. If you are, please read on! -CURRENT users of geli(4) should be advised that, a geli(4) device may have weak master key, if the provider is created on -CURRENT system built against source code between r238116 (Jul 4 17:54:17 2012 UTC) and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). One can verify if its provider was created with weak keys by running: # geli dump provider | grep version If the version is 7 and the system did not include this fix (r239184) when provider was initialized, then the data has to be backed up, underlying provider overwritten with random data, system upgraded and provider recreated. Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for fixing it, and Xin Li for drafting this text. PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't supported by the FreeBSD Security Team, we are not releasing an advisory, just this heads up. -- Simon L. B. Nielsen FreeBSD Security Officer signature.asc Description: OpenPGP digital signature
Re: SVN2CVS exporter down
On 2 Jul 2012, at 22:39, David O'Brien wrote: On Sun, Jul 01, 2012 at 11:14:45AM +0100, Simon L. B. Nielsen wrote: On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: Just FYI, the svn2cvs exporter is currently down due to http://svn.freebsd.org/changeset/base/237860 . I'll fix it as soon as I get back from lunch, so should be back in a few hours. Fixed. Please try not to replace files or even worse directories. Thanks. Simon, Are you saying we are now restricted in the svn operations we can perform due to the lack of the svn2cvs exporter to consume them? Basically yes, though it's not a new thing - we have been from day 1 of using svn. Or rather, each time somebody replaces a file we (peter, bz, or me) have to manually hack svn2cvs to handle the case with the increasing risk that we will do it wrong and svn/cvs will be out of sync. If so, this doesn't seem desirable... we moved to Subversion to obtain such operations as file and directory moves. You can move files and dirs, just as long as you don't move them on top of existing files. The problem is that that creates an 'remove' and 'add' operation in the same changeset which CVS cannot handle. Tested patches are accepted (http://svnweb.freebsd.org/base/svnadmin/tools/export.py), or even better - work on killing off CVS sooner rather than later. I suspect such operations will only happen with increased frequency after the Ports Collection moves to Subversion. Ports will explicitly deny Replaced files in a presubmit check. I will look at adding the same for src once I get a chance. -- Simon L. B. Nielsen ___ 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: SVN2CVS exporter down
On 1 Jul 2012, at 10:20, Bjoern A. Zeeb wrote: Just FYI, the svn2cvs exporter is currently down due to http://svn.freebsd.org/changeset/base/237860 . I'll fix it as soon as I get back from lunch, so should be back in a few hours. Fixed. Please try not to replace files or even worse directories. Thanks. -- Simon L. B. Nielsen ___ 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
svn2cvs fixed again
Hey, svn2cvs has been fixed and is catching up now. Mirrors should be fully up to date within a couple of hours (depending on their sync schedule). -- Simon L. B. Nielsen ___ 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: SVN - CVS exporter issue?
On 12 Aug 2011, at 13:11, Bjoern A. Zeeb wrote: On Aug 12, 2011, at 12:20 AM, Navdeep Parhar wrote: On Thu, Aug 11, 2011 at 07:26:36PM -0400, Michael Butler wrote: I'm not seeing any of today's SVN src updates flow through to CVS/CSUP. Is it broken? Could it be because of r224768? I vaguely recall that svn mv bothers whatever it is that converts from svn - cvs. It is. But it was 224776. I pinged the right people. Fixed. It wasn't a problem from svn this time, but a direct commit to cvs. -- Simon L. B. Nielsen ___ 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: [head tinderbox] failure on i386/i386
On 19 Jun 2011, at 14:45, FreeBSD Tinderbox wrote: World build started on Sun Jun 19 12:20:28 UTC 2011 stage 4.2: building libraries [...] cc -O2 -pipe -I/obj/i386.i386/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace -I/src/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/i386 -I/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -I/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -I/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common -I/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DDIS_MEM -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c /src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_subr.c:831:3: error: #warning need td_popc() implementation Build should be fixed now, but implementation is still broken (just as it was before the recent build breakage)... -- Simon L. B. Nielsen ___ 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: SVN - CVS burp?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Apr 2011, at 15:39, Michael Butler wrote: It seem that CVS hasn't seen any src updates sine the burp involving /usr/ports/net/unison232/files/patch-update.mli.diff. svn2cvs was down for a bit on April 6, but as ports isn't in SVN that's not related to anything there. FWIW, see also: http://twitter.com/clusteradm - -- Simon L. B. Nielsen -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2gi3gACgkQBJx0gP90kKsrfwCbBQf4B7ntp4PPO4QFSHw3Xrdz w5oAnjlPHnrOY2z3MeT8Z13cm0c5eQHg =Vabl -END PGP SIGNATURE- ___ 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: [head tinderbox] failure on amd64/amd64
On 24 Jan 2011, at 06:16, Peter Jeremy wrote: On 2011-Jan-21 20:01:32 +0100, Simon L. B. Nielsen si...@nitro.dk wrote: Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? Can cvsup-master still lose atomicity of commits? I suspect it can, Yes, there would not be a change in that - there is no simple way around that with current infrastructure (as fixing that wold mean doing evil hacks around cvs etc.) The only thing you would gain by using cvsup-master to pull sources is lower lag time between what tinderboxes build and what's in src/ VCS. in which case syncing directly off the SVN master would seem a better approach. Better yes, but that's not a simple configuration change like switching to using cvsup-master is, and unfortunately I have plenty of more interesting projects than changing tinderbox code :-). PS. for other people not being Peter Jeremy :) - no, I'm not going to consider git or going to consider discussing it - see above :-). -- Simon L. B. Nielsen ___ 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: [head tinderbox] failure on amd64/amd64
On 20 Jan 2011, at 17:23, Mike Tancsa wrote: On 1/20/2011 9:30 AM, Matthew Fleming wrote: As far as I can tell this is another cvsup / tinderbox bug. Both sysctl.h and tsc.c were modified in r217616 but somehow tsc.c is seeing the old version of sysctl.h. This happened on another of my commits a few weeks ago. Sometimes it takes a bit to get all the updates. The tinderbox syncs off my local cvsup server which gets its updates from cvsup18 once per hr. You can check its progress at Perhaps we should just set the tinderbox up to sync directly of cvsup-master instead if that makes it more useful? -- Simon L. B. Nielsen Hat: admins team etc etc. ___ 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
svn2cvs replication down for the moment
Hey, The FreeBSD svn2cvs exporter is currently down and won't be fixed until tonight CET at the earliest. This basically mean that until that is fixed, any change in svn (IE, src/) won't be available via CVS or CVSup. A change yesterday morning replaced an entire directory, which svn2cvs don't know how to deal with. As it's an entire directory I can't just use our usual hack and ignore the delete part as that will leave files in the directory in CVS which wasn't supposed to be there. As that not a quick thing to do I won't be able to fix it before getting home from work. -- Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team ___ 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: svn2cvs replication down for the moment
On 4 Nov 2010, at 09:55, Simon L. B. Nielsen wrote: The FreeBSD svn2cvs exporter is currently down and won't be fixed until tonight CET at the earliest. This basically mean that until that is fixed, any change in svn (IE, src/) won't be available via CVS or CVSup. A change yesterday morning replaced an entire directory, which svn2cvs don't know how to deal with. As it's an entire directory I can't just use our usual hack and ignore the delete part as that will leave files in the directory in CVS which wasn't supposed to be there. After some handholding (and 'evil' direct cvs commit) cvs2svn is now running again. -- Simon L. B. Nielsen Hat: FreeBSD.org cluster admins team ___ 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: OpenSSL 1.0
On 8 Oct 2010, at 13:40, Fabien Thomas wrote: Is there any plan to import OpenSSL 1.0 into the tree? Hey, Yes, the current plan is to have it in 9.0, but when it will be imported I can't say yet as it depends on having a good continuos chunk of time, which I haven't had too much of lately. I had hoped to get around to looking at it during EuroBSDCon 2010, but I didn't. -- Simon L. B. Nielsen Hat: OpenSSL maintainer ___ 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: OpenSSL 1.0
On 9 Oct 2010, at 11:37, Roubíček Zdeněk wrote: On 8 Oct 2010, at 12:40, Fabien Thomas wrote: Is there any plan to import OpenSSL 1.0 into the tree? I would be also happy to see that coming as I have a problem using current openssl as ipv6 client for tests, though it is bsd v7.3. If you need a newer version of OpenSSL in FreeBSD 7 you should try the OpenSSL ports. FreeBSD 7 will probably get the latest 0.9.8 before FreeBSD 7.4, but it won't get OpenSSL 1.0 (and neither will FreeBSD 8 for that matter). -- Simon L. B. Nielsen Hat: OpenSSL maintainer ___ 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
New FreeBSD SVN seed snapshot
Hey, I have made a new snapshot of the svn repo which can be used to start new FreeBSD svn mirrors. Hopefully I made it the right way, but... let me know if there are any issues. Since the original snapshot was made by peter the repo was 'packed' which means it uses a lot fewer files. The snapshot can be found at: ftp://ftp.freebsd.org/pub/FreeBSD/development/subversion/ You need ports/archivers/xz installed if you aren't running FreeBSD 8.1+. Thanks to rpaulo and bz for prodding my into finding out how this worked and making the new snapshot :-). I can't think of what else to say, so that was probably it :-). -- Simon L. B. Nielsen Hat: svn janitor ___ 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: New FreeBSD SVN seed snapshot
On 23 Aug 2010, at 21:27, Max Laier wrote: On Monday 23 August 2010 20:56:08 Simon L. B. Nielsen wrote: I can't think of what else to say, so that was probably it :-). MD5/SHA256/SIZE? People use that? That sounds difficult ;-) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 SIZE (svnmirror-base-r211583.tar.xz) = 893293980 SHA256 (svnmirror-base-r211583.tar.xz) = aeb176e4f8121e1ceab9be3acbc15d7d09995de2a5262e1db5999f92571799a1 MD5 (svnmirror-base-r211583.tar.xz) = caf3ba55c2d5bf3c140b2127b6722ae6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkxy2ZQACgkQFdaIBMps37IHcwCgiqbxZGzaVHwujhPpvQcFarM0 ZEMAn2P9KtafEfr5OBfgSy9wtG94sOKD =0Y7Z -END PGP SIGNATURE- I'm using a new MUA so I'm not entirely sure if will leave the above signature without mangling it... If it fails, for now the info is at http://people.freebsd.org/~simon/tmp/seedinfo.txt.asc (will go away at some point in the future). -- Simon L. B. Nielsen ___ 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
