Re: net/kea: 1.2.0

[Patrik Lundin]

On Sun, Aug 27, 2017 at 11:19:44AM +0100, Stuart Henderson wrote:
> On 2017/08/27 12:07, Patrik Lundin wrote:
> > On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> > > 
> > > Since there have been no further feedback, is there a chance the latest
> > > diff can get commited?
> > > 
> > 
> > Ping.
> 
> The COMPILER infrastructure changed in the meantime, I'm leaving it building
> now and should be able to pick it up later today.
> 

I saw the commit, thank you Stuart :).

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Stuart Henderson]

On 2017/08/27 12:07, Patrik Lundin wrote:
> On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> > 
> > Since there have been no further feedback, is there a chance the latest
> > diff can get commited?
> > 
> 
> Ping.

The COMPILER infrastructure changed in the meantime, I'm leaving it building
now and should be able to pick it up later today.

Re: net/kea: 1.2.0

[Patrik Lundin]

On Sat, Aug 12, 2017 at 11:39:14PM +0200, Patrik Lundin wrote:
> 
> Since there have been no further feedback, is there a chance the latest
> diff can get commited?
> 

Ping.

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Patrik Lundin]

On Thu, Aug 03, 2017 at 10:24:00PM +0200, Patrik Lundin wrote:
> 
> Thanks for spotting that. New diff against fresh ports tree below (and
> now portcheck is happy as well).
> 

Since there have been no further feedback, is there a chance the latest
diff can get commited?

-- 
Patrik Lundin

Re: net/kea: 1.2.0

[Patrik Lundin]

Hello Stuart, thanks for the review.

On Thu, Aug 03, 2017 at 06:43:11PM +0100, Stuart Henderson wrote:
> 
> clang is already used as the compiler on i386/amd64/aarch64. Just using
> "COMPILER=clang" means this won't build on some arch which do have c++11
> support from ports gcc.
> 
> For most things "COMPILER=gcc" is generally now the best option for c++11
> ports, this means "build with clang if it's in base, otherwise build with
> ports gcc".
> 

Thank you for the information. I will use "gcc" instead.

> > * Use /var/run/kea instead of /tmp for the UNIX domain control sockets
> >   introduced in 1.2.0.
> 
> Please subst with ${LOCALSTATEDIR} instead of hardcoding /var.
> 

Sorry about that. While using ${LOCALSTATEDIR} directly in the .pre
files does not work, I have used the @localstatedir@ markers instead
(which is used in other places in the files already).

> 
> It's no longer LIBCXX but COMPILER_LIBCXX, which made me spot that your cvs
> diff is against Makefile r1.7 (post-6.1 but pre-current) .. so your ports tree
> (which includes portcheck) needs an update.
> 

Thanks for spotting that. New diff against fresh ports tree below (and
now portcheck is happy as well).

I also noticed something I had missed in the configure output previously:
===
./configure[16315]: test: >: unexpected operator/operand
===

I opened a PR for that:
https://github.com/isc-projects/kea/pull/53

I dont feel that warrants a port patch though as I don't think the
outcome matters on OpenBSD.

-- 
Patrik Lundin

Index: Makefile
===
RCS file: /cvs/ports/net/kea/Makefile,v
retrieving revision 1.9
diff -u -p -u -r1.9 Makefile
--- Makefile26 Jul 2017 22:45:27 -  1.9
+++ Makefile3 Aug 2017 20:17:26 -
@@ -2,29 +2,30 @@
 
 COMMENT=   high-performance and extensible DHCP server engine from ISC
 
-VERSION=   1.1.0
+VERSION=   1.2.0
 
 DISTNAME=  kea-${VERSION}
 PKGNAME=   ${DISTNAME:S/-P/pl/}
-REVISION=  0
 
 SHARED_LIBS +=  kea-asiodns   0.0 # 0.0
-SHARED_LIBS +=  kea-asiolink  1.0 # 3.0
-SHARED_LIBS +=  kea-cc0.0 # 1.0
-SHARED_LIBS +=  kea-cfgclient 0.1 # 2.1
-SHARED_LIBS +=  kea-cryptolink0.0 # 1.0
-SHARED_LIBS +=  kea-dhcp++1.0 # 4.1
-SHARED_LIBS +=  kea-dhcp_ddns 0.1 # 1.1
-SHARED_LIBS +=  kea-dhcpsrv   1.0 # 6.0
-SHARED_LIBS +=  kea-dns++ 0.0 # 2.0
-SHARED_LIBS +=  kea-eval  1.0 # 4.0
+SHARED_LIBS +=  kea-asiolink  2.0 # 4.0
+SHARED_LIBS +=  kea-cc1.0 # 2.0
+SHARED_LIBS +=  kea-cfgclient 1.0 # 3.0
+SHARED_LIBS +=  kea-cryptolink1.0 # 2.0
+SHARED_LIBS +=  kea-dhcp++2.0 # 5.0
+SHARED_LIBS +=  kea-dhcp_ddns 0.2 # 1.2
+SHARED_LIBS +=  kea-dhcpsrv   2.0 # 7.0
+SHARED_LIBS +=  kea-dns++ 1.0 # 1.1
+SHARED_LIBS +=  kea-eval  2.0 # 5.0
 SHARED_LIBS +=  kea-exceptions0.0 # 0.0
-SHARED_LIBS +=  kea-hooks 1.0 # 2.0
-SHARED_LIBS +=  kea-log   1.0 # 2.0
+SHARED_LIBS +=  kea-hooks 2.0 # 3.0
+SHARED_LIBS +=  kea-http  0.0 # 0.0
+SHARED_LIBS +=  kea-log   2.0 # 3.0
+SHARED_LIBS +=  kea-process   0.0 # 0.0
 SHARED_LIBS +=  kea-stats 0.0 # 1.0
 SHARED_LIBS +=  kea-threads   1.0 # 1.0
 SHARED_LIBS +=  kea-util-io   0.0 # 0.0
