Patch committed. Thanks for your contribution!

Thank you @tagattie !

Thanks for the head up and sorry for getting back this late.

@tagattie any plan to review this?

Committed, thanks for the patience!

Thank you! :)

In D30045#727389, @a.wolk_fudosecurity.com wrote:

@meta Unfortunately I don't have a commit bit. Who can I ask to commit the change?

@meta Unfortunately I don't have a commit bit. Who can I ask to commit the change?

I have already approved this. Feel free to commit with commit message Approved by: meta (maintainer).

Looks OK from ports/ POV and this port doesn't have a maintainer. I remember deciding against using _SC_HOST_NAME_MAX due to being too error-prone in one of my ports.

This port has a maintainer. Assigning as reviewer.

This is the commit message that phrabricator silently removed:

I guess you miss the point.. For nsupdate to be any usable as a intermediator between Samba and bind9 it has to be compiled against (some) Kerberos library.

To avoid collisions with DHCP and other applications,
it might be better to just depend on the binaries created by bind-tools?

after reading D24586 :

update path in diff, add PORTREVISION

Still looks ok to me. I had a couple of comments.

This version cleans up more ports to fix failures reported by exp-run.

Thanks for being so thorough Jung-uk and doing this in a way that will make similar changes much easier in the future.

Closing this due to timeout

In D18477#401611, @pfg wrote:

ping?

FWIW, this is currently my favorite IDE on FreeBSD: netbeans has problems refreshing.
VSCode is not yet ported :(.

FWIW, this is currently my favorite IDE on FreeBSD: netbeans has problems refreshing.
VSCode is not yet ported :(.

Abandoning this change (probably not applicable to enough ports).

Fix issues pointed out by mat@

• Update to 2018.3.2
• Move to devel as we don't really depend on the intellij infrastructure.
• Use native file watching support as in the latest intellij port.

Use WRKSRC instead of WRKDIST.
Still passes portlint and check-plist

In D15350#356103, @bjk wrote:

In D15350#350715, @0mp wrote:

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

As fair as I know we tend to use Dq Li instead of Nm make Cm build-like for inline commands. This is the style we follow in make.conf.5, src.conf.5, mqueufs.5. The Nm-based formatting is used in rc.conf.5 and find.1 on the other hand.

AFAICT, Dq Li is a more popular way to format commands.

The argument which is in favor of Dq Li is that we tend to make commands in Examples sections literal. We very rarely add Nm-like formatting to examples. Hence for the sake of consistency I'm proposing this change from Nm ... to Dq Li. 😄

What do you think about it, @bjk?

I see this is basically overcome by events, but thank you for the explanation/research -- your proposal seems reasonable to me.

In D15350#350715, @0mp wrote:

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

As fair as I know we tend to use Dq Li instead of Nm make Cm build-like for inline commands. This is the style we follow in make.conf.5, src.conf.5, mqueufs.5. The Nm-based formatting is used in rc.conf.5 and find.1 on the other hand.

AFAICT, Dq Li is a more popular way to format commands.

The argument which is in favor of Dq Li is that we tend to make commands in Examples sections literal. We very rarely add Nm-like formatting to examples. Hence for the sake of consistency I'm proposing this change from Nm ... to Dq Li. 😄

What do you think about it, @bjk?

In D15350#348437, @bjk wrote:

Can you remind me why the .Dq Li is supposed to be better for inline commands?

Can you remind me why the .Dq Li is supposed to be better for inline commands?

No idea what this is/does.

Update the patch after recent changes to ports.7.

Fix ntraceroute port

Fix ntraceroute, fix suggested by @mat

New patch generated using -U9999 as per request, no change otherwise

Could you use devel/arcanist, or at least generate a diff with full context like it does, with svn diff -x -U9999 or git diff -U9999.

Some of these ports should probably be deprecated and removed... I'll look into deprecating tripwire12,

LGTM though some of these will want maintainer notification/approval.

Most of these ports are ancient and while I do understand that http://www.minix3.org/distfiles-backup/ isn't ideal it's in most cases the only reliable site I could find hosting the tarballs.

In D12793#274492, @lifanov wrote:

I re-tested it and the port looks good now.
Would you like me to commit it?

Is there a Bugzilla issue for it?

I re-tested it and the port looks good now.
Would you like me to commit it?