Log message:
Recursive PKGREVISION bump for jpeg update to 8.

Log message:
Simply and speed up buildlink3.mk files and processing.
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.

Log message:
Don't use text relocations, link against shared libcrypto.
DESTDIR support. Simplify. Bump revision.

Log message:
Fix DEPENDS for Python 2.5.

Log message:
Don't hardcode PYPKGPREFIX in bl3.mk

Log message:
Update PYTHON_VERSIONS_COMPATIBLE
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.

Log message:
Per the process outlined in revbump(1), perform a recursive revbump
on packages that are affected by the switch from the openssl 0.9.7
branch to the 0.9.8 branch. ok jlam@

Log message:
Initial import of py-SSLCrypto-0.1.1 into the Packages Collection.

	SSLCrypto is a package for Python that dramatically eases the task of
	adding encryption to Python programs.

	It provides a unified API that is almost totally compatible with that
	of ezPyCrypto, except that it takes advantage of the OpenSSL Crypto
	Library to deliver massive improvements in speed and security.

	After using ezPyCrypto myself, I found that while it performed ok with
	smaller public key sizes, it proved impossibly slow with larger keys.
	This slowness, resulting from non-optimal code in its backend (the
	Python Cryptography Toolkit) meant that on a 1.5 GHz Athlon XP, it was
	taking several minutes to generate 4096-bit keys.  Completely
	unacceptable if you need real security.

	Performance is absolutely critical for an encryption API.  If slowness
	deters people from using adequate-sized keys, security will be
	severely compromised, almost to the extent that there's little point
	in using encryption in the first place.