-SHARED_LIBS +=  kea-util  1.0 # 2.0
+SHARED_LIBS +=  kea-util  1.1 # 2.1
 
 CATEGORIES=net
 
@@ -50,6 +51,9 @@ CONFIGURE_ARGS+= --with-openssl=/usr \
  --with-boost-lib-dir=${LOCALBASE}/lib
 
 LIBTOOL_FLAGS= --tag=disable-static
+
+# configure: error: std::unique_ptr (a C++11 feature) is not supported
+COMPILER= gcc
 
 FLAVORS=   mysql postgresql
 FLAVOR?=
Index: distinfo
===
RCS file: /cvs/ports/net/kea/distinfo,v
retrieving revision 1.3
diff -u -p -u -r1.3 distinfo
--- distinfo13 Nov 2016 14:58:18 -  1.3
+++ distinfo3 Aug 2017 20:17:26 -
@@ -1,2 +1,2 @@
-SHA256 (kea-1.1.0.tar.gz) = w9l67k+qGWU//m0355fi+/YyEkzQuYu1Avm5e1o4PC0=
-SIZE (kea-1.1.0.tar.gz) = 4934875
+SHA256 (kea-1.2.0.tar.gz) = ItFZRbE2ALVsNyE3l8ofPumFHmEZEgrq4IAzxMxS0Sk=
+SIZE (kea-1.2.0.tar.gz) = 5720941
Index: patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
===
RCS file: patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
diff -N patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in
--- patches/patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in 28 Feb 2017 
08:57:12 -  1.1
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,12 +0,0 @@
-$OpenBSD: patch-src_bin_dhcp4_tests_dhcp4_process_tests_sh_in,v 1.1 2017/02/28 

Re: net/kea: 1.2.0

[Stuart Henderson]

On 2017/08/03 19:12, Patrik Lundin wrote:
> * Start using clang as the compiler. Kea 1.2.0 requires C++11 support.
>   With the clang work taking place in base I noticed espie@ had already
>   added a patch for a clang build breaking problem. This has been reported and
>   fixed upstream for later editions:
>   
> https://github.com/isc-projects/kea/commit/75691636ab9421297cfc353b0954aa2e8c82

clang is already used as the compiler on i386/amd64/aarch64. Just using
"COMPILER=clang" means this won't build on some arch which do have c++11
support from ports gcc.

For most things "COMPILER=gcc" is generally now the best option for c++11
ports, this means "build with clang if it's in base, otherwise build with
ports gcc".

> * Use /var/run/kea instead of /tmp for the UNIX domain control sockets
>   introduced in 1.2.0.

Please subst with ${LOCALSTATEDIR} instead of hardcoding /var.

> I did notice that portcheck is currently complaining:
> ===
> # /usr/ports/infrastructure/bin/portcheck
> in default FLAVOR: stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> in FLAVOR "mysql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> in FLAVOR "postgresql": stdc++ in WANTLIB when gcc4 is in MODULES; run 
> port-lib-depends-check and if stdc++ is still there, check actual build 
> thoroughly, it's broken
> net/kea
> ===
> 
> I believe this is a result of ${LIBCXX} being part of WANTLIB. This is
> not something that has been added by me, so I am unsure what the correct
> solution is. Here is the output of the requested port-lib-depends-check:
> ===
> # make port-lib-depends-check
> 
> kea-1.2.0(net/kea):
> Extra:  stdc++.57
> ===
> 
> Any input on this?

It's no longer LIBCXX but COMPILER_LIBCXX, which made me spot that your cvs
diff is against Makefile r1.7 (post-6.1 but pre-current) .. so your ports tree
(which includes portcheck) needs an update.

> 

Re: net/kea: 1.1.0

[Jeremie Courreges-Anglas]

Patrik Lundin  writes:

> Hello,
>
> See below for an update to net/kea from 1.0.0 to 1.1.0.

Committed, thanks.

[...]

> This also brings up another question of mine: where to place logs.
>
> Currently the default setup creates logs in the following places:
> /var/kea/kea.log
   ^^^
> /var/log/kea-ddns.log
vs ^^^, weird...
> /var/log/kea-dhcp4.log
> /var/log/kea-dhcp6.log
>
> Of course the port does not do anything to setup rotation of these logs. Any
> input how this should be handled?

I guess you could put a newsyslog.conf example in pkg/README.

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: net/kea: 1.1.0

[Patrik Lundin]

On Mon, Oct 10, 2016 at 12:28:58AM +0200, Patrik Lundin wrote:
> Hello,
> 
> See below for an update to net/kea from 1.0.0 to 1.1.0.
> 

Ping.

-- 
Patrik Lundin

Re: net/kea: Ensure base awk is used

[Christian Weisgerber]

On 2016-06-27, Stuart Henderson  wrote:

> ...but there's also this in config.site, which seems incorrect:
>
> ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

If you mean that it should use the full path, then no, it's correct
as is.  Putting /usr/bin/awk there causes build errors, because
some of the autoconf magic that uses ac_cv_prog_AWK can't handle a
full path.

We have:

  config.site:
  ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

  config.no-gawk:
  ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}

Since ac_cv_prog_AWK is already set, the entry in config.no-gawk
is never used.  Instead we want to set ac_cv_path_AWK in config.no-gawk.

I suggest the patch below.  I've had this in the last two amd64
bulk builds.  Yes, here the full path is fine.

OK?

Index: config.no-gawk
===
RCS file: /cvs/ports/infrastructure/db/config.no-gawk,v
retrieving revision 1.1
diff -u -r1.1 config.no-gawk
--- config.no-gawk  12 Dec 2011 10:33:33 -  1.1
+++ config.no-gawk  6 Jul 2016 21:39:46 -
@@ -1,3 +1,3 @@
 # $OpenBSD: config.no-gawk,v 1.1 2011/12/12 10:33:33 jasper Exp $
 # included unless lang/gawk
-ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
+ac_cv_path_AWK=${ac_cv_path_AWK=/usr/bin/awk}
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Helpfully failing test in ./configure

[Patrik Lundin]

On Mon, Jun 27, 2016 at 07:44:07PM +0200, Jeremie Courreges-Anglas wrote:
> Patrik Lundin  writes:
> 
> >
> > This means that the failing "test" can actually be thought of as a
> > feature. It is of course brittle, and will modify the build parameters
> > if someone decides to teach the test builtin about "<" prior to bumping
> > base gcc past 4.5.
> 
> This is a very unlikely scenario.
> 
> > Basically I am just asking for pointers from other porters, anyone have
> > an idea how I should deal with this? Should I bother at all?
> 
> I guess you could just use /bin/test.
> 

I figured that such a gcc version bump is fairly unlikely but I would
rather ask than guess :). Thanks for the input, I'll see what upstream
thinks about the "expr" proposal. If they decide to merge it I will
return with a patch for the port.

-- 
Patrik Lundin

Re: net/kea: Helpfully failing test in ./configure

[Patrik Lundin]

On Mon, Jun 27, 2016 at 07:51:33PM +, Christian Weisgerber wrote:
> On 2016-06-27, Patrik Lundin  wrote:
> 
> > CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> > if test "$CXX_DUMP_VERSION" \< "4.5"; then
> >WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> > fi
> >
> > The error message is thrown because the builtin test does not support
> > the "<" operator (which /bin/test does).
> 
> That's not portable.  POSIX does not specify an operator < for test.
> 
> For a portable solution, use expr(1) instead.
> 

Thanks, that sounds like the most proper way forward. I have opened a PR
against upstream, lets see what they think:
https://github.com/isc-projects/kea/pull/25

I guess the side effect of fixing the check (adding
"-fno-strict-aliasing" to the build even if not strictly needed) is not
really detrimental to the build.

-- 
Patrik Lundin

Re: net/kea: Helpfully failing test in ./configure

[Christian Weisgerber]

On 2016-06-27, Patrik Lundin  wrote:

> CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> if test "$CXX_DUMP_VERSION" \< "4.5"; then
>WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> fi
>
> The error message is thrown because the builtin test does not support
> the "<" operator (which /bin/test does).

That's not portable.  POSIX does not specify an operator < for test.

For a portable solution, use expr(1) instead.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Ensure base awk is used

[Christian Weisgerber]

On 2016-06-27, Stuart Henderson  wrote:

>> That should already be set. Is it not picking up config.site for some reason?
>
> Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea
> is also looking at ac_cv_*path*_AWK.
>
> Perhaps we should add the path variant to config.site then..

In fact, ac_cv_prog_AWK is set in both config.site and again in
config.no-gawk.  That doesn't make sense.

I suspect the intention was to set ac_cv_path_AWK in config.no-gawk.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 21:10, David Coppa wrote:
> On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson  
> wrote:
> 
> > Perhaps we should add the path variant to config.site then..
> 
> It looks like the right approach to me, ok dcoppa@.

These are the relevant ports,

bacula-7.4.0
check-0.10.0
check_mssql_health-1.5.19
clusterit-2.5
djview4-4.10.6
elinks-0.11.7
freedroidrpg-0.16
geda-gaf-1.6.0
kea-1.0.0
lam-6.5.9
latex-mk-1.9.1
lbdb_0.40
libgnome-2.32.1
libgnomecanvas-2.30.3
libgnomeui-2.24.5
libreoffice-5.1.2.2
libsmi-0.4.8
quilt-0.64
xboard-4.8.0

basic diff:

Index: config.no-gawk
===
RCS file: /cvs/ports/infrastructure/db/config.no-gawk,v
retrieving revision 1.1
diff -u -p -r1.1 config.no-gawk
--- config.no-gawk  12 Dec 2011 10:33:33 -  1.1
+++ config.no-gawk  27 Jun 2016 19:32:34 -
@@ -1,3 +1,4 @@
 # $OpenBSD: config.no-gawk,v 1.1 2011/12/12 10:33:33 jasper Exp $
 # included unless lang/gawk
 ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
+ac_cv_path_AWK=${ac_cv_path_AWK=/usr/bin/awk}

...but there's also this in config.site, which seems incorrect:

ac_cv_prog_AWK=${ac_cv_prog_AWK=awk}

Re: net/kea: Ensure base awk is used

[David Coppa]

On Mon, Jun 27, 2016 at 6:26 PM, Stuart Henderson  wrote:

> Perhaps we should add the path variant to config.site then..

It looks like the right approach to me, ok dcoppa@.

ciao!
David

Re: net/kea: Helpfully failing test in ./configure

[Jeremie Courreges-Anglas]

Patrik Lundin  writes:

> Hello,
>
> When looking at the output of ./configure in net/kea I noticed the
> following warning which I have previously missed:
> ===
> ./configure[15929]: test: <: unexpected operator/operand
> ===
>
> The responsible code in the configure script should be this:
> ===
> # gcc 4.4 would emit warnings about breaking strict aliasing rules.
> # See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874
> CXX_DUMP_VERSION=`$CXX -dumpversion | cut -f1-2 -d.`
> if test "$CXX_DUMP_VERSION" \< "4.5"; then
>WARNING_GCC_44_STRICT_ALIASING_CFLAG="-fno-strict-aliasing"
> fi
> ===
>
> The error message is thrown because the builtin test does not support
> the "<" operator (which /bin/test does).
>
> The funny thing is that gcc in base does not seem to suffer from the
> bug that is described in the bug tracker linked above, because the build
> generates no warnings relating to strict-aliasing.
>
> This means that the failing "test" can actually be thought of as a
> feature. It is of course brittle, and will modify the build parameters
> if someone decides to teach the test builtin about "<" prior to bumping
> base gcc past 4.5.

