Log message:
Add SHA512 digests for distfiles for sysutils category

Problems found with existing digests:
	Package memconf distfile memconf-2.16/memconf.gz
	b6f4b736cac388dddc5070670351cf7262aba048 [recorded]
	95748686a5ad8144232f4d4abc9bf052721a196f [calculated]

Problems found locating distfiles:
	Package dc-tools: missing distfile dc-tools/abs0-dc-burn-netbsd-1.5-0-gae55ec9
	Package ipw-firmware: missing distfile ipw2100-fw-1.2.tgz
	Package iwi-firmware: missing distfile ipw2200-fw-2.3.tgz
	Package nvnet: missing distfile nvnet-netbsd-src-20050620.tgz
	Package syslog-ng: missing distfile syslog-ng-3.7.2.tar.gz

Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden).  All existing
SHA1 digests retained for now as an audit trail.

Log message:
Update to 1.0.36.1:
OS X lacks the POSIX-mandated clock_gettime function, and tarsnap is
not using libcperciva's "support broken operating systems" compatibility
mechanism yet.  Add -DPOSIXFAIL_CLOCK_REALTIME to the build.

Log message:
Update to 1.0.36:

1. SECURITY FIX: When constructing paths of objects being archived, a buffer
could overflow by one byte upon encountering 1024, 2048, 4096, etc. byte
paths. Theoretically this could be exploited by an unprivileged user whose
files are being archived; I do not believe it is exploitable in practice,
but I am offering a $1000 bounty for the first person who can prove me wrong:
http://www.daemonology.net/blog/2015-08-21-tarsnap-1000-exploit-bounty.html

2. SECURITY FIX: An attacker with a machine's write keys, or with read keys
and control of the tarsnap service, could make tarsnap allocate a large
amount of memory upon listing archives or reading an archive the attacker
created; on 32-bit machines, tarsnap can be caused to crash under the
aforementioned conditions.

3. BUG FIX: Tarsnap no longer crashes if its first DNS lookup fails.

4. BUG FIX: Tarsnap no longer exits with "Callbacks uninitialized" when
running on a dual-stack network if the first IP stack it attempts fails to
connect.

5. tarsnap now avoids opening devices nodes on linux if it is instructed to
archive /dev/.  This change may prevent "watchdog"-triggered reboots.

6. tarsnap -c --dry-run can now run without a keyfile, allowing users to
predict how much Tarsnap will cost before signing up.

7. tarsnap now has bash completion scripts.

8. tarsnap now takes a --retry-forever option.

9. tarsnap now automatically detects and uses AESNI and SSE2.

As usual, there are also many minor build fixes, harmless bug fixes, and code
refactoring / cleanup changes.  For a full listing of changes, consult the
tarsnap git repository: https://github.com/Tarsnap/tarsnap

Log message:
Fix build on SunOS (needs explicit -lnsl).

Log message:
Update to 1.0.35:

Changes since version 1.0.34:

   A bug in tarsnap 1.0.34 which could cause tarsnap to crash
   (segmentation fault or bus error) when encountering network
   glitches or outages is fixed.

   When tarsnap encounters "insane" filesystems (procfs and other
   similar synthetic filesystems which are not reasonable to
   archive), it now archives the filesystem mount point but by
   default does not recurse into the filesystem. Previous releases
   (since 1.0.26) did not archive the synthetic filesystem mount
   point.

Changes since version 1.0.33:

   Tarsnap now supports both IPv4 and IPv6.

   Tarsnap is now more resilient against short network glitches
   when it first connects to the Tarsnap server.

   Tarsnap now supports platforms with mandatory structure alignment
   (e.g., ARM OABI).

   Tarsnap now restores terminal settings if killed with ^C while
   reading a password or passphrase.

   Multiple minor bug fixes and cleanups.

Log message:
Bulk build wants openssl

Log message:
Needs zlib

Log message:
Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.

Log message:
Update tarsnap to version 1.0.33.

Changes since version 1.0.32:

	- Tarsnap now caches archive metadata blocks in RAM, typically
	  providing a 5x - 10x speedup and reduction in bandwidth usage
	  in the "fsck" operation and when deleting a large number of
	  archives at once.
	- Tarsnap's internal "chunk" metadata structure is now smaller,
	  providing a ~10% reduction in usage on 32-bit machines and a
	  ~30% reduction in memory usage on 64-bit machines.
	- Tarsnap's --newer* options now correctly descend into old
	  directories in order to look for new files. (But note that
	  tarsnap's snapshotting makes these options unnecessary in
	  most situations.)
	- Multiple minor bug fixes and cleanups.

Changes since version 1.0.31:

	- A bug affecting the handling of the --nodump option on Linux
	  (and in most cases rendering it inoperative) is fixed.
	- A workaround has been added for a compiler bug in OS X 10.7 (Lion).
	- The NetBSD "kernfs" and "ptyfs" filesystems are now excluded
	  from archival by default.

Log message:
Update tarsnap to version 1.0.31.

Changes since version 1.0.30:

	- A race condition in key generation has been fixed which could
	  allow a newly-generated key file to be read by another local
	  user if the key file is being generated in a world-readable
	  directory and the user running tarsnap-keygen has a umask other
	  than 0066.
	- A bug in key generation has been fixed which could allow a
	  newly-generated key file to be read by another local user
	  if they key file is being generated in a world-writable
	  directory (e.g., /tmp).
	- Tarsnap now supports Minix.
	- Tarsnap now ignores blank lines in key files; line-buffers
	  its output (which makes tarsnap --list-archives | foo more
	  responsive); and prints a progress indicator during tarsnap --fsck.
	- Multiple minor bug fixes.