Christian Koch | 21 Nov 11:41 2015

MKMAN=no in wrong place for some test programs

Hey everyone,

I am unable to perform a " distribution" with MKMAN=yes because the
process stops in a couple of places like this:

    nbmake[9]: nbmake[9]: don't know how to make h_gai.1. Stop 

I discovered there are at least two test programs whose Makefile specifies
MKMAN=no *before* is imported. They are:


Relocating the "MKMAN=no" bit allows the build to complete for me.  Can we
fix this?


Mouse | 19 Nov 01:45 2015

Re: curses vs non-ASCII

>> "each octet is one character" semantic I want for this application.
> It's a long time since I tought the Perl Curses module to correctly deal wit$

I'm not sure how usefully describe which flavour of curses I'm using
except "the one that comes with 5.2".  Is there something I can look at
that will tell me?

Looking at addbytes.c (which is where all the add-string functions seem
to end up), I see nothing at all to prevent throwing the octet string
at mbrtowc, I think it was, except building without HAVE_WCHAR.

I've since done some build attempts, and this is pretty ridiculous.
First I tried to build with CITRUS=no, to make the library backing the
i18n stuff go away entirely.  That failed - something failed to link (I
forget what).  Then I tried to build with RUNE=no, to make libc's
multibyte support stub itself out despite citrus's presence.  Something
else failed to link (again, I forget what).  Then I tried
DISABLE_WCHAR=yes, to make libcurses not use the wide character stuff.
Then vi failed to link.  Now I'm trying DISABLE_WCHAR=yes (for
libcurses) and USE_WIDECHAR=no (for vi).  If I can't get this to work
within at most a few more iterations I think I'll go back to CITRUS=no
(because that's really what I want here, to make all wide-character
goop go away) and wade in with a code machete on anything that gets
upset by that.

