daily CVS update output

2019-11-01 Thread NetBSD source update


Updating src tree:
P src/common/lib/libc/misc/ubsan.c
P src/doc/HACKS
P src/external/bsd/jemalloc/lib/Makefile.inc
P src/sys/arch/amd64/include/pmap.h
P src/sys/arch/arm/fdt/cpu_fdt.c
P src/sys/arch/arm/sunxi/sunxi_gmac.c
P src/sys/arch/arm/ti/files.ti
U src/sys/arch/arm/ti/omap2_gpmcreg.h
U src/sys/arch/arm/ti/omap2_nand.c
P src/sys/arch/arm/ti/omap3_cm.c
U src/sys/arch/arm/ti/ti_gpmc.c
P src/sys/arch/arm/ti/ti_iic.c
P src/sys/arch/evbarm/conf/GENERIC
P src/sys/arch/macppc/conf/GENERIC
P src/sys/arch/macppc/conf/files.macppc
U src/sys/arch/macppc/dev/psoc.c
P src/sys/arch/x86/x86/cpu_rng.c
P src/sys/dev/i2c/files.i2c
cvs update: `src/sys/dev/i2c/tps65950.c' is no longer in the repository
P src/sys/dev/i2c/twl4030.c
P src/sys/dev/rasops/rasops.h
P src/sys/net/if_ipsec.c
P src/sys/net/if_ipsec.h
P src/sys/netinet/tcp.h
P src/sys/netinet6/in6.h
P src/sys/netinet6/ip6_forward.c
P src/sys/netinet6/ip6_output.c
P src/sys/netipsec/ipsec.h
P src/sys/netipsec/ipsec6.h
P src/sys/netipsec/ipsec_output.c
P src/sys/netipsec/ipsecif.c
P src/sys/netipsec/ipsecif.h
P src/sys/netipsec/xform.h
P src/sys/netipsec/xform_ah.c
P src/sys/netipsec/xform_esp.c
P src/sys/netipsec/xform_ipcomp.c
P src/sys/netipsec/xform_ipip.c
P src/sys/netipsec/xform_tcp.c
P src/sys/uvm/uvm_map.c
P src/usr.sbin/npf/npfctl/npf_show.c

Updating xsrc tree:


Killing core files:


Updating tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting...pax: Unable to access src/gnu (No such file or directory)
pax: WARNING! These file names were not selected:
src/gnu
 done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done
src/sbin: collecting... replacing... done
src/share: collecting... replacing... done
src/sys: collecting... replacing... done
src/tests: collecting... replacing... done
src/tools: collecting... replacing... done
src/usr.bin: collecting... replacing... done
src/usr.sbin: collecting... replacing... done
src/config: collecting... replacing... done
src: collecting... replacing... done
xsrc/top-level: collecting... replacing... done
xsrc/external: collecting... replacing... done
xsrc/local: collecting... replacing... done
xsrc: collecting... replacing... done



Updating release-7 src tree (netbsd-7):
P distrib/sets/lists/modules/md.amd64
U distrib/sets/lists/modules/md.evbppc.powerpc
P distrib/sets/lists/modules/md.i386
U doc/CHANGES-7.3

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


Updating release-7 tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done
src/sbin: collecting... replacing... done
src/share: collecting... replacing... done
src/sys: collecting... replacing... done
src/tests: collecting... replacing... done
src/tools: collecting... replacing... done
src/usr.bin: collecting... replacing... done
src/usr.sbin: collecting... replacing... done
src/config: collecting... replacing... done
src/x11: collecting... replacing... done
src: collecting... replacing... done
xsrc/top-level: collecting... replacing... done
xsrc/external: collecting... replacing... done
xsrc/local: collecting... replacing... done
xsrc/xfree: collecting... replacing... done
xsrc: collecting... replacing... done



Updating release-8 src tree (netbsd-8):
U doc/CHANGES-8.2
P sys/kern/subr_disk.c

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


Updating release-8 tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: 

Re: heads-up: planned changes in nvmm

2019-11-01 Thread David Brownlee
On Mon, 28 Oct 2019 at 14:58, Maxime Villard  wrote:
>
> Le 22/10/2019 à 22:34, Maxime Villard a écrit :
> > I will soon commit a set of changes in NVMM, which will require a full
> > rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API,
> > the libnvmm ATF tests, and the qemu-nvmm package if you're using it.
> >
> > You can cherry-pick each change, but it will be easier to just do a full
> > distribution rebuild and reinstall.
> >
> > Overall it is no different than what I've been doing over the last six
> > months. This time, however, the changes will also be pulled up to 9beta
> > afterwards.
> >
> > I will push my changes in -current and update the qemu-nvmm package in
> > several rounds probably over several days, and then will pull up to 9beta.
> >
> > In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta.
>
> So I think I'm done, I'll let the dust settle for a few days, and then will
> request pullup9.
>[...]

Would you have an idea when the changes might be pulled up to netbsd-9?
(This is not a "hey get it done", more a "thanks for a cool feature
which has my laptop
already very happily running 64bit Ubuntu and Windows 7 under netbsd-9
and looking forward to doing even more as time goes on" :)

Would there be any general advice in setting up a box to run a few Linux nvmm
guests (I have a non production XEN box I'm tempted to cut across)

For anyone else wanting to {re,}build pkgsrc-wip qemu-nvmm before the pullups
I'd recommend updating to 69cc68ce4bea01c3c1783029442e2ac676430e32,
then copying the qemu-nvmm directory then updating back to HEAD

Thanks again

David


Re: xfwm4 crashes on NetBSD 9.99.17 (was "Re: firefox dumping core after NetBSD upgrade")

2019-11-01 Thread Chavdar Ivanov
I don't remove xfwm4.xml, just set use_compositing setting to no. Then
I am able to start xfce4 without a problem many times. EVen if I
delete that file - out of xfce4 - then startxfce4, it starts first
time; on exit use_compositing is set to true, subsequent startxfce4
starts, but without xfwm4 (and a longer delay to dump core); as I have
a terminal in the session, I still can edit xfwm4.xml, set
use_compositing to false and nohup xfwm4...

On Fri, 1 Nov 2019 at 05:49, David H. Gutteridge  wrote:
>
> On Tue, 2019-10-29 at 19:52 -0400, David H. Gutteridge wrote:
> > On Tue, 2019-10-29 at 10:38 +, Chavdar Ivanov wrote:
> > > I've tested xfce4 - a few days old build from -current pkgsrc - now
> > > on
> > > real hardware with functional dri2. I get the same as with the
> > > VirtualBox client - I have to disable compositing to get xfwm4
> > > working. At the same time glmark2 returns the usual or close to
> > > results.
> >
> > What do you find if you disable compositing to get Xfce to start, and
> > then enable it once xfwm4 is running successfully? I find that seems
> > to
> > work. So it fails some sort of initial probing, but then is able to
> > activate the feature later, anyway. (As if there are two different
> > code
> > paths for this, or something is getting corrupted in memory during
> > start up, but that isn't happening later on. I haven't had a chance to
> > look at it in gdb again, yet.)
>
> Sorry, that's the wrong example, the right example is:
>
> - Move or delete the xfwm4.xml file from the .config path
> - Start Xfce
> - Go to Window Manager Tweaks->Compositor
> - Note that the compositor is enabled, and related setting changes (e.g.
> opacity of window decorations) successfully apply.
>
> Yet, on the next startup cycle, xfwm4 crashes. (And it crashes with my
> previous example of starting with the compositor turned off, and then
> turning it on.)
>
> Regards,
>
> Dave
>
>


-- 



Re: scp protocol error on multiple file copy?

2019-11-01 Thread Michael van Elst
jdba...@consolidated.net ("John D. Baker") writes:

>On the remote, it invokes 'scp' with an undocumented "-f" (lowercase
>"f") switch:

>  debug1: Sending command: scp -v -p -f 
> /path/to/@(sets/@([bem*|text.tgz)|kernel/netbsd-CUSTOM.gz)

>passing it the path/fileglob given on the local host.


Actually that is passed to the shell first, if the shell doesn't interpret
the globbing, it passes it then unchanged to the command.

The '-f' and the '-t' are the hidden flags that tell the scp command to
serve the operation on the remote machine, depending on direction (from,to):

% scp fud:'@(raid0|raid1).label' .
protocol error: filename does not match request

With -v you see that the remote machine (with ksh) correctly globs that pattern
and tries to send the files:

Sink: C0644 894 raid0.label
Sending file modes: C0644 894 raid0.label
protocol error: filename does not match request
Sending file modes: C0644 890 raid1.label

But the local scp client tries to parse the answers and since it doesn't
understand the ksh pattern, it rejects the files sent. The -T flag skips
that pattern check.

% scp -T fud:'@(raid0|raid1).label' .
raid0.label   100%  894   266.4KB/s   0.9KB/s  
raid1.label   100%  890   305.3KB/s   0.9KB/s  

Unlike the globbing on the remote side, the local check doesn't use the
shell to interpret the pattern. Instead scp itself splits braced sequences
like '{a,b,...}' and calls fnmatch() to handle the parts.

scp is a hack.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."