Pull up following revision(s) (requested by taca in ticket #132):
	sys/kern/uipc_usrreq.c: revision 1.172
Make behavior of getsockname(2) (and maybe getpeername(2)) as the same as
NetBSD 6.1_STABLE and other operating system (OS X 10.9.5).
* sa_len of sockaddr_un strucrure is always set to sizeof(sun_path).
* pathname stored in sun_path is alwasys '\0' terminated (except length
  of sun_path is sizeof(sun_path)?).
Should be fix PR kern/49247, runtime problem of lmtp service of dovecot2 on
NetBSD current and NetBSD 7.0_BETA.
Pull up following revision(s) (requested by christos in ticket #133):
	external/bsd/dhcp/Makefile.inc: revision 1.12
The crypto-enabled dhclient command needs more libraries burned in so that
it does not depend on /usr/lib
Pull up following revision(s) (requested by manu in ticket #134):
	lib/libperfuse/ops.c: revision 1.75
Do not trust the filesystem's readdir to give us nul-terminated file
names
Pull up following revision(s) (requested by apb in ticket #135):
	tests/lib/libutil/t_parsedate.c: revision 1.8
Add local parsecheck() function and use it for several tests.
Instead of just checking that parsedate(3) does not return an error,
also pass the result through localtime_r(3) or gmtime_r(3) and check the
year/month/day/hour/minute/second fields in the resulting struct tm.
Pull up following revision(s) (requested by apb in ticket #135):
	tests/lib/libutil/t_parsedate.c: revision 1.9
Add comments for some non-obvious cases.
Also add a test with year=70, which is documented to be treated as 1970.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.y: revision 1.17
Some years don't need the "maybe add 1900 or 2000" adjustment
that was designed for handling two-digit abbreviated years.
For example, "1/2/70" still refers to the year 1970, as before,
but "70-01-02" now refers to the year 70.
* Add a new yyHaveFullYear member to struct dateinfo, to record whether
  or not the year needs to be adjusted.
* Code that parses years sets yyHaveFullYear=1 if they know that the
  year should not be adjusted (as is the case for ISO 8601 dates), or if
  they perform their own adjustment (as is the case for CVS timestamps).
* Move the year adjustment code into a new function, AdjustYear,
  instead of inline in Convert().
* Make Convert() assume the year doesn't need to be adjusted,
  and make Convert's callers first call AdjustYear() if appropriate.
Pull up following revision(s) (requested by apb in ticket #135):
	tests/lib/libutil/t_parsedate.c: revision 1.10
Adapt to a recent change in parsedate().
"9/10/69" still refers to 2069, and "9/10/70" still refers to 1970,
but "69-09-10" and "70-09-10" now refer to the years 69 and 70.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.3: revision 1.13
Document that years in ISO 8601 dates are taken literally.
"69-09-10" is in the year 69, not 2069.
Pull up following revision(s) (requested by apb in ticket #135):
	tests/lib/libutil/t_parsedate.c: revision 1.11
Add tests for PR lib/47916.  Some of these fail.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.y: revision 1.18
A time like HH:MM:SS.sss says nothing about whether DST is on or off.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.y: revision 1.19
Previously, input of the form "HH:MM:SS +ZZZZ" would not have set the
yyhaveZone flag.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.3: revision 1.14
The tzoff argument is in minutes (behind/west of UTC), not seconds.
While here, also say that time = NULL and tzoff = NULL are independent.
The code doesn't yet implement that, but it will soon.
Pull up following revision(s) (requested by apb in ticket #135.10):
	tests/lib/libutil/t_parsedate.c: revision 1.12
When tests fail, print all args, notjust the date string.
Pull up following revision(s) (requested by apb in ticket #135):
	tests/lib/libutil/t_parsedate.c: revision 1.13
2013-07-09 was in British Summer TIme, so use tzoff=-60, not 0.
Pull up following revision(s) (requested by apb in ticket #135):
	lib/libutil/parsedate.y: revision 1.20
Improved handling of local times.
* A magic value USE_LOCAL_TIME (defined as 99999) may be passed as the
  Timezone to Convert(), instructing it to use mktime() to work
  in the local time zone, instead of using mktime_z to work in UTC
  (and then adding the specified timezone offset).
* Some old code is removed now that there's no need to find the local
  timezone offset.
* Allow either one or both of the now and zone arguments to
  parsedate() to be NULL, treating them independently.  Previously,
  if either one was NULL, the other was ignored.
* If the zone argument is specified, then the current date is calculated
  in the specified zone, not in local time.
Also add some disabled debug code.
This should fix PR lib/47916.
tickets 132-135