CVS log for pkgsrc/converters/py-zbase32/Attic/distinfo

Up to [cvs.NetBSD.org] / pkgsrc / converters / py-zbase32

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

py-zbase32: removed

converters: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes

converters: Remove SHA1 hashes for distfiles

Add SHA512 digests for distfiles for converters category

Problems found with existing distfile:
	distfiles/libiconv-1.13-cp932.patch.gz
No changes made to the libiconv distinfo file.

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.

Update to 1.1.5, changes not found.

Update converters/zbase32 to 1.1.3.

pkgsrc changes:
- /usr/bin/env python is no longer valid as an interpreter.

upstream changes:

Unknown.

Add patch to avoid trying to fetch setuptools-darcs.

Import py26-zbase32-1.1.2 as converters/py-zbase32.

An alternate base32 encoder (not RFC 3548 compliant).

The rationale for base-32 encoding in RFC 3548 [1] is as written therein: "The
Base 32 encoding is designed to represent arbitrary sequences of octets in a
form that needs to be case insensitive but need not be humanly readable.".

The rationale for our encoding is different -- it is to represent arbitrary
sequences of octets in a form that is as convenient as possible for human
users to manipulate.  In particular, z-base-32 was created in order to serve
the Mnet project [3], where 30-octet cryptographic values are encoded into
URIs for humans to manipulate.  Anticipated uses of these URIs include cut-
and-paste, text editing (e.g. in HTML files), manual transcription via a
keyboard, manual transcription via pen-and-paper, vocal transcription over
phone or radio, etc.

The desiderata for such an encoding are:

 * minimizing transcription errors -- e.g. the well-known problem of confusing
   `0' with `O'
 * embedding into other structures -- e.g. search engines, structured or
   marked-up text, file systems, command shells
 * brevity -- Shorter URLs are better than longer ones.
 * ergonomics -- Human users (especially non-technical ones) should find the
   URIs as easy and pleasant as possible.  The uglier the URI looks, the worse.

Initial revision