Just a hint at what I do, both on src and ports, is create a git branch, commit to it, then submit the revision here (because some people like to see the full picture). When the revision is reviewed, I rebase my git branch, git fetch && git svn rebase in master, merge my branch back into master, and finally git svn dcommit to push my changes back to svn.

The handler was under "assumed" GIANT. IPF itself uses two other locking mechanisms, common to NetBSD and Solaris (Illumos). I intend to replace them with one of the more modern locks. Given they're called by macros the job won't be as daunting as expected.

It's probably best to discuss strsep() with des@ first and leave strtok() for now.

It passes a build. I'll upload.

If they've been removed from IANA's list, then that's OK. To be absolutely correct, using KRB4 is a security risk, however allowing them to stay in services(5) is not a risk. It's KRB4 that is the risk. I'll accept this revision as long as the commit message *accurately* reflects that we are truing up our services(5) with IANA, not the documentation of a port is itself a security risk, which it is not. Just so we are clear about how this is documented in the commit message.

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

In D23615#518357, @wulf wrote:

I recommend to disable USB backend by default and leave it as build-time option as it is not completed yet and interferes with existing USB drivers.
It can be disabled with

sed -i'' -e '/usbhid.c/s/^/#/' Makefile

Replaced MAINTAINER= cy@freebsd.org with ports@freebsd.org. I don't have the hardware and I'm not interested in maintaining it. Anyone else can.

I agree there is no other way to do this:

I agree there is no other way to do this: