mail/opensmtpd:
- Update to 5.4.4p1
- Add LIBASRDEVEL option to depend on dns/libasr-devel
- Use OpenSSL from ports, should help with migration to LibreSSL
- Explicitly provide path to OpenSSL[1]
mail/opensmtpd-devel:
- Update to 201502012312
- Add LIBASR option to depend on dns/libasr
- Remove MYSQL, PGSQL, LDAP, and REDIS options as they're removed
upstream
- Add a note for above to UPDATING
- Explicitly provide path to OpenSSL[1]
- Add a diff to fix build failure on FreeBSD[2]
Reported by: TJ <tj at mrsk.me> (via private email)
Submitted by: Herbert J. Skuhra <herbert at oslo.ath.cx> (via list)
"Revert the change from readline to libedit, and instead make libedit optional.",
I failed to get the PORTREVISION set correctly. Fixed now.
PR: ports/197362
libasr is a FREE asynchronous DNS resolver.
libasr runs on top of the OpenBSD operating system but also has a portable
version that can build and run on several systems, including:
* Linux
* FreeBSD
* NetBSD
* DragonFly
* MacOSX
This port packages the development snapshots released by OpenSMTPD team.
WWW: https://github.com/OpenSMTPD/libasr
libasr is a FREE asynchronous DNS resolver.
libasr runs on top of the OpenBSD operating system but also has a portable
version that can build and run on several systems, including:
* Linux
* FreeBSD
* NetBSD
* DragonFly
* MacOSX
WWW: https://github.com/OpenSMTPD/libasr
- Unbreak
- Pass maintainership to submitter
- Add LICENSE(LGPL20 GPLv2)
- Remove OPTIONS LIBRARY to make default as most of the dependent ports
require the library
- Make proper use of OPTIONSNG to declutter ${PORT_OPTIONS:M*}
PR: 196942
Differential Revision: https://reviews.freebsd.org/D1795
Submitted by: mp39590@gmail.com
Approved by: marino(mentor)
When dougb released the port, he also reset the MASTER_SITES. It has
been pulling off the cache ever since. If the cache gets cleared, this
port would break. I've moved the distfiles to my LOCAL site so this
never happens.
The other big change is to remove this hacky dependency logic. Someone
tried to select between gnupg and gnupg1 depending on what was already
installed. For the standard packages builders, this meant the port always
used the old gnupg1 because gnupg was never installed in the clean jail.
As both gnupg packages are range between 1.0M and 1.5M in size and can
coexist, the savings of resources in miniscule assuming they weren't both
installed anyway. Let's just pick the new gnupg as the unconditional
dependency and remove the hack. Inspired by discussion on PR which
was trying to fix a bug in the hack.
PR: 195426
Submitted by: Trond Endrestol
