2017-09-04 20:08:18 +02:00
|
|
|
# $NetBSD: Makefile,v 1.12 2017/09/04 18:08:19 wiz Exp $
|
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.
2010-07-24 19:56:26 +02:00
|
|
|
|
2014-01-19 23:22:56 +01:00
|
|
|
DISTNAME= zbase32-1.1.5
|
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.
2010-07-24 19:56:26 +02:00
|
|
|
PKGNAME= ${PYPKGPREFIX}-${DISTNAME}
|
|
|
|
|
CATEGORIES= converters
|
2016-06-08 19:43:20 +02:00
|
|
|
MASTER_SITES= ${MASTER_SITE_PYPI:=z/zbase32/}
|
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.
2010-07-24 19:56:26 +02:00
|
|
|
|
2010-08-01 07:44:07 +02:00
|
|
|
MAINTAINER= gdt@ir.bbn.com
|
2017-09-04 20:08:18 +02:00
|
|
|
HOMEPAGE= https://pypi.python.org/pypi/zbase32/
|
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.
2010-07-24 19:56:26 +02:00
|
|
|
COMMENT= Alternate base32 encoder (not RFC 3548 compliant)
|
|
|
|
|
LICENSE= modified-bsd
|
|
|
|
|
|
2012-02-12 21:02:53 +01:00
|
|
|
REPLACE_INTERPRETER+= python
|
|
|
|
|
REPLACE.python.old= /usr/bin/env python
|
|
|
|
|
REPLACE.python.new= ${PYTHONBIN}
|
|
|
|
|
REPLACE_FILES.python= zbase32/zbase32.py zbase32/test/test_zbase32.py
|
|
|
|
|
|
2017-01-01 15:43:22 +01:00
|
|
|
PYTHON_VERSIONS_INCOMPATIBLE= 34 35 36 # not yet ported as of 1.1.5
|
2014-01-19 23:22:56 +01:00
|
|
|
|
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.
2010-07-24 19:56:26 +02:00
|
|
|
.include "../../lang/python/egg.mk"
|
|
|
|
|
.include "../../mk/bsd.pkg.mk"
|