This is a very unlikely scenario.

> Basically I am just asking for pointers from other porters, anyone have
> an idea how I should deal with this? Should I bother at all?

I guess you could just use /bin/test.

-- 
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 17:19, Stuart Henderson wrote:
> On 2016/06/27 18:15, Patrik Lundin wrote:
> > +CONFIGURE_ENV+= ac_cv_path_AWK=awk
> 
> That should already be set. Is it not picking up config.site for some reason?
> 

Oh, it is ac_cv_*prog*_AWK that is getting set, for some reason kea
is also looking at ac_cv_*path*_AWK.

Perhaps we should add the path variant to config.site then..

Re: net/kea: Ensure base awk is used

[Stuart Henderson]

On 2016/06/27 18:15, Patrik Lundin wrote:
> +CONFIGURE_ENV+= ac_cv_path_AWK=awk

That should already be set. Is it not picking up config.site for some reason?

Re: net/kea

[Patrik Lundin]

On Thu, Dec 24, 2015 at 02:53:06AM +, Stuart Henderson wrote:
> 
> I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> to emphasize the slightly random nature of that feed it was followed
> by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> and since I maintain the BIND port I track a few places where ISC are
> likely to announce things.
> 
> http://www.openwall.com/lists/oss-security/2015/12/22/11
> https://www.isc.org/?feed=security-feed
> 

Thanks for the info, I guess it is time to spin up newsbeuter again :).

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
packets with invalid client-id and DUID.") I also added an XXX comment
to remind us to update the license marker for 1.0 because ISC are moving
to the Apache license :'(

I'm still looking for OKs to import if anyone has time to look it over...


On 2015/12/10 09:57, Stuart Henderson wrote:
> On 2015/12/09 20:33, Patrik Lundin wrote:
> > On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> > > On 2015/12/08 23:59, Patrik Lundin wrote:
> > > > I have posted a question to kea-dev regarding this:
> > > > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > > > 
> > > > Let's see how that goes.
> > > 
> > > Good idea.
> > > 
> > 
> > I have recieved a response now. As I do not think there is an
> > overwhelming reason for using Botan I feel it is nicer to skip
> > additional port dependencies and explicitly use our LibreSSL instead.
> > 
> > The question remaining is if the configure flag should be --with-openssl
> > or --with-openssl=/usr. While it seems the configure script will look
> > for the library in an order that starts with /usr, I wonder if it is
> > nicer to be explicit that we want to use the base version (rather than
> > the openssl port for instance).
> > 
> > Attached is a port with the explicit flag set and a shortened
> > LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> > when it is installed. Let me know what you think.
> 
> Either way is OK, I deliberately put the ports version of OpenSSL in a
> directory that is unlikely to be searched by configure. (Unless it uses
> something like the bonkers locate(1) check that freeradius3 uses, but
> I digress...)
> 
> Any OKs to import this version?
> 



kea,4.tgz
Description: application/tar-gz

Re: net/kea

[Landry Breuil]

On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> packets with invalid client-id and DUID.") I also added an XXX comment
> to remind us to update the license marker for 1.0 because ISC are moving
> to the Apache license :'(
> 
> I'm still looking for OKs to import if anyone has time to look it over...

Quickly skimmed through it, only two small remarks:
include/kea/asio/ -> this looks like a partial copy of boost's
boost/asio library ? patched ? copied ? what for ?

bin/message in PLIST seems awfully generic, but luckily it doesnt
conflict with anything in pkglocatedb...

Other than that, looks good to me.

Landry

Re: net/kea

[Patrik Lundin]

On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> packets with invalid client-id and DUID.")
>

Nice catch! I had not seen any word of this release on the kea mailing
lists, how did you notice it?

>
> I also added an XXX comment
> to remind us to update the license marker for 1.0 because ISC are moving
> to the Apache license :'(
> 

I did have this upcoming change noted in the back of my head, but having
an explicit note in the Makefile does makes sense.

-- 
Patrik Lundin

Re: net/kea

[Kenneth Westerback]

On 23 December 2015 at 21:53, Stuart Henderson  wrote:
> On 2015/12/23 14:47, Patrik Lundin wrote:
>> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
>> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
>> > packets with invalid client-id and DUID.")
>> >
>>
>> Nice catch! I had not seen any word of this release on the kea mailing
>> lists, how did you notice it?
>
> I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> to emphasize the slightly random nature of that feed it was followed
> by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> and since I maintain the BIND port I track a few places where ISC are
> likely to announce things.
>
> http://www.openwall.com/lists/oss-security/2015/12/22/11
> https://www.isc.org/?feed=security-feed
>

What would be really  nice is if they described somewhere the
'crafted' packet that was blowing them up. As far as the diff goes
they just wrapped try {} around the code trying to get a client
identifier. So it's kinda unsatisfying as far as figuring out if our
in-tree dhcpd would blow up with a similar packet. :-)

 Ken

Re: net/kea

[Stuart Henderson]

On 2015/12/23 14:47, Patrik Lundin wrote:
> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> > packets with invalid client-id and DUID.")
> >
> 
> Nice catch! I had not seen any word of this release on the kea mailing
> lists, how did you notice it?

I saw it on oss-sec first, then on ISC's security RSS feed (and as if
to emphasize the slightly random nature of that feed it was followed
by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
and since I maintain the BIND port I track a few places where ISC are
likely to announce things.

http://www.openwall.com/lists/oss-security/2015/12/22/11
https://www.isc.org/?feed=security-feed

Re: net/kea

