Not a Go user, but semantically the change looks fine.

There is a clear demand for a newer Linuxulator base and unlike the FreeBSD base we can't control the minimum CPU requirement here. Ports still provide an option for users to switch to an older Linuxulator base. At the same time, how likely would it be that a pre-Nehalem user bumps into a program that uses those instructions? I can hardly imagine someone playing Linux games on old amd64 hardware.

• Fix email

games/nwnclient will be fixed after the switch according to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252747

• Fix plist for glib20@bootstrap
• Add an URL to the upstream announcement explaining the circular dependency situation

I think the proper way to port this software would be to approach upstream and merge our patches there, then wait for a new release.

Last time I tried to port it in https://reviews.freebsd.org/D34051 the main obstacle was that COOL uses various Linux-specific features to jail its processes. I reached the stage when it runs, but in an "insecure" mode, which isn't ready for the production. To properly port this software a lot of upstream work was required.

• Add UPDATING entry

Also to draft an UPDATING entry since the circular build situation requires "manual intervention" for those not using poudriere/isolated build environments.

• devel/glibd: Fix build with new devel/glib20
• devel/glib20: Fix plist by adding docs
• devel/glib20: Remove OPTIONS and TRIGGERS from the bootstrap FLAVOR

• Update to util-linux 2.41 that contains our upstreamed patches
• filesystems/e2fsprogs-core: Stop linking util-linux libs statically, because upstream stopped providing it
• Did a mini-exprun on all libuuid libblkid consumers

Overcome by events.

Fixed last build failures uncovered by my mini-exprun. Let's finally land this?

Running a mini (Queued: 2012) exp-run with this Diff.

• Apply suggestions