It really seems to me it shouldn't be this hard to use a single-byte
character set like 8859-1 or KOI-8 with curses.  (It's still possible
all I need to do is set something in the environment, but I have no
idea what; the documentation is a maze of pointers without the content
I need and my attempts to USTL foundered on the maze of pointers in the
(Continue reading)

Mouse | 14 Nov 16:13 2015

curses vs non-ASCII

I'm writing a program with a curses(3) interface, and I'm finding that
non-ASCII octets in strings are getting completely lost somewhere
between the addstr()/printw()/etc argument and the display.  (This is
with 5.2 at the moment, but if someone has answers for other versions,
I'd be interested in those too.)

Looking at addbytes.c and checking with nm, I believe the curses I'm
dealing with was built with HAVE_WCHAR (addbytes.o shows a reference to
mbrtowc) and, thus, it is probably multibyte foo that's causing the
trouble.  Also, libc contains multibyte_amd1.o rather than

I have, however, been unable to find any documentation on what I need
to put where in the environment, and/or what API I need to call, to
make this get out of the way and give me the "each octet is one
character" semantic I want for this application.  mbrtowc(3) (as used
by libcurses) says that its behaviour "is affected by the LC_CTYPE
category of the current locale", but I have so far completely failed to
find any documentation on what I need to do to make this work.  nls(7)
seems to imply that setting LC_ALL or LANG might help, but gives only
tiny hints what settings might do what I want.  I tried setting LANG to
en_CA.ISO8859-1 (this guessed based on the da_DK.ISO8859-1 example in
the nls(7) manpage); when that didn't help I instead tried setting
LC_ALL to that same value.  That didn't help either.

If necessary I'll rebuild libcurses with HAVE_WCHAR turned off.  But I
find it hard to believe NetBSD would make it this hard to use
single-byte character sets like ISO 8859-1 or KOI-8, so I am inclined
to assume there's something I'm missing.

(Continue reading)

Emmanuel Dreyfus | 9 Nov 10:58 2015

netbsd-7 kernel and older vnconfig(8)


We have a backward compatibility problem with vnconfig(8). If I use
netbsd-6 vnconfig with netbsd-7 kernel, vnconfig -l loops forever
because src/usr.sbin/vnconfig/vnconfig.c lacks this change:

revision 1.41
date: 2013-06-09 15:25:40 +0200;  author: christos;  state: Exp;  
   lines: +76 -56;  commitid: 0DfyvNbGKtoEuWSw;
branches:  1.41.4;
Now that we grow vnd's dynamically we cannot depend on the kernel returning
ENXIO when we exceed the number of configured vnds, so in the -l case, print
info for all vnds we can find device nodes for in /dev.

I am not sure how it could be fixed.


Emmanuel Dreyfus
manu <at>

Martin Husemann | 6 Nov 20:31 2015

Creating /var/shm as a symlink during startup

I would like to commit the patch below.

It is usefull for memory restricted systems where you only want one tmpfs
(with a single, reasonable small limit) and want to share that tmpfs
for both /tmp and /var/shm.

With the patch, it is as easy as setting


in /etc/rc.conf and making /tmp a tmpfs in /etc/fstab.

Any objections? Better ideas?

Index: share/man/man5/rc.conf.5
RCS file: /cvsroot/src/share/man/man5/rc.conf.5,v
retrieving revision 1.163
diff -u -r1.163 rc.conf.5
--- share/man/man5/rc.conf.5	12 Oct 2015 12:07:24 -0000	1.163
+++ share/man/man5/rc.conf.5	6 Nov 2015 19:26:40 -0000
 <at>  <at>  -55,7 +55,7  <at>  <at> 
-.Dd October 9, 2015
+.Dd November 6, 2015
(Continue reading)

Terry Moore | 4 Nov 03:57 2015

Upgrade to NetBSD 7: no _mandb entry found in man.conf

I just upgraded using the upgrade UI from NetBSD 5.0.1 to NetBSD 7.0

Everything went very well, except that when I try to run apropos, or
makemandb, I get:

$ man -k makemandb
apropos: _mandb entry not found in man.conf
$ makemandb
makemandb: _mandb entry not found in man.conf

I looked at man.conf; there is no entry.

I looked at the manpages for apropos, makemandb, and man, and saw only text
of the form:

(man apropros)
     /etc/man.conf  The location of the Sqlite FTS database can be
                    using the _mandb tag.

(man makemandb)
     /etc/man.conf  The location of the Sqlite FTS database can be
                    using the _mandb tag.

(man man.conf | grep _mandb) gives no output.

So my questions are:
(Continue reading)

David CARLIER | 3 Nov 21:49 2015

new code / small geolocalisation service

Hello all,

I wanted to submit a modest new unix socket service which serves geolocalisation data per ip addresses
request. This service is api agnostic (but only shipped with geoip for the moment so if it gets enough
attraction, ip2location for example might be added as well). For last, a control command line is provided
to connect with the service by command line. Hope it will get some attention.
Brooks Davis | 2 Nov 23:35 2015

varargs bug in libedit

I've commmitted the following to FreeBSD's copy of libedit.  It fixes a
bug in varargs handling in el_get().  It's harmless for most
architectures, but our CHERI architecture turns it into a failure.

-- Brooks

----- Forwarded message from Brooks Davis <brooks <at>> -----

Date: Mon, 2 Nov 2015 22:21:02 +0000 (UTC)
From: Brooks Davis <brooks <at>>
To: src-committers <at>, svn-src-all <at>,
	svn-src-head <at>
Subject: svn commit: r290298 - head/lib/libedit

Author: brooks
Date: Mon Nov  2 22:21:02 2015
New Revision: 290298

  an int, not an int*.

  Sponsored by:	DARPA, AFRL
  Discovered with:	CHERI
  Differential Revision:


(Continue reading)

Kamil Rytarowski | 29 Oct 03:41 2015

strsuftoi(3), strsuftou(3) proposal in libc

I'm proposing adoption of a new functions in libc:
- strsuftoi(3),
- strsuftou(3),
- their _l counterparts.

Their are built over strtoi(3) and strtou(3), which are part of the
Standard C Library in NetBSD-7.0. The only difference between *i and *u
functions is operating over signed or unsigned values.

These functions take exactly the same arguments as strtoi(3) and
strtou(3), just they return different status values and they can handle
multiplication of products in nptr.

strsuftoi(const char * restrict nptr, char ** restrict endptr, int base,
         intmax_t lo, intmax_t hi, int *rstatus);

The strsuftoi() function converts the string in nptr to an intmax_t
value.  Two or more numbers may be separated by an ``x'' or ``*'' to
indicate a product.

Each number may have one of the following optional suffixes:

      b    Block; multiply by 512
      k    Kibi; multiply by 1024 (1 KiB)
      m    Mebi; multiply by 1048576 (1 MiB)
      g    Gibi; multiply by 1073741824 (1 GiB)
      t    Tebi; multiply by 1099511627776 (1 TiB)
      p    Pebi; multiply by 1125899906842624 (1 PiB)
      e    Exbi; multiply by 1152921504606846976 (1 EiB)
(Continue reading)

Martin Husemann | 25 Oct 20:17 2015

Ownership of ugen usb devices

Hey folks,

while investigation possible solutions for PR 50340 (can't use uscanner*
any more since the last sane-backends update), I thought about options
to chown only a subset of usb devices to the current user owning the
console, the idea is to pass things like scanners and epass/yubikey
over, but not arbitrary devices happening to be connected via usb.

Of course this is an admin decision and needs to be local configurable.
Idealy it should be simple pattern list in /etc, but I did not get quite

This all is important if you want to run tools like xsane (that can not
run as root in any sane X config, but would need root to access the
scanner device nodes). With uscannner* it was simple to chown only the
uscanner* device nodes, but if you do not want that for all ugen* devices,
it becomes tricky.

The stuff attached depends on a (yet uncommited) patch by Jared to add
a -x option to usbdevs, which acts like this:

# usbdevs -x ugen0
ugen0 product=0x0001 vendor=0x055f rev=1.00

With this output it is easy to match the devices we are interested in.
So I created three scripts:

	this one gets the devices description and decides whether to
	chwon to the user or not. Idealy it would read a list file,
(Continue reading)

Niclas Rosenvik | 24 Oct 19:42 2015

aligned_alloc c11 function

Hi, I have already discussed this with other NetBSD developers 
but to make it public I wanted to send a mail to tech-userland.
I will commit this if no one objects in 24 hours.

Niclas Rosenvik

New file

/* $NetBSD$ */

 * Copyright (C) 2015 The NetBSD Foundation, Inc.
 * All rights reserved.
 * This code is derived from software contributed to The NetBSD
 * by Niclas Rosenvik.
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice(s), this list of conditions and the following disclaimer as
 *    the first lines of this file unmodified other than the possible
 *    addition of one or more copyright notices.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice(s), this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
(Continue reading)