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

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

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

py-zbase32: removed

*: bump PKGREVISION for egg.mk users

They now have a tool dependency on py-setuptools instead of a DEPENDS

multiple: Update MAINTAINER from gdt@ir.bbn.com

Changed PYTHON_VERSIONS_INCOMPATIBLE to PYTHON_VERSIONS_ACCEPTED; needed for future Python 3.8

fix some whitespace, mostly introduced in the previous
python 3.4 / 3.5 removal commit.

Omit mentions of python 34 and 35, after those were removed.

- Includes some whitespace changes, to be handled in a separate commit.

extend PYTHON_VERSIONS_ for Python 3.7

Follow some redirects.

Add python-3.6 to incompatible versions.

Remove python33: adapt all packages that refer to it.

Switch to MASTER_SITES_PYPI.

Extend PYTHON_VERSIONS_INCOMPATIBLE to 35

Mark packages that are not ready for python-3.3 also not ready for 3.4,
until proven otherwise.

Update to 1.1.5, changes not found.

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

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.

fix typo in maintainer

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