- support for newer Python versions
- various bug fixes and security improvements
- moved from LGPL to MIT license
Based on the update by Christian Sturm in wip with additional fixes from
me.
- 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.
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
/usr/pkg/include and /usr/include can appear in any order, PREFIX can be
!= /usr/pkg.
XXX Why this hack and not split + filter to remove the include pathes?
python*-pth packages into meta-packages which will install the non-pth
packages. Bump PKGREVISIONs on the non-pth versions to propagate the
thread change, but leave the *-pth versions untouched to not affect
existing installations.
Sync all PYTHON_VERSIONS_AFFECTED lines in package Makefiles.
in PR 25573, with some cleanup by me.
Mixminion is a communication security application for electronic mail
messages. Its purpose is to deny an adversary the ability to
determine who is communicating with whom and to provide the closely
related service of anonymous communication.
It does this by sending messages through a series of servers.
Messages going into and out of each server are encrypted. Each server
keeps a pool of messages. When a message comes in it is placed in the
pool. Messages sent out from the pool are difficult to correlate with
the messages going in. This process is called "mixing."
Each server reduces the ability of the adversary to determine the
origin of a message. Chaining the servers further reduces this
ability and contains the damage caused by compromised servers. The
chain of servers is chosen by the Mixminion software running on the
user's machine.
See http://mixminion.net for a complete description.