[Stuart Henderson]

On 2015/12/23 22:03, Kenneth Westerback wrote:
> On 23 December 2015 at 21:53, Stuart Henderson  wrote:
> > On 2015/12/23 14:47, Patrik Lundin wrote:
> >> On Wed, Dec 23, 2015 at 11:33:30AM +, Stuart Henderson wrote:
> >> > Updated tar.gz for the 0.9.2-P1 crash fix ("Improved handling of incoming
> >> > packets with invalid client-id and DUID.")
> >> >
> >>
> >> Nice catch! I had not seen any word of this release on the kea mailing
> >> lists, how did you notice it?
> >
> > I saw it on oss-sec first, then on ISC's security RSS feed (and as if
> > to emphasize the slightly random nature of that feed it was followed
> > by release notes for 0.9, 0.9.2-beta and 0.9.2 :-) I read oss-sec anyway,
> > and since I maintain the BIND port I track a few places where ISC are
> > likely to announce things.
> >
> > http://www.openwall.com/lists/oss-security/2015/12/22/11
> > https://www.isc.org/?feed=security-feed
> >
> 
> What would be really  nice is if they described somewhere the
> 'crafted' packet that was blowing them up. As far as the diff goes
> they just wrapped try {} around the code trying to get a client
> identifier. So it's kinda unsatisfying as far as figuring out if our
> in-tree dhcpd would blow up with a similar packet. :-)

See, they learned from Juniper!

Re: net/kea

[Stuart Henderson]

On 2015/12/09 20:33, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> > On 2015/12/08 23:59, Patrik Lundin wrote:
> > > I have posted a question to kea-dev regarding this:
> > > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > > 
> > > Let's see how that goes.
> > 
> > Good idea.
> > 
> 
> I have recieved a response now. As I do not think there is an
> overwhelming reason for using Botan I feel it is nicer to skip
> additional port dependencies and explicitly use our LibreSSL instead.
> 
> The question remaining is if the configure flag should be --with-openssl
> or --with-openssl=/usr. While it seems the configure script will look
> for the library in an order that starts with /usr, I wonder if it is
> nicer to be explicit that we want to use the base version (rather than
> the openssl port for instance).
> 
> Attached is a port with the explicit flag set and a shortened
> LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> when it is installed. Let me know what you think.

Either way is OK, I deliberately put the ports version of OpenSSL in a
directory that is unlikely to be searched by configure. (Unless it uses
something like the bonkers locate(1) check that freeradius3 uses, but
I digress...)

Any OKs to import this version?

Re: net/kea

[Mike]

