Bug 199298

Summary: [MAINTAINER] dns/knot: Update to 1.6.3
Product: Ports & Packages Reporter: Leo Vandewoestijne <freebsd>
Component: Individual Port(s)Assignee: freebsd-ports-bugs mailing list <ports-bugs>
Status: Closed FIXED    
Severity: Affects Some People CC: brnrd, danfe
Priority: --- Keywords: needs-qa, patch
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198981
Bug Depends on: 199292    
Bug Blocks:    
Attachments:
Description Flags
Knot 1.6.3 - without dnstap
none
knot 1.6.3 - with dnstap
none
update to 1.6.3
freebsd: maintainer-approval+
portlint -AC output
none
poudriere log for 10.1
none
Patch for Makefile
none
Makefile diff for new 1.6.3
none
Revised Makefile for 1.6.3
none
knot upgrade patch again WITH_OPENSSL_PORT as default
freebsd: maintainer-approval+
poudriere log for 9.3
none
poudriere log for 10.1 none

Description Leo Vandewoestijne 2015-04-08 16:20:55 UTC
Created attachment 155341 [details]
Knot 1.6.3 - without dnstap

Earlier today Knot 1.6.3 was released by CZ.NIC

This (approved) patch supersedes PR 198981
Comment 1 Leo Vandewoestijne 2015-04-08 16:24:20 UTC
Created attachment 155342 [details]
knot 1.6.3 - with dnstap

Additional -on condition PR 199292 is committed- dnstap could be enabled.
This (tested) patch does so. So once fstrm is in the ports, this one is prefered.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2015-04-09 05:46:57 UTC
*** Bug 198981 has been marked as a duplicate of this bug. ***
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2015-04-09 05:53:57 UTC
Maintainer, there are two attachments included in this issue which makes it ambiguous for a committer to resolve.

As your intent is to wait for bug 199292 to be committed, such that 'with dnstap' can be enabled, I have set this issue to depend on it.

If you would please set maintainer-approval flag on attachment 155342 [details], and obsolete the other, that would be great.

Please also include (as attachments) portlint -AC and poudriere testport (or bulk -t) QA results.
Comment 4 Leo Vandewoestijne 2015-04-10 14:03:19 UTC
Created attachment 155425 [details]
update to 1.6.3

bug 199292 was committed very rapidly, so by these the (hopefully) final patch that included dnstap and a minor edit.
Comment 5 Leo Vandewoestijne 2015-04-10 14:03:40 UTC
Created attachment 155426 [details]
portlint -AC output
Comment 6 Leo Vandewoestijne 2015-04-10 14:03:50 UTC
Created attachment 155427 [details]
poudriere log for 10.1
Comment 7 Bernard Spil freebsd_committer 2015-04-10 20:06:19 UTC
Created attachment 155433 [details]
Patch for Makefile

Problem with this patch...

===>   knot-1.6.3 depends on shared library: libressl.so - not found

Don't need to specifically depend on LibreSSL, set WITH_OPENSSL_PORT= security/libressl and Mk/bsd.openssl.mk takes care of the SHLIB version. Probably should check on value of WITH_OPENSSL_PORT as well, but security/libressl already conflicts with security/openssl.
Comment 8 Bernard Spil freebsd_committer 2015-04-11 08:55:21 UTC
Created attachment 155451 [details]
Makefile diff for new 1.6.3

Hi Leo,

Problem is that there IS no such thing as libressl.so, security/libressl uses the same installed files as security/openssl does (i.e. /usr/local/lib/libssl.so and /usr/local/lib/libcrypto.so as well as the headers in /usr/local/include/openssl).

This makes the existing Makefile fail the build as it tries to compile/install LibreSSL again whilst it is already installed.

/usr/ports/Mk/bsd.openssl.mk contains all the necessary logic to build/install LibreSSL when WITH_OPENSSL_PORT= security/libressl is defined so all the port needs to do is add that line to pull in LibreSSL. If security/openssl where installed already, the CONFLICTS will trigger a build failure.

To be complete, I don't think that this is the right way for the port to deal with LibreSSL altogether. We should be able to rely on the user setting WITH_OPENSSL_PORT in their configuration and then either disable GOST or use the current IGNORE when it detects GOST is enabled and LibreSSL is configured by the user.

