pkgsrc - [no description]

Age	Commit message (Collapse)	Author	Files	Lines
2016-03-05	Bump PKGREVISION for security/openssl ABI bump.	jperkin	1	-2/+2

2015-12-05	Extend PYTHON_VERSIONS_INCOMPATIBLE to 35	adam	1	-2/+2

2015-11-04	Add SHA512 digests for distfiles for security category	agc	1	-1/+2
	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.
2014-05-09	Mark packages that are not ready for python-3.3 also not ready for 3.4,	wiz	1	-2/+2
	until proven otherwise.
2014-02-12	Recursive PKGREVISION bump for OpenSSL API version bump.	tron	1	-2/+2

2014-01-21	Convert to distutils.mk. Mark as not for python-3.x.	wiz	2	-7/+6
	Bump PKGREVISION.
2013-02-16	Fix incorrect expansion (use PYPKGPREFIX instead of hardcoded py27)	wiz	1	-2/+2

2013-02-06	PKGREVISION bumps for the security/openssl 1.0.1d update.	jperkin	2	-4/+4

2012-10-23	Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.	asau	1	-3/+1

2012-05-07	Set BUILDLINK_ABI_DEPENDS correctly (with +=, not ?=)	dholland	1	-2/+2
	It turns out there were a lot of these.
2012-04-08	Remove python24 and all traces of it from pkgsrc.	wiz	1	-2/+1
	Remove devel/py-ctypes (only needed by and supporting python24). Remove PYTHON_VERSIONS_ACCEPTED and PYTHON_VERSIONS_INCOMPATIBLE lines that just mirror defaults now. Miscellaneous cleanup while editing all these files.
2011-10-14	Allow to accept any Python-2.x.	obache	1	-2/+2

2010-01-17	Recursive PKGREVISION bump for jpeg update to 8.	wiz	2	-4/+4

2009-03-20	Simply and speed up buildlink3.mk files and processing.	joerg	1	-13/+6
	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-02-11	Don't use text relocations, link against shared libcrypto.	joerg	3	-12/+21
	DESTDIR support. Simplify. Bump revision.
2008-04-25	Fix DEPENDS for Python 2.5.	tnn	1	-2/+2

2008-04-25	Don't hardcode PYPKGPREFIX in bl3.mk	tnn	1	-11/+11

2008-04-25	Update PYTHON_VERSIONS_COMPATIBLE	joerg	1	-2/+2
	- 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.
2008-01-18	Per the process outlined in revbump(1), perform a recursive revbump	tnn	2	-2/+4
	on packages that are affected by the switch from the openssl 0.9.7 branch to the 0.9.8 branch. ok jlam@
2007-05-05	Initial import of py-SSLCrypto-0.1.1 into the Packages Collection.	agc	5	-0/+74
	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.