On 12/8/2015 5:41 PM, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 11:18:53PM +0100, Patrik Lundin wrote:
>>
>> What is picking up botan? I looked at every @bin and @lib with ldd and I
>> can't see anyone referring to that library. What am i missing?
>>
> 
>>From http://kea.isc.org/docs/kea-guide.html#required-software:
> ===
> Kea supports two crypto libraries: Botan and OpenSSL. Only one of them
> is required to be installed during compilation. Kea uses the Botan
> crypto library for C++ (http://botan.randombit.net/), version 1.8 or
> later. As an alternative to Botan, Kea can use the OpenSSL crypto
> library (http://www.openssl.org/). It requires a version with SHA-2
> support. 
> ===
> 
> I realize I do not know which library is preferred from the upstream
> perspective, but using LibreSSL seemed nice (and this is what was choosen on 
> my
> build box).
> 
> On my box the following is seen:
> ===
> # ldd /usr/local/sbin/kea-dhcp4
> [...]
> 1f4847a77000 1f4848045000 rlib 07   0  
> /usr/lib/libcrypto.so.36.1
> [...]
> ===
> 
>>From config.log (after tests for botan have failed):
> ===
> configure:17410: checking for OpenSSL library
> configure:17430: result: yes
> configure:17468: checking OpenSSL version
> configure:17480: result: LibreSSL 2.3.2
> configure:17485: checking support of SHA-2
> configure:17506: c++ -o conftest -O2 -pipe   -DOS_BSD  conftest.cpp  -lcrypto 
> >&5
> configure:17506: $? = 0
> configure:17507: result: yes
> ===
> 
> I can ask upstream what they prefer if there are no strong opinions raised on
> this list.
> 

One of the reasons I am moving back to OpenBSD (now that rtadv and IPv6
forwarding are now supported simultaneously) is due to things like
LibreSSL, and the thought and code quality behind it.

If upstream doesn't have a strong preference, please go to LibreSSL.

thx.

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 11:15:04PM +, Stuart Henderson wrote:
> On 2015/12/08 23:59, Patrik Lundin wrote:
> > I have posted a question to kea-dev regarding this:
> > https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> > 
> > Let's see how that goes.
> 
> Good idea.
> 

I have recieved a response now. As I do not think there is an
overwhelming reason for using Botan I feel it is nicer to skip
additional port dependencies and explicitly use our LibreSSL instead.

The question remaining is if the configure flag should be --with-openssl
or --with-openssl=/usr. While it seems the configure script will look
for the library in an order that starts with /usr, I wonder if it is
nicer to be explicit that we want to use the base version (rather than
the openssl port for instance).

Attached is a port with the explicit flag set and a shortened
LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
when it is installed. Let me know what you think.

-- 
Patrik Lundin


kea,3.tgz
Description: application/tar-gz

Re: net/kea

[Patrik Lundin]

On Wed, Dec 09, 2015 at 08:33:10PM +0100, Patrik Lundin wrote:
> 
> Attached is a port with the explicit flag set and a shortened
> LIB_DEPENDS/WANTLIB list. I have tested that it ignores the use of Botan
> when it is installed. Let me know what you think.
> 

Stuart: It would of course be nice to know if this stops the inclusion of
Botan on your build box as well, just for good measure.

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 07:39:24PM +0100, Patrik Lundin wrote:
> > not a port problem, but "message" is a terrible name for sonething that
> > upstream want to place in a system directory!
> 
> I have mentioned this in my upstream kea-dev thread.
> 

FYI: upstream has created a ticket which aims to rename "message" to
"kea-msg-compiler" based on this input: http://kea.isc.org/ticket/4228

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Mon, Dec 07, 2015 at 09:59:44AM +, Stuart Henderson wrote:
> > 
> > 1. When running "make update-plist" I get the following messages:
> > ===
> > make-plist: Bogus element outside of every prefix: /etc/kea/kea.conf
> > make-plist: Bogus element outside of every prefix: /etc/kea/keactrl.conf
> 
> For these, you can often override a variable in upstream's Makefiles
> in FAKE_FLAGS to install these files to /usr/local/share/examples,
> often named sysconfdir or SYSCONFDIR.
> 
>  it's likely to be similar to this
> 
> FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples/
> 
> pre-install:
> mkdir -p ${PREFIX}/share/examples/bind10/
> 

Some trial and error proved that these were pretty much exactly what was
needed, thanks!

This line is now printed instead, guess I can just ignore it?:
===
make-plist: Bogus element outside of every prefix: /etc/kea
===

> > make-plist: Bogus element outside of every prefix: /etc/rc.d/kea
> 
> Ignore this and handle the rcscript in PLIST manually.
> 

I have noticed that update-plist always removes the rcscript in
PLIST, but reading older threads this seems to be a known problem.

> > make-plist: Bogus element outside of every prefix: /var/kea
> > make-plist: Bogus element outside of every prefix: /var/run/kea
> 
> /var/run is cleared at boot so the /var/run/kea directory needs creating
> in the rcscript. we normally do not include these in plist.
> 

I have removed the PLIST @sample for /var/run/kea, and added an rc_pre()
which creates the directory if it does not exist.

> 
> other comments:
> 
> "@sample /etc/kea/" shoukd use SYSCONFDIR and this plist line is usually
> placed near the files that go in that dir
> 

Fixed.

>
> please order Makefile closer to the section ordering in
> Makefile.template
> 
> the shared libs lines are ok (except want to be earlier in the makefile)
> 

I have done a major reorder of the Makefile to mirror the template.

> the static libs are unlikely to be useful, and the whole port is unlikely
> to work without shared libs, so I'd disable them (probably --disable-static
> in CONFIGURE_ARGS, and SHARED_ONLY=Yes) to save build time
> 

This turned out to be the trickiest part. Adding "--disable-static" to
CONFIGURE_ARGS indeed disabled static libraries according to config.log:
===
configure:12388: checking whether to build static libraries
configure:12392: result: no
===

However, the .a files were still being generated by the build.

After digging around I found out about LIBTOOL_FLAGS and added
"LIBTOOL_FLAGS=  --tag=disable-static" and this made the .a files
disappear.

Using LIBTOOL_FLAGS it does not seem to matter if CONFIGURE_ARGS are set
or not, should I use both for good measure or only LIBTOOL_FLAGS? Is
this expected behaviour?

> not a port problem, but "message" is a terrible name for sonething that
> upstream want to place in a system directory!

I have mentioned this in my upstream kea-dev thread.

Attached is the updated port, which only uses LIBTOOL_FLAGS to disable
the static libraries.

Thanks a lot for your time!

-- 
Patrik Lundin


kea.tgz
Description: application/tar-gz

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 10:41:07PM +, Stuart Henderson wrote:
> 
> I see it in perfdhcp. Actually it looks like there's another option, we can
> instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?
> 
> $ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp
> 
[...]
>   NEEDED  libbotan-1.10.so.1.0
[...]

It is not being required on my (clean) system, did you have the library
installed previously when building the port? Of course we should make sure only
one path is choosen anyway.

For reference, this is how perfdhcp looks for me:
===
# objdump -p /usr/local/sbin/perfdhcp  

/usr/local/sbin/perfdhcp: file format elf64-x86-64

Program Header:
PHDR off0x0040 vaddr 0x0040 paddr 
0x0040 align 2**3
 filesz 0x0268 memsz 0x0268 flags r-x
  INTERP off0x0318 vaddr 0x0318 paddr 
0x0318 align 2**0
 filesz 0x0013 memsz 0x0013 flags r--
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x0005361e memsz 0x0005361e flags r-x
LOAD off0x00053620 vaddr 0x00153620 paddr 
0x00153620 align 2**20
 filesz 0x00011ae5 memsz 0x00011ae5 flags r--
LOAD off0x00065108 vaddr 0x00265108 paddr 
0x00265108 align 2**20
 filesz 0x1ad0 memsz 0x1ad0 flags rw-
LOAD off0x00066bd8 vaddr 0x00366bd8 paddr 
0x00366bd8 align 2**20
 filesz 0x0908 memsz 0x0908 flags rw-
LOAD off0x000674e0 vaddr 0x004674e0 paddr 
0x004674e0 align 2**20
 filesz 0x0058 memsz 0x0500 flags rw-
 DYNAMIC off0x00066a08 vaddr 0x00266a08 paddr 
0x00266a08 align 2**3
 filesz 0x01d0 memsz 0x01d0 flags rw-
NOTE off0x032c vaddr 0x032c paddr 
0x032c align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x0005a128 vaddr 0x0015a128 paddr 
0x0015a128 align 2**2
 filesz 0x0f54 memsz 0x0f54 flags r--
OPENBSD_RANDOMIZE off0x00065108 vaddr 0x00265108 paddr 
0x00265108 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libkea-exceptions.so.0.0
  NEEDED  libkea-dhcp++.so.0.0
  NEEDED  libkea-asiolink.so.0.0
  NEEDED  libkea-dns++.so.0.0
  NEEDED  libkea-cryptolink.so.0.0
  NEEDED  libcrypto.so.36.1
  NEEDED  libkea-util.so.0.0
  NEEDED  libstdc++.so.57.0
  NEEDED  libm.so.9.0
  NEEDED  libc.so.84.2
  HASH0x348
  STRTAB  0x48f0
  SYMTAB  0x1440
  STRSZ   0x69e5
  SYMENT  0x18
  DEBUG   0x0
  PLTGOT  0x366bd8
  PLTRELSZ0xd98
  PLTREL  0x7
  JMPREL  0xf700
  RELA0xb2d8
  RELASZ  0x4428
  RELAENT 0x18
  RELACOUNT   0x111

===

I have posted a question to kea-dev regarding this:
https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html

Let's see how that goes.

-- 
Patrik Lundin

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 11:18:53PM +0100, Patrik Lundin wrote:
> 
> What is picking up botan? I looked at every @bin and @lib with ldd and I
> can't see anyone referring to that library. What am i missing?
> 

>From http://kea.isc.org/docs/kea-guide.html#required-software:
===
Kea supports two crypto libraries: Botan and OpenSSL. Only one of them
is required to be installed during compilation. Kea uses the Botan
crypto library for C++ (http://botan.randombit.net/), version 1.8 or
later. As an alternative to Botan, Kea can use the OpenSSL crypto
library (http://www.openssl.org/). It requires a version with SHA-2
support. 
===

I realize I do not know which library is preferred from the upstream
perspective, but using LibreSSL seemed nice (and this is what was choosen on my
build box).

On my box the following is seen:
===
# ldd /usr/local/sbin/kea-dhcp4
[...]
1f4847a77000 1f4848045000 rlib 07   0  
/usr/lib/libcrypto.so.36.1
[...]
===

>From config.log (after tests for botan have failed):
===
configure:17410: checking for OpenSSL library
configure:17430: result: yes
configure:17468: checking OpenSSL version
configure:17480: result: LibreSSL 2.3.2
configure:17485: checking support of SHA-2
configure:17506: c++ -o conftest -O2 -pipe   -DOS_BSD  conftest.cpp  -lcrypto 
>&5
configure:17506: $? = 0
configure:17507: result: yes
===

I can ask upstream what they prefer if there are no strong opinions raised on
this list.

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

On 2015/12/08 23:18, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 09:46:34PM +, Stuart Henderson wrote:
> > Thanks, this is looking good to me, Only two changes I'd make. First is
> > in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
> > lines can be replaced with a single command:
> > 
> > install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea
> > 
> 
> This is much prettier, nice catch :).
> 
> >
> > Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
> > listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.
> > 
> 
> What is picking up botan? I looked at every @bin and @lib with ldd and I
> can't see anyone referring to that library. What am i missing?
> 
> -- 
> Patrik Lundin
> 

I see it in perfdhcp. Actually it looks like there's another option, we can
instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?



$ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp

../fake-amd64/usr/local/sbin/perfdhcp: file format elf64-x86-64

Program Header:
PHDR off0x0040 vaddr 0x0040 paddr 
0x0040 align 2**3
 filesz 0x0268 memsz 0x0268 flags r-x
  INTERP off0x0318 vaddr 0x0318 paddr 
0x0318 align 2**0
 filesz 0x0013 memsz 0x0013 flags r--
LOAD off0x vaddr 0x paddr 
0x align 2**20
 filesz 0x000536de memsz 0x000536de flags r-x
LOAD off0x000536e0 vaddr 0x001536e0 paddr 
0x001536e0 align 2**20
 filesz 0x00011ba5 memsz 0x00011ba5 flags r--
LOAD off0x00065288 vaddr 0x00265288 paddr 
0x00265288 align 2**20
 filesz 0x1b30 memsz 0x1b30 flags rw-
LOAD off0x00066db8 vaddr 0x00366db8 paddr 
0x00366db8 align 2**20
 filesz 0x0908 memsz 0x0908 flags rw-
LOAD off0x000676c0 vaddr 0x004676c0 paddr 
0x004676c0 align 2**20
 filesz 0x0058 memsz 0x0500 flags rw-
 DYNAMIC off0x00066b88 vaddr 0x00266b88 paddr 
0x00266b88 align 2**3
 filesz 0x0230 memsz 0x0230 flags rw-
NOTE off0x032c vaddr 0x032c paddr 
0x032c align 2**2
 filesz 0x0018 memsz 0x0018 flags r--
EH_FRAME off0x0005a2a8 vaddr 0x0015a2a8 paddr 
0x0015a2a8 align 2**2
 filesz 0x0f54 memsz 0x0f54 flags r--
OPENBSD_RANDOMIZE off0x00065288 vaddr 0x00265288 paddr 
0x00265288 align 2**3
 filesz 0x0008 memsz 0x0008 flags rw-

Dynamic Section:
  NEEDED  libkea-exceptions.so.0.0
  NEEDED  libkea-dhcp++.so.0.0
  NEEDED  libkea-asiolink.so.0.0
  NEEDED  libkea-dns++.so.0.0
  NEEDED  libkea-cryptolink.so.0.0
  NEEDED  libbotan-1.10.so.1.0
  NEEDED  libbz2.so.10.4
  NEEDED  libcrypto.so.36.1
  NEEDED  libgmp.so.9.0
  NEEDED  libpthread.so.20.1
  NEEDED  libz.so.5.0
  NEEDED  libkea-util.so.0.0
  NEEDED  libstdc++.so.57.0
  NEEDED  libm.so.9.0
  NEEDED  libc.so.84.2
  RPATH   /usr/local/lib
  HASH0x348
  STRTAB  0x4908
  SYMTAB  0x1440
  STRSZ   0x6a93
  SYMENT  0x18
  DEBUG   0x0
  PLTGOT  0x366db8
  PLTRELSZ0xd98
  PLTREL  0x7
  JMPREL  0xf7c8
  RELA0xb3a0
  RELASZ  0x4428
  RELAENT 0x18
  RELACOUNT   0x111

Re: net/kea

[Stuart Henderson]

On 2015/12/08 23:59, Patrik Lundin wrote:
> On Tue, Dec 08, 2015 at 10:41:07PM +, Stuart Henderson wrote:
> > 
> > I see it in perfdhcp. Actually it looks like there's another option, we can
> > instead use CONFIGURE_ARGS+= --with-openssl - which would you prefer?
> > 
> > $ objdump -p ../fake-amd64/usr/local/sbin/perfdhcp
> > 
> [...]
> >   NEEDED  libbotan-1.10.so.1.0
> [...]
> 
> It is not being required on my (clean) system, did you have the library
> installed previously when building the port? Of course we should make sure 
> only
> one path is choosen anyway.

Yes - and this will sometimes be the case in package builds, so if it's not
registered then we'll either have build failures (DPB has a 'junking' stage
run periodically where it removes packages during the build if they're not
a known dependency of anything currently being built) or runtime failures
(if packages are produced which are built against botan and the user doesn't
have that installed).

> I have posted a question to kea-dev regarding this:
> https://lists.isc.org/pipermail/kea-dev/2015-December/000588.html
> 
> Let's see how that goes.

Good idea.

Re: net/kea

[Patrik Lundin]

On Tue, Dec 08, 2015 at 09:46:34PM +, Stuart Henderson wrote:
> Thanks, this is looking good to me, Only two changes I'd make. First is
> in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
> lines can be replaced with a single command:
> 
>   install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea
> 

This is much prettier, nice catch :).

