Problems found locating distfiles:
Package f-prot-antivirus6-fs-bin: missing distfile fp-NetBSD.x86.32-fs-6.2.3.tar.gz
Package f-prot-antivirus6-ws-bin: missing distfile fp-NetBSD.x86.32-ws-6.2.3.tar.gz
Package libidea: missing distfile libidea-0.8.2b.tar.gz
Package openssh: missing distfile openssh-7.1p1-hpn-20150822.diff.bz2
Package uvscan: missing distfile vlp4510e.tar.Z
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.
either because they themselves are not ready or because a
dependency isn't. This is annotated by
PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z
or
PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar
respectively, please use the same style for other packages,
and check during updates.
Use versioned_dependencies.mk where applicable.
Use REPLACE_PYTHON instead of handcoded alternatives, where applicable.
Reorder Makefile sections into standard order, where applicable.
Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default
with the next commit.
Whitespace cleanups and other nits corrected, where necessary.
Upstream's version is 0.6.0.X, where X appears to be a large integer
in decimal that corresponds to a git sha1 has. Such large numbers
violate the assumption, true with just about every previous package,
that version number components will fit in an int --- code that
handles version numbers does not use a multiprecision integer library
like gmp. To address this, split the version into what would have
been the version under normal procedures (0.6.0), and put the bignum
into ${VERSION_EXCESSIVE}, allowing it be used in DISTNAME but not
PKGNAME.
(Yes, that ridiculous version number really is what upstream calls it.)
No NEWS entry, but announcement includes:
2012-03-13 Zooko Wilcox-O'Hearn <zooko@zooko.com>
* src/pycryptopp/_version.py: release pycryptopp-0.6.0
* add Ed25519 signatures (#75)
* add XSalsa20 cipher (#40)
* switch from darcs to git for revision control
* pycryptopp version numbers now include a decimal encoding of *
* reorganize the source tree and the version number generation
* aesmodule.cpp: validate size of IV and throw exception if it
is not 16 (#70)
* fixed compile errors with gcc-4.7.0 (#78)
* fixed compile errors concerning "CryptoPP::g_nullNameValuePairs" (#77)
* suppress warnings from valgrind with new OpenSSL 1.0.1 on Fedora (#82)
* raise Python exception instead of uncaught C++ exception
(resulting in abort) when deserializing malformed RSA keys (#83)
Upstream changes:
Not complete, the only info mentionned in the Changelog is this:
2011-01-16 -- pycryptopp v0.5.28
re-enable the ECDSA module, but please do not rely on it as it is expected to
change in backwards-incompatible ways in future releases several changes to the
build system to make it tidier and less error-prone -- see revision control
history for details
2010-09-20 -- pycryptopp v0.5.25
* make setup backwards-compatible to Python 2.4
* fix incompatibilities between setup script and older versions of darcsver
* don't attempt to compile Mac OS X extended attribute files (this fixes the build breaking)
* include a version number of the specific version of Crypto++ in extraversion.h
* small changes to docs
2010-09-18 -- pycryptopp v0.5.20
* fix bugs in assembly implementation of SHA-256 from Crypto++
* fix it to compile on *BSD (#39)
* improve doc strings
* add a quick start-up-self-test of SHA256 (#43)
* execute the quick start-up-self-tests of AES and SHA256 on module import
While one would expect a python wrapper for a library to link with the
library, this packages's source has files from crypto++, and it
doesn't try to link against the installed crypto++.
