see https://reviews.freebsd.org/D19192 for alternative diff

@feld here's https://git.sr.ht/~dch/ports/commit/0af5618836ea22f68f8c4a0c183dee08c042375b alternative implementation using OTP21 via shim, much tidier IMO. I am not clear how to update LOCALBASE within the patch file though, what do you suggest for doing that rather than having it hardwired?

@feld what about using OTP21_RUN_DEPENDS=${LOCALBASE}/lib/erlang21/bin/erl:lang/erlang-runtime21 and leaving the OTP bump alone in this patch? It would also require a small shim for each of:

submitted exp-run https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235733 for removing the older OTP versions. Once that's back I'll do one to bump default OTP to 21.2.5.

• updated diff removes hardcoded paths, cleaned for rclint
• confirmed it really does work when zerotier is newly installed and after joining a secure network
• found it blocks the boot completely if the environment uses static IP rather than DHCP
• see https://github.com/zerotier/ZeroTierOne/issues/900 for community feedback

committed in r487870

tweak UPDATING and pkg-message in line with diff

The underlying issue I'm trying to fix is to get the interfaces up and have an
IP available *before* we allow pf|ipfw to run. I'm pretty sure that this doesn't
actually do what I want at present, but I've not figured out a good way of
debugging things that early in the boot phase.

Unfortunately not this is a bug in the upstream build and can’t just be
changed as other modules refer to it. It only appears in the plist which
is why nobody noticed it prior. We’ll fix it for 2.3.1 though.

the diff side of this is ready for review, but I still need to work through functional testing - actual conf is quite different to previous version.

@jrm this passes local poudriere, needs your rubber stamp or your nit-stick.

• update config files to latest release and backport FreeBSD customisations
• use more templating for configs from ports tree
• bump documented end-user dependencies

• update for latest ruby versions
• include riemann-rabbitmq and riemann-tail
• passes poudriere 11.2R 12.0b4 on amd64 & tested a few functions

In D17907#382700, @jrm wrote:

I'm now wondering if devel is the appropriate category. sysutils?

Makefile-based interpretative dance moves

final tweaks to Makefile, fail to appease portlint

thanks, that sed goop works a treat. I'll doublecheck some more functionality tomorrow but I think this is ready to land now.

use jrm's powerful sed-fu to sidestep the dreaded GNU dependency

include via sed an upstreamed patch that cleans process name

merge PR feedback + new plist

danfe is having a look at the C side of this (thank-you) which would be a far better solution

abuse MAKE_ENV to force including pinned security/openssl 1.0.2

OK poudriere tells me this doesn't work. However I definitely got 1 good build earlier - need to investigate what I've missed.

bump version to 1.1.2

remove pathological lack of self-assurance

annihilate invisible whitespace

done - thanks for the catch - I'll be able to test drive this finally tomorrow back in the office.

unbreak sorting of dependencies

amend egregious USES? & add missing dependency

changes done (thanks for the catch) I'll give the actual port a test drive tomorrow.

If our policy gurus say it should be bumped, then I'm cool with that
but I don't see the need to inflict more unnecessary downloads and
upgrades on the planet than we already do.

• update to 3.7.8
• add user knob for OTP versions
• appease jrm and portlint
• fail getting USE_GITHUB to work

poudriere says "no":

In D17168#366010, @dumbbell wrote:

I didn't test it yet but this looks good to me.

What do you think about adding a variable for the version of Erlang and use it everywhere in the Makefile? Something like:

ERLANG_VERSION ?= 19

• update to 3.7.8
• add user knob for OTP versions

I think this is ready to land now, I'll do the poudriere thing and report back if anything breaks.

I think this is all that's missing?

this is why I dislike using phab, git, and svn, instead of just 1 integrated system....

BTW not clear for me, if after these changes, it would now compile on powerpc *shrug*

fix compiler nits & add arm support from PR#231335

@jbeich thanks for your compiler changes, as I'm not a C programmer I'm not really following the consequences of this. If you can suggest a web page or docs I can read up to understand better that would really be helpful for me.

I incorporated most of the feedback, ppc/arm/qemu-flavoured poudriere will need to wait til I'm back in the office. thanks for the suggestions!

incorporate feedback from jbeich@

In D16880#359947, @jbeich wrote:

this port hardcodes CXX, so USES=compiler:c++14-lang cannot switch to devel/llvm60. This is a regression since rP436712.