>
> Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
> listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.
> 

What is picking up botan? I looked at every @bin and @lib with ldd and I
can't see anyone referring to that library. What am i missing?

-- 
Patrik Lundin

Re: net/kea

[Stuart Henderson]

Thanks, this is looking good to me, Only two changes I'd make. First is
in the rc script, what you have isn't wrong, but the mkdir/chown/chmod
lines can be replaced with a single command:

install -d -o root:_kea -m 775 ${LOCALSTATEDIR}/run/kea

Second change is WANTLIB/LIB_DEPENDS; it picks up botan so it needs to be
listed in LIB_DEPENDS, and the relevant WANTLIBs added. New tar attached.

Any OKs to import? (Or, as usual, if someone else would like to import,
it's OK with me).

> FYI: upstream has created a ticket which aims to rename "message" to
> "kea-msg-compiler" based on this input: http://kea.isc.org/ticket/4228

Great, thanks :)



kea,2.tgz
Description: application/tar-gz

Re: net/kea

[Stuart Henderson]

On 2015/12/06 21:19, Patrik Lundin wrote:
> Hello,
> 
> I am working on a port for Kea, the new DHCP server from ISC.
> 
> ===
> # cat pkg/DESC
> Kea is a new open source DHCPv4/DHCPv6 server being developed by Internet
> Systems Consortium. The objective of this project is to provide a very
> high-performance, extensible DHCP server engine for use by enterprises and
> service providers, either as is or with extensions and modifications.
> 
> Kea provides DHCPv4 and DHCPv6 servers, a dynamic DNS update module, a 
> portable
> DHCP library, libdhcp++, and a DHCP benchmarking tool, perfdhcp.
> ===
> 
> Attached you will find the port, which is currently a work-in-progress
> hoping for input from more experience porters.
> 
> I am currently able to build three flavors: the default one which only
> uses the built in "memfile" backend, and then two database backends
> using mysql and postgresql.
> 
> My current up front questions are these:
> 
> 1. When running "make update-plist" I get the following messages:
> ===
> make-plist: Bogus element outside of every prefix: /etc/kea/kea.conf
> make-plist: Bogus element outside of every prefix: /etc/kea/keactrl.conf

