r311871: kernel build failure: ieee80211_vht.c:94:2: error: implicit declaration ...

On CURRENT (r311871), I'm bothered with this error schown below. Buildkernel fails. It is a customized kernel. [...] Building /usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211.o Building /usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211_vht.o /usr/src/sy

Re: MANPATH not handled correctly

On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote: > Steve Kargl wrote: > > > MANPATH is not handled correctly. According to the documentation > > in apropos(1) and whatis(1): > > Can you clarify where you are seeing this documentation? > I don't see it in 7.x 10.x or current. >

Re: MANPATH not handled correctly

On Mon, Jan 09, 2017 at 10:26:16PM -0800, Simon J. Gerraty wrote: > Steve Kargl wrote: > > > On Mon, Jan 09, 2017 at 05:19:01PM -0800, Simon J. Gerraty wrote: > > > Steve Kargl wrote: > > > > > > > MANPATH is not handled correctly. According to the documentation > > > > in apropos(1) and whati

Re: MANPATH not handled correctly

On Sun, Jan 08, 2017 at 11:26:33AM -0800, Steve Kargl wrote: > MANPATH is not handled correctly. According to the documentation > in apropos(1) and whatis(1): > > MANPATH The standard search path used by man(1) may be changed by > specifying a path in the MANPATH environment varia

Re: MANPATH not handled correctly

Steve Kargl wrote: > Well, yes, it is the manpage that gets installed. > > > usr.bin/man/apropos.1 > > > > is the one that matches apropos(1) I should have said "in 10.x" ;-) In current, MK_MANDOCDB defaults yes, so you are right. So the script needs an update. Is there a PR filed? ___

Re: r311871: kernel build failure: ieee80211_vht.c:94:2: error: implicit declaration ...

Am Tue, 10 Jan 2017 11:32:00 +0100 "O. Hartmann" schrieb: > On CURRENT (r311871), I'm bothered with this error schown below. Buildkernel > fails. It is a customized kernel. > > [...] > Building > /usr/obj/usr/src/sys/FREYJA/modules/usr/src/sys/modules/wlan/ieee80211.o > Building > /usr/obj/usr

Re: [RFC/RFT] projects/ipsec

Hi All, I ported the changes from projects/ipsec to stable/11 branch. So, if it is more suitable for testing, please, welcome. You can checkout the sources from github: https://github.com/bu7cher/freebsd/tree/stable/11 Also I made the standalone patch: https://people.freebsd.org

Re: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote: > Hello, > > Since the commit in the subject /etc/rc.d/ntpdate does not work > anymore. > # /etc/rc.d/ntpdate restart > Setting date via ntp. > 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting > > This diff fixes it for me: > #

rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

Hello, Since the commit in the subject /etc/rc.d/ntpdate does not work anymore. # /etc/rc.d/ntpdate restart Setting date via ntp. 11 Jan 00:35:46 ntpdate[56020]: no servers can be used, exiting This diff fixes it for me: # diff -u /tmp/ntpdate /etc/rc.d/ntpdate --- /tmp/ntpdate2017-01-11

Re: rc.d/ntpdate broken since r311103 - /head/etc/ntp.conf - Update ntp.conf to use the ntpd pool feature

In message <1484093380.96230.94.ca...@freebsd.org>, Ian Lepore writes: > On Wed, 2017-01-11 at 00:48 +0100, Ronald Klop wrote: > > Hello, > > > > Since the commit in the subject /etc/rc.d/ntpdate does not work > > anymore. > > # /etc/rc.d/ntpdate restart > > Setting date via ntp. > > 11 Jan 00:35:

Sluggish performance on head r311648

I'v been noticing lately sluggish performance, maybe zfs? First noticed this a few days ago right after upgrading on Jan 7th to r311648 and the last upgrade before that was around dec 30-jan 1 (not sure of rev). Decided to upgrade again today. I usually build and install head every week or two, but