Spotted some more issues... USE_OPENSSL should probably always be defined, even when building with LibreSSL, as well as CONFIGURE_ENV+= --with-openssl=${OPENSSLDIR}
Comment 9 Bernard Spil freebsd_committer 2015-04-11 08:57:12 UTC
Created attachment 155452 [details]
Revised Makefile for 1.6.3

Let me know if you need any additional clarification... I'm on Freenode and EFNet as Barnerd or comment on the patch in my github.com/Sp1l/ports/patches/patch-dns_knot-1.6.3
Comment 10 Leo Vandewoestijne 2015-04-11 17:45:20 UTC
I'm currently suffering vision trouble; and apparently at the finish of installing LibreSSL I had a dyslectic confusion. Then I was testing it the traditional way, and combined with a forgotten `setenv FORCE_PKG_REGISTER` I wasn't getting any of the errors that you got. But (elsewhere) neither poudriere reported it.

Anyway, testing your last revision results in:
make: "/usr/ports/dns/knot/Makefile" line 56: Malformed conditional (${OPENSSL_PORT} == security/libressl)
What would be a better way of detecting LibreSSL here?

Without that check, and having LibreSSL in make.conf, it all installs, but ends up with fatal errors when starting Knot i.c.w. doing DNSSEC auto-signing of zones using GOST keys.

As upstream is trying to solve this in the next release, what would you recommend?
Should we maybe have a little patience, and for now remove the patch?
Although GOST in DNSSEC isn't very widely practiced, I think a DNS operator rather has an error on install, than a silent message in a log.

Also; Knot's roadmap is to use GnuTLS per 2.0, because of hardware support and smartcards. Actually this is already the case per 1.99.1 (a devel release).
Comment 11 Bernard Spil freebsd_committer 2015-04-11 20:03:50 UTC
(In reply to Leo Vandewoestijne from comment #10)
That type of error neeeeeeever happens to me :D
Probably because it is empty for you?
Try a "${OPENSSL_PORT}" or ""${OPENSSL_PORT} perhaps? Hadn't tested without OPENSSL_PORT set, sorry.

For now this is mostly convenience. By now PC-BSD and OPNSense are releasing LibreSSL builds so this would ease the effort of fixing up the builds there at the expense of managing these patches in our ports tree.
I do/will upstream all that I do to patch ports with LibreSSL but that's a time-consuming task!

Additionally there are plans to force all ports to use ports' OpenSSL, not sure about a timescale just yet but I believe it's better be prepared than confronted.
Comment 12 Leo Vandewoestijne 2015-04-12 02:14:03 UTC
Created attachment 155490 [details]
knot upgrade patch again WITH_OPENSSL_PORT as default

In that case, this should be it.
Comment 13 Leo Vandewoestijne 2015-04-12 02:15:46 UTC
Created attachment 155491 [details]
poudriere log for 9.3
Comment 14 Leo Vandewoestijne 2015-04-12 02:16:31 UTC
Created attachment 155492 [details]
poudriere log for 10.1
Comment 15 commit-hook freebsd_committer 2015-04-13 17:43:48 UTC
A commit references this bug:

Author: danfe
Date: Mon Apr 13 17:43:15 UTC 2015
New revision: 383940
URL: https://svnweb.freebsd.org/changeset/ports/383940

Log:
  - Update to version 1.6.3; remove "foo is" from COMMENT text
  - Move bison(1) from BUILD_DEPENDS to USES
  - Register CONFLICTS with knot-devel-1.*
  - Enable compiler messages in batch (package building) mode
  - Add new options (DNSTAP, GOST, LMDB)
  - Rename IDNA option to our standard (shared) IDN
  - Allow to build against `security/libressl' as OPENSSL_PORT
  - Switch to using @sample keyword for knot.sample.conf
  - Sort pkg-plist and reformat pkg-descr while I'm at it
  - Update files/pkg-message.in to include instructions for both new
    and legacy rc systems (e.g. FreeBSD 8.4 has service(8), but no
    sysrc(8) utility)

  PR:		199298
  Submitted by:	maintainer

Changes:
  head/dns/knot/Makefile
  head/dns/knot/distinfo
  head/dns/knot/files/patch-src_libknot_dnssec_config.h
  head/dns/knot/files/pkg-message.in
  head/dns/knot/pkg-descr
  head/dns/knot/pkg-plist
Comment 16 Alexey Dokuchaev freebsd_committer 2015-04-13 17:46:03 UTC
Committed as ports r383940, with several changes to make the port adhere to FreeBSD standards more closely and minor style nits, thank you!