daily CVS update output

[NetBSD source update]

Updating src tree:
cvs update: `src/external/mit/xorg/server/xorg-server/afb/Makefile' is no 
longer in the repository
cvs update: `src/external/mit/xorg/server/xorg-server/afb/Makefile.afb' is no 
longer in the repository
cvs update: `src/external/mit/xorg/server/xorg-server/cfb/Makefile' is no 
longer in the repository
cvs update: `src/external/mit/xorg/server/xorg-server/cfb/Makefile.cfb' is no 
longer in the repository
cvs update: `src/external/mit/xorg/server/xorg-server/cfb32/Makefile' is no 
longer in the repository
P src/external/mit/xorg/server/xorg-server/hw/netbsd/x68k/Makefile
P src/external/mit/xorg/server/xorg-server/hw/xfree86/common/Makefile
cvs update: `src/external/mit/xorg/server/xorg-server/mfb/Makefile' is no 
longer in the repository
cvs update: `src/external/mit/xorg/server/xorg-server/mfb/Makefile.mfb' is no 
longer in the repository
P src/share/man/man3/rbtree.3
P src/share/mk/bsd.x11.mk

Updating xsrc tree:
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68k.h
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kFb.c
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kGraph.c
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kInit.c
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kKbd.c
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kMouse.c
P xsrc/external/mit/xorg-server/dist/hw/netbsd/x68k/x68kText.c
P xsrc/external/mit/xorg-server/include/dix-config.h
P xsrc/external/mit/xorg-server/include/xorg-server.h


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Wed Aug 31 03:01:45 2016
SUP Scan for current completed at Wed Aug 31 03:02:01 2016
SUP Scan for mirror starting at Wed Aug 31 03:02:01 2016
SUP Scan for mirror completed at Wed Aug 31 03:04:13 2016



Updating release-6 src tree (netbsd-6):

Updating release-6 xsrc tree (netbsd-6):

Running the SUP scanner:
SUP Scan for release-6 starting at Wed Aug 31 03:06:40 2016
SUP Scan for release-6 completed at Wed Aug 31 03:06:49 2016



Updating release-7 src tree (netbsd-7):

Updating release-7 xsrc tree (netbsd-7):

Running the SUP scanner:
SUP Scan for release-7 starting at Wed Aug 31 03:09:11 2016
SUP Scan for release-7 completed at Wed Aug 31 03:09:17 2016




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  55119121 Aug 31 03:10 ls-lRA.gz

Re: bind -> unbound/nsd

[Erik Berls]

On August 29, 2016 at 8:36:23 PM, Thor Lancelot Simon (t...@panix.com) wrote:
> On Sun, Aug 28, 2016 at 06:24:41AM +, David Holland wrote:
> >
> > So for what it's worth: I don't see any need to have a DNS server in
> > base. It may be traditional, but few people use it; the landscape's
>  
> As a guy who spent the best part of a decade building embedded products
> out of NetBSD: I'll believe all this "you can just add a package" stuff
> when all this stuff I should supposedly be able to use from pkgsrc
> cross-compiles as cleanly as our base system does.

Yes, we lost a lot of what was supposed to be the goal with pkgsrc in that area 
(cross-compiling).
Work has been done, but, like many pkgsrc projects, it never really became a 
first class citizen. Not to disparage all the work the pkgsrc people do. 

Yes, the loss of cross compile *does* impact the decision on pkgsrc vs base.  
However, ARMs are getting faster, m68ks aren’t. ;)

I firmly believe we need to have a stronger push into the embedded/appliance 
space. 

That said, yeah, we (image builders) are at a disadvantage until we can turn 
that ship. Maybe this is the impetus to start improvements on making pkgsrc 
more useful to cross environments?
Right now we’re at the the original 4.3BSD/386BSD here’s a long list of 
instructions:
https://ftp.netbsd.org/pub/pkgsrc/stable/pkgsrc/doc/HOWTO-use-crosscompile
(Further described here: 
https://www.netbsd.org/gallery/presentations/riastradh/asiabsdcon2015/pkgsrc-cross-paper.pdf)

We need to get here:
https://wiki.netbsd.org/projects/project/cross_nb_pkgsrc/



>  
> I had to integrate *PHP* to our "base system" build. That sucked,
> but it sucked a lot less than the logistical and non-reproducibility
> issues which stemmed from building parts of our product outside the
> wonderful, clean, cross-compile-from-anywhere-to-anywhere NetBSD
> system build.
>  
> Thor
>  

--  
Erik Berls

Re: high cpu load with tcpdump

[Manuel Bouyer]

On Tue, Aug 30, 2016 at 04:12:02PM +0200, Rhialto wrote:
> Meanwhile, in 7.0.1, tcpdump still seems to cause (close to) 100% cpu
> load.  (Tested with "tcpdump -i re1 -vvv icmp6" on an almost idle link)
> 
> Has this been fixed in -current? Will it be in 7.0.2 (or 7.1?) soon?

I'm not sure it has been fixed. I'm seeing such issues with arpwatch
or ndpwatch (which uses bpf too).

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: high cpu load with tcpdump

[Rhialto]

On Sun 06 Mar 2016 at 18:59:57 +0100, Manuel Bouyer wrote:
> On Fri, Mar 04, 2016 at 12:31:07PM +, Patrick Welche wrote:
> > Was there ever a conclusion to the "pipe read returning EAGAIN" thread?
> > 
> >   https://mail-index.netbsd.org/current-users/2016/02/07/msg028841.html
> 
> The conclusion was that it's a programming error in the application,
> but there's still something messy with poll (it says there's one descriptor
> ready for read but there are two descriptors in the fileset).

Meanwhile, in 7.0.1, tcpdump still seems to cause (close to) 100% cpu
load.  (Tested with "tcpdump -i re1 -vvv icmp6" on an almost idle link)

Has this been fixed in -current? Will it be in 7.0.2 (or 7.1?) soon?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly.


signature.asc
Description: PGP signature