For these, you can often override a variable in upstream's Makefiles
in FAKE_FLAGS to install these files to /usr/local/share/examples,
often named sysconfdir or SYSCONFDIR.

 it's likely to be similar to this

FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples/

pre-install:
mkdir -p ${PREFIX}/share/examples/bind10/

the advantage of this is that if upstream later start to install another
file, you're less likely to miss it.

> make-plist: Bogus element outside of every prefix: /etc/rc.d/kea

Ignore this and handle the rcscript in PLIST manually.

> make-plist: Bogus element outside of every prefix: /var/kea
> make-plist: Bogus element outside of every prefix: /var/run/kea

/var/run is cleared at boot so the /var/run/kea directory needs creating
in the rcscript. we normally do not include these in plist.

> 
> Can these be ignored? I am handling all of the files mentioned via
> @sample lines in PLIST (except for rc.d/kea which of course is an @rc
> line).
> 
> 2. I am not completely comfortable in my SHARED_LIBS knowledge, I would
>appreciate an extra eye on those lines in the Makefile. Right now
>they are taken as-is from the output generated when building the
>port.
> 
> Other than that I have raised some additional questions against
> upstream, you can find them here:
> https://lists.isc.org/pipermail/kea-dev/2015-December/000576.html
> 
> -- 
> Patrik Lundin

other comments:

"@sample /etc/kea/" shoukd use SYSCONFDIR and this plist line is usually
placed near the files that go in that dir

please order Makefile closer to the section ordering in
Makefile.template

the shared libs lines are ok (except want to be earlier in the makefile)

the static libs are unlikely to be useful, and the whole port is unlikely
to work without shared libs, so I'd disable them (probably --disable-static
in CONFIGURE_ARGS, and SHARED_ONLY=Yes) to save build time

not a port problem, but "message" is a terrible name for sonething that
upstream want to place in a system directory!