Commit graph

8 commits

Author SHA1 Message Date
wiz
48ead00e71 Fix incorrect expansion (use PYPKGPREFIX instead of hardcoded py27) 2013-02-16 12:07:26 +00:00
jperkin
becd113253 PKGREVISION bumps for the security/openssl 1.0.1d update. 2013-02-06 23:20:50 +00:00
dholland
7e751949e4 Set BUILDLINK_ABI_DEPENDS correctly (with +=, not ?=)
It turns out there were a lot of these.
2012-05-07 01:53:12 +00:00
wiz
579796a3e5 Recursive PKGREVISION bump for jpeg update to 8. 2010-01-17 12:02:03 +00:00
joerg
2d1ba244e9 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.
2009-03-20 19:23:50 +00:00
tnn
29075003c4 Don't hardcode PYPKGPREFIX in bl3.mk 2008-04-25 22:16:20 +00:00
tnn
ad6ceadd25 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@
2008-01-18 05:06:18 +00:00
agc
72f70f2fc6 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.
2007-05-05 00:03:54 +00:00