On 2012-03-24 16:52, Super Bisquit wrote:
On Sat, Mar 24, 2012 at 10:08 AM, Dimitry Andric d...@freebsd.org wrote:
As of r233419 in head, you should now be able to build world and the
GENERIC kernel using clang, and without the need to place NO_WERROR=
and/or WERROR= in your src.conf file.
...
On Tue, Jan 24, 2012 at 4:32 PM, Rick Macklem rmack...@uoguelph.ca wrote:
As such, specifying udp or mntudp options in the /etc/fstab
entry for / on a diskless NFS client could result in the mount -u
failing. I'd suggest that udp and mntudp be avoided for this
case, if you are using the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/25/12 17:44, Craig Rodrigues wrote:
If a user boots with an NFS root mount, and does not specify
UDP or TCP, what is the default transport protocol used?
If I user does: mount -t nfs or mount_nfs
from the command-line, and does
On Sat, 14 Jan 2012 15:30:15 +
Chris Rees cr...@freebsd.org wrote:
On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in freebsd-rc@, I have removed set_rcvar() from
rc.subr. The concept of
On 01/15/2012 00:11, Conrad J. Sabatier wrote:
Chris, if you're working on fixing ports' rc files
Thanks for taking a look at this. FYI, all of the rc.d scripts that are
actually in the ports tree have already been fixed. The outliers at this
point are scripts that are included in the
On 15 January 2012 08:11, Conrad J. Sabatier conr...@cox.net wrote:
On Sat, 14 Jan 2012 15:30:15 +
Chris Rees cr...@freebsd.org wrote:
On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in
On Sun, 15 Jan 2012 00:40:36 -0800
Doug Barton do...@freebsd.org wrote:
On 01/15/2012 00:11, Conrad J. Sabatier wrote:
Chris, if you're working on fixing ports' rc files
Thanks for taking a look at this. FYI, all of the rc.d scripts that
are actually in the ports tree have already been
On Sun, 15 Jan 2012 08:51:53 +
Chris Rees cr...@freebsd.org wrote:
[snip]
Don't thank me!
http://lists.freebsd.org/pipermail/cvs-ports/2012-January/233843.html
Wow! Doug has been a busy boy recently! :-)
The only ones that will cause trouble are the ones provided by
upstream, but a
On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote:
to make the change by hand, change this:
name=foo
rcvar=`set_rcvar`
to:
name=foo
rcvar=foo_enable
The scripts installed by net/avahi-app still use set_rcvar() because
they are included in the source.
--
Denny Lin
On 14 January 2012 11:11, Denny Lin dennyli...@hs.ntnu.edu.tw wrote:
On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote:
to make the change by hand, change this:
name=foo
rcvar=`set_rcvar`
to:
name=foo
rcvar=foo_enable
The scripts installed by net/avahi-app still use
On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote:
Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup process, which is especially noticeable on
slower systems, such
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup process, which is especially noticeable on
slower systems, such as
On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
Howdy,
Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
The concept of set_rcvar() was nice in theory, but the forks it creates
are a drag on the startup
On 01/14/2012 06:44, Jilles Tjoelker wrote:
Why must the 2-argument form of set_rcvar die at the same time? It is
used very differently and does not cause unnecessary forks. Instead, it
is called in the same shell environment to define additional rc.conf
variables that have defaults and are
On 01/14/2012 07:16, Rainer Hurling wrote:
BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?
http://lists.freebsd.org/pipermail/freebsd-rc/2012-January/002660.html
Also, as I pointed out in my commit message, using the literal value is
a tiny bit faster, and every
On 14.01.2012 22:29 (UTC+1), Doug Barton wrote:
On 01/14/2012 07:16, Rainer Hurling wrote:
BTW, is there any reason not to set 'rcvar=${name}_enable' in all that
cases?
http://lists.freebsd.org/pipermail/freebsd-rc/2012-January/002660.html
Also, as I pointed out in my commit message, using
David Chisnall thera...@freebsd.org writes:
[...]
libcxxrt and libc++ are now in contrib and building with the base
system, but are not used by anything (and are only built if you set
WITH_LIBCPLUSPLUS=yes when building world, not by default). If you
want to test some code with the new
On 26 Nov 2011, at 23:09, Niclas Zeising wrote:
This is great news! Thank you very much for undertaking this work. Just
a question, is there a wiki page with these instructions, or a wiki page
related to this work where these instructions can be added? If they're
not on the wiki, I can do
On Sun, Nov 27, 2011 at 1:58 PM, David Chisnall thera...@freebsd.org wrote:
On 26 Nov 2011, at 23:09, Niclas Zeising wrote:
This is great news! Thank you very much for undertaking this work. Just
a question, is there a wiki page with these instructions, or a wiki page
related to this work
Am 11/27/11 15:14, schrieb C. P. Ghost:
On Sun, Nov 27, 2011 at 1:58 PM, David Chisnall thera...@freebsd.org wrote:
On 26 Nov 2011, at 23:09, Niclas Zeising wrote:
This is great news! Thank you very much for undertaking this work. Just
a question, is there a wiki page with these
On 27 Nov 2011, at 15:26, O. Hartmann wrote:
Why is the knob
WITH_LIBCPLUSPLUS=yes
located in /etc/make.conf and not in /etc/src.conf?
Sorry, it is in src.conf, I was thinking about enabling clang. Or possibly not
thinking at all. It's Sunday, so thinking is optional...
Am 11/27/11 16:54, schrieb David Chisnall:
On 27 Nov 2011, at 15:26, O. Hartmann wrote:
Why is the knob
WITH_LIBCPLUSPLUS=yes
located in /etc/make.conf and not in /etc/src.conf?
Sorry, it is in src.conf, I was thinking about enabling clang. Or possibly
not thinking at all. It's
On 2011-11-26 21:59, David Chisnall wrote:
Hi,
I've just imported libc++[1] and libcxxrt[2] to head. libc++ is UUIC
licensed, libcxxrt is 2-clause BSDL. The former implements the C++ standard
template library, and provides all of the programmer-visible parts. The
latter provides an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28.09.2011 21:32, Hartmann, O. wrote:
floating like a dead man in the water. I suspect the
conversters/libiconv broke something, since it claims it has
installed libiconv.so.3, but there is never such a shared object
installed!
Here's what I
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin
10 'X' for their tenth version of their operating system ...
FreeBSD XP anyone?
Are you sure
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin
10 'X' for their tenth version of their operating system ...
FreeBSD XP anyone?
Are you sure there's a sufficient window of opportunity?
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin
10 'X' for their tenth version of their operating
On Sep 28, 2011, at 10:29 AM, Hartmann, O. wrote:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin
10
On 09/28/11 20:20, h h wrote:
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com wrote:
2011/9/27 O. Hartmann
On 09/28/11 20:41, Garrett Cooper wrote:
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com wrote:
Eitan Adler li...@eitanadler.com
On 09/28/11 20:56, Hartmann, O. wrote:
On 09/28/11 20:41, Garrett Cooper wrote:
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 15:47, per...@pluto.rain.com
On 09/28/11 12:16, Hartmann, O. wrote:
On 09/28/11 20:56, Hartmann, O. wrote:
On 09/28/11 20:41, Garrett Cooper wrote:
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O.ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 21:16, Hartmann, O. wrote:
On 09/28/11 20:56, Hartmann, O. wrote:
On 09/28/11 20:41, Garrett Cooper wrote:
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O. ohart...@zedat.fu-berlin.de writes:
On 09/28/11 09:26, Hartmann, O. wrote:
On 09/28/11 21:30, Matt wrote:
On 09/28/11 12:16, Hartmann, O. wrote:
On 09/28/11 20:56, Hartmann, O. wrote:
On 09/28/11 20:41, Garrett Cooper wrote:
On Sep 28, 2011, at 11:38 AM, Hartmann, O. wrote:
On 09/28/11 20:20, h h wrote:
Hartmann, O.ohart...@zedat.fu-berlin.de writes:
On
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since this build binutils and even gettext and libiconv, I guess they
got broken. Last I saw was a successful installation
On Wednesday 28 September 2011 12:18:47 Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since this build binutils and even gettext and libiconv, I guess
On 09/28/2011 13:45, Beech Rintoul wrote:
On Wednesday 28 September 2011 12:18:47 Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since this build binutils
On Wednesday 28 September 2011 12:47:50 Doug Barton wrote:
On 09/28/2011 13:45, Beech Rintoul wrote:
On Wednesday 28 September 2011 12:18:47 Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port
On Wed, Sep 28, 2011 at 1:45 PM, Beech Rintoul be...@freebsd.org wrote:
On Wednesday 28 September 2011 12:18:47 Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf
On Wednesday 28 September 2011 12:53:23 Beech Rintoul wrote:
On Wednesday 28 September 2011 12:47:50 Doug Barton wrote:
On 09/28/2011 13:45, Beech Rintoul wrote:
On Wednesday 28 September 2011 12:18:47 Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to
Garrett Cooper yaneg...@gmail.com writes:
So if I change /usr/src/sys/conf/newvers.sh to something like vers 9.9 I'm
not
going to shoot myself in the foot if I try and update? I would really like to
avoid downgrading this box.I've altready been bitten once today and had to
build packages
On 09/28/11 22:18, Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since this build binutils and even gettext and libiconv, I guess they
got broken. Last I
On 09/28/11 15:41, Hartmann, O. wrote:
On 09/28/11 22:18, Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since this build binutils and even gettext and
On Sep 28, 2011, at 4:36 PM, Matt wrote:
On 09/28/11 15:41, Hartmann, O. wrote:
On 09/28/11 22:18, Doug Barton wrote:
On 09/28/2011 12:39, Hartmann, O. wrote:
The mess started to happen when I tried to repair a non CLANG
compiling port math/gotoblas with portmaster -vf amth/gotoblas.
Since
It just means that folks didn't plan ahead and didn't think up
proper contingency plans.
First off, apologies to Garrett, I'm not picking on you directly, but I
kinda knew this would come up.
The undeniable fact is that configure scripts in general have chosen to
do things a certain way.
On 27/09/2011, at 13:33, Ade Lovett wrote:
That is to say, until 9.0-R happens, and for some considerable period
afterwards, ya'll can pretty much expect ports/ to be non-functional on
HEAD. PRs mentioning this will be gleefully closed referencing this
message.
I imagine you can work around
Kevin Oberman kob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to
On Tue, 27 Sep 2011, h h wrote:
Kevin Oberman kob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue
On 09/27/11 08:35, h h wrote:
Kevin Obermankob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovetta...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems
On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote:
On 09/27/11 08:35, h h wrote:
Kevin Obermankob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovetta...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/
At 11:18 27/09/2011, Anton Shterenlikht wrote:
Now I understand why some OS vendors have choosen the latin 10 'X' for
their tenth version of their operating system ...
At least there will be a long rest after
the move to 10 is complete.. until FreeBSD 100.
Or move to hexadecimal
$ export
Ade Lovett a...@freebsd.org wrote:
The undeniable fact is that configure scripts in general have
chosen to do things a certain way. Unfortunately for us (us
being FreeBSD), we have now broken these conceptions by moving
to a dual-digit major release.
I don't suppose
REVISION=A.1
i.e.
On 09/27/11 16:46, per...@pluto.rain.com wrote:
Ade Lovetta...@freebsd.org wrote:
The undeniable fact is that configure scripts in general have
chosen to do things a certain way. Unfortunately for us (us
being FreeBSD), we have now broken these conceptions by moving
to a dual-digit major
On 27 September 2011 10:18, Anton Shterenlikht me...@bristol.ac.uk wrote:
On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote:
On 09/27/11 08:35, h h wrote:
Kevin Obermankob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovetta...@freebsd.org wrote:
With the
Eduardo Morras nec...@retena.com writes:
At 11:18 27/09/2011, Anton Shterenlikht wrote:
Now I understand why some OS vendors have choosen the latin 10 'X' for
their tenth version of their operating system ...
At least there will be a long rest after
the move to 10 is complete.. until
krad writes:
we can leave that to our grand children to figure out though 8)
Wasn't that what people said about two-digit years?
Robert Huff
___
freebsd-current@freebsd.org mailing list
On 27 September 2011 20:22, Robert Huff roberth...@rcn.com wrote:
krad writes:
we can leave that to our grand children to figure out though 8)
Wasn't that what people said about two-digit years?
Our children will be dealing with Y2038. :-)
Adrian
2011/9/27 O. Hartmann ohart...@zedat.fu-berlin.de:
Now I understand why some OS vendors have choosen the latin 10 'X' for their
tenth version of their operating system ...
FreeBSD XP anyone?
___
freebsd-po...@freebsd.org mailing list
On Tue, Sep 27, 2011 at 08:22:54AM -0400, Robert Huff wrote:
krad writes:
we can leave that to our grand children to figure out though 8)
Wasn't that what people said about two-digit years?
Not quite. There they mostly said No way that this program will still
be in use when
On 27 September 2011 13:57, Adrian Chadd adr...@freebsd.org wrote:
On 27 September 2011 20:22, Robert Huff roberth...@rcn.com wrote:
krad writes:
we can leave that to our grand children to figure out though 8)
Wasn't that what people said about two-digit years?
Our children
Adrian Chadd writes:
we can leave that to our grand children to figure out though 8)
Wasn't that what people said about two-digit years?
Our children will be dealing with Y2038. :-)
Statistically, some of us will.
Robert
On Tue, Sep 27, 2011 at 09:36:17AM -0400 I heard the voice of
Robert Huff, and lo! it spake thus:
Adrian Chadd writes:
Our children will be dealing with Y2038. :-)
Statistically, some of us will.
Actually, I had to deal with it just last week...
--
Matthew Fuller (MF4839) |
On 09/27/11 16:27, Matthew D. Fuller wrote:
On Tue, Sep 27, 2011 at 09:36:17AM -0400 I heard the voice of
Robert Huff, and lo! it spake thus:
Adrian Chadd writes:
Our children will be dealing with Y2038. :-)
Statistically, some of us will.
Actually, I had to deal with it just last week...
On 27 September 2011 10:18, Anton Shterenlikht me...@bristol.ac.uk wrote:
On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote:
On 09/27/11 08:35, h h wrote:
Kevin Obermankob6...@gmail.com writes:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovetta...@freebsd.org wrote:
With the advent
On Sep 27, 2011 10:04 AM, Chris Rees cr...@freebsd.org wrote:
On 27 September 2011 10:18, Anton Shterenlikht me...@bristol.ac.uk
wrote:
On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote:
On 09/27/11 08:35, h h wrote:
Kevin Obermankob6...@gmail.com writes:
On Mon, Sep 26,
On (26/09/2011 23:03), Ade Lovett wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to choose something completely
at random) assuming that FreeBSD would
On Sep 27, 2011, at 8:50 PM, Gleb Kurtsou wrote:
On (26/09/2011 23:03), Ade Lovett wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to choose something
Hi--
On Sep 27, 2011, at 11:50 AM, Gleb Kurtsou wrote:
It's more exciting than that. FreeBSD = 10 is already seized by Apple :)
http://www.google.com/codesearch#search/q=__FreeBSD__%5CW%2B10type=cs
MacOS X doesn't define __FreeBSD__ either in CPP macros or the system headers:
% touch foo.h;
On 09/27/11 02:37, Daniel O'Connor wrote:
On 27/09/2011, at 13:33, Ade Lovett wrote:
That is to say, until 9.0-R happens, and for some considerable period
afterwards, ya'll can pretty much expect ports/ to be non-functional on
HEAD. PRs mentioning this will be gleefully closed referencing
Michael Butler i...@protected-networks.net writes:
On 09/27/11 02:37, Daniel O'Connor wrote:
On 27/09/2011, at 13:33, Ade Lovett wrote:
That is to say, until 9.0-R happens, and for some considerable period
afterwards, ya'll can pretty much expect ports/ to be non-functional on
HEAD. PRs
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems from configure scripts (to choose something completely
at random)
On Mon, Sep 26, 2011 at 9:56 PM, Kevin Oberman kob6...@gmail.com wrote:
On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett a...@freebsd.org wrote:
With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
expected, ports/ is going to be essentially unusable for a while.
The issue stems
On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper yaneg...@gmail.com wrote:
It's not the FreeBSD dev's fault. Unfortunately the autotools folks
were microoptimizing and didn't consider that the future would come
sooner than it actually did.
Garrett,
First, I'm not complaining or criticizing
On Mon, Sep 26, 2011 at 10:15 PM, Kevin Oberman kob6...@gmail.com wrote:
On Mon, Sep 26, 2011 at 10:01 PM, Garrett Cooper yaneg...@gmail.com wrote:
It's not the FreeBSD dev's fault. Unfortunately the autotools folks
were microoptimizing and didn't consider that the future would come
sooner
On 2011-07-16 13:55, Doug Barton wrote:
Howdy,
I wanted to let everyone know that BIND 9.8.0-P4 has just been imported
to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has
many nice new features vs. 9.6.x, especially in the area of DNSSEC. You
can read more about the new
From: Rick Macklem
Well, I doubt you'll find much difference performance wise. An NFS server can
be looked as a protocol translator, converting the NFS RPCs into VFS/VOP
calls. Performance is largely defined by how well the network stack and/or
file system perform.
When you set up a server,
Chris Forgeron wrote:
[stuff snipped]
I hope to do a speed test comparison between new and old NFS servers
this weekend - At this stage, my feeling is that the new NFS server is
at least as fast. I suspect tests will show it to be faster (at least
the code looks faster. :-) ).
Well, I
On Sat, Jun 04, 2011 at 05:54:49AM +0400, Andrey Chernov wrote:
On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
On a freshly installed -CURRENT, to view a colorized manpage in color
and in full terminal width, try this:
env MANCOLOR=yes MANWIDTH=tty man grotty
BTW,
I've been pounding on the new NFS server with a few test VM's from my ESX
cluster for the last 2 weeks, 24/7. Everything looks solid, no panics, no
errors, no corruption. Memory usage is staying stable, so I haven't found any
leaks. I'm using IOMETER to move a few TB of randomized data a
On Fri, Jun 03, 2011 at 02:48:59PM +, Ruslan Ermilov wrote:
On a freshly installed -CURRENT, to view a colorized manpage in color
and in full terminal width, try this:
env MANCOLOR=yes MANWIDTH=tty man grotty
SGR presence can be easily autodetected analyzing termcap capibilities
On Wed, 27 Apr 2011 13:59:49 -0400 (EDT) Rick Macklem wrote:
Hopefully, you won't need to do anything to keep things working
and this won't cause you grief, rick
I've updated my tiny home network (host + two diskless clients).
No problems so far. Great work, thanks!
--
WBR, Boris Samorodov
On 04/29/11 11:00, Boris Samorodov wrote:
On Wed, 27 Apr 2011 13:59:49 -0400 (EDT) Rick Macklem wrote:
Hopefully, you won't need to do anything to keep things working
and this won't cause you grief, rick
I've updated my tiny home network (host + two diskless clients).
No problems so far.
On Wed, Apr 27, 2011 at 07:39:17PM -0400, Rick Macklem wrote:
Hi,
Is there any impact on /usr/sbin/amd?
I'll admit I haven't tested it (I've never used the FreeBSD amd). I
will
do so once I figure out how to set it up, but I'm hoping others will
report
any problems. If you
On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote:
The commit r221124 switches the default NFS client to the new one in head.
The fstype newnfs is now nfs and the regular/old NFS client is
now fstype oldnfs. As such, mount -t nfs ... will use the new client.
Hi,
Is there any impact
On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote:
The commit r221124 switches the default NFS client to the new one in
head.
The fstype newnfs is now nfs and the regular/old NFS client is
now fstype oldnfs. As such, mount -t nfs ... will use the new
client.
Hi,
Is
On Wed, Apr 27, 2011 at 07:39:17PM -0400, Rick Macklem wrote:
Hi,
Is there any impact on /usr/sbin/amd?
I'll admit I haven't tested it (I've never used the FreeBSD amd). I will
do so once I figure out how to set it up, but I'm hoping others will report
any problems. If you can test
On Tue, Apr 26, 2011 at 09:26:05AM -0400, John Baldwin wrote:
Actually, I think we should switch GENERIC in HEAD to the new client and
kernel very soon. The goal is to get current users testing the new client
and
server so they can uncover any bugs. If problems crop up during the testing
On Sunday, April 24, 2011 3:12:13 pm Rick Macklem wrote:
On 04/24/11 02:00, Rick Macklem wrote:
There will soon be a commit to head that will change the
default NFS server to the new one that was called the
experimental NFS server (but no longer experimental). After
this commit, you
On 04/26/11 15:54, Rick Macklem wrote:
Since today's source (FreeBSD 9.0-CURRENT/amd64 (source is:
Revision:
221060) update I get the follwoing error while building the kernel
(options NFSD/options NFSCL instead of options NFSSERVER/options
NFSCLIENT):
cc -c -O2 -frename-registers -pipe
Actually, I think we should switch GENERIC in HEAD to the new client
and
kernel very soon. The goal is to get current users testing the new
client and
server so they can uncover any bugs. If problems crop up during the
testing
that can't be resolved, we can always revert to the older
On 04/24/11 02:00, Rick Macklem wrote:
There will soon be a commit to head that will change the
default NFS server to the new one that was called the
experimental NFS server (but no longer experimental). After
this commit, you must use -o on both mountd and nfsd to
force the system to use the
On 04/24/11 02:00, Rick Macklem wrote:
There will soon be a commit to head that will change the
default NFS server to the new one that was called the
experimental NFS server (but no longer experimental). After
this commit, you must use -o on both mountd and nfsd to
force the system to
On Friday, 22 April 2011, Adrian Chadd adr...@freebsd.org wrote:
Hm, I'll revert this change for now.
Sorry!
Could you post a diff of your reverted change, I currently have no
connectivity to be able to update src.
Sevan
___
On 22 April 2011 15:20, Sevan / Venture37 ventur...@gmail.com wrote:
On Friday, 22 April 2011, Adrian Chadd adr...@freebsd.org wrote:
Hm, I'll revert this change for now.
Sorry!
Could you post a diff of your reverted change, I currently have no
connectivity to be able to update src.
or I
On 21 April 2011 06:19, Adrian Chadd adrian.ch...@gmail.com wrote:
It's possible, but none of the current drivers in -head implement MIMO and
the data wasn't actually filled out in net80211, so it's highly unlikely it
was being used.
The rt2860/70 driver was, attempting to compile the drive
Hm, I'll revert this change for now.
Sorry!
Adrian
On 21 April 2011 23:40, Sevan / Venture37 ventur...@gmail.com wrote:
On 21 April 2011 06:19, Adrian Chadd adrian.ch...@gmail.com wrote:
It's possible, but none of the current drivers in -head implement MIMO
and
the data wasn't actually
Hi,
On Thu, Apr 21, 2011 at 12:21 AM, Adrian Chadd adrian.ch...@gmail.com wrote:
Hi,
If you're using wireless on -HEAD and using an older base w/ newer kernels,
you may wish to recompile ifconfig.
I've changed the binary ABI used for MIMO statistics (which nothing actually
exports yet) but
It's possible, but none of the current drivers in -head implement MIMO and
the data wasn't actually filled out in net80211, so it's highly unlikely it
was being used.
Adrian
On 21 April 2011 13:07, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Thu, Apr 21, 2011 at 12:21 AM, Adrian Chadd
601 - 700 of 2479 matches
Mail list logo
