Fix the silly cut and paste bug.

In D14721#348739, @mat wrote:

Side note.

All ports MUST build as a regular user.

We spent a lot of time making sure they all do, DO NOT add new ports that require being root, they will get removed at one point in the very near future.

Generally, I like what's presented here. There's much we need to cleanup, I think, but this is a good start.

In D16775#357085, @jhb wrote:

As far as std.arm*: I don't know why it only has options. It seems to me that 'std.*' files should be fine to have devices as well. Note that 'std.MALTA' in sys/conf/mips has both devices and options. I think moving "standard" devices into std.arm* to reduce duplication in kernel configurations for things that are a truly "standard" thing (which pseudo-devices probably are) would probably be a good thing, but that probably needs to be run by Warner.

OK from manpages.

The issue with SSE2 here is not related to C compiler flags or build environment. lang/go is self-hosting and doesn't use C compiler during build.

OK from manpages.

jhb' wording for the comment.

I'm not sure if I got the problem lead to this option/flavor-izing completely.
But I had an issue with SSE4.2-ops on MySQL,
with suggestion of people,added "compiler:c++14-lang" fixed it naturally because it added "correct" dependency/flags to port's build-env...

lang/go: flavorize; add -nosse2 flavor for older i386 CPUs lacking SSE2 support

Sorry to be so picky about the comments. The code part definitely looks fine to me.

In D16782#357098, @kristof wrote:

It'd be really awesome if you could also see about writing some basic tests (both as pfctl parser tests, to check we can now set higher bitrates for shaping, and as a basic test that shaping actually happens), but that's certainly not blocking.

Rework comments.

In D16743#357090, @jhb wrote:

This looks ok to me, but I'm not a ports committer so I can't approve it. :)

Do you know if we will need to exclude the plugins for the various devel/{amd64,i386,aarch64,mips,mips64,powerpc64,sparc64}-gcc pkg-plist files as well? That is, do they build cleanly now on arm64? Removing BROKEN_aarch64 from powerpc64-gcc/Makefile means all those packages will try to build on the next aarch64 package run.

Can you please break the change to share/mk/bsd.confs.mk out into a separate review, though it is required by the moving of the profile files, it is actually not a part of that change directly. I would also like to ask that you tag bdrewery in on the review of the .mk change. I do not see how file owner/group/mode are set in the new Makefile.

It'd be really awesome if you could also see about writing some basic tests (both as pfctl parser tests, to check we can now set higher bitrates for shaping, and as a basic test that shaping actually happens), but that's certainly not blocking.

Though I disagree with the relocation of this to libc as it is going to be installed with the absolute minimal system anyway so this delta just creates src tree churn, and user finger memory churn. You site your reason for moving it is to put it close to the sources, well, traditionally BSD sources are layed out to match the installed DESTDIR tree. I understand things like csh and sh conf files moving, that makes since in a world where csh or sh may or may not be installed by a pkgbase, however that makes no since in a world where libc and hence master.passwd shall always be installed.

Two minor remarks, at first glance. I've not dug into it at great depth, but your approach looks good and I've not seen any big problems.

This looks ok to me, but I'm not a ports committer so I can't approve it. :)

Generally looks fine to me.

I do think we shouldn't tag 'crypto' on 'IPSec' files nor 'IPSec' on crypto files. Ok, I've looked at sys/conf/files and I do think it needs cleaning up. In particular, crypto algorithms that have a software OCF binding should have 'crypto' in their list so that OCF supports them. Things like IPSec and GELI that use OCF for crypto should not be listed in the list of options for crypto algorithms, only things that directly use the API exported by the file in question.

This looks ready to land. We need to get it in in the next week.

Abandoning since this idea is being rejected.

In D16573#356843, @darrick.freebsd_gmail.com wrote:

In D16573#356822, @kib wrote:

Why did you moved the check for mallocspace back into the want_malloc_buf() ?

I thought we wanted that check in both places where want want_malloc_buf() is called? I can inline it in both places if that's preferred.

Reorder variables

Upload all the changes once again.

Move SUB_FILES to the block for standard bsd.port.mk variables.

LGTM (with minor change noted in-line).

In D16626#356917, @rrs wrote:

This version incorporates all of Jonathans comments and suggested improvements. Thanks
Jonathan!!!

Flush out SYSLOGD_DDIR

Bump date.

Remove an extra file that snuck in