• New port: devel/llbuild
• Change post-stage to post-install for docs.
• Fix typo: "swift-llbuild", not "switch-llbuild"!
• Add the llbuild binary to the build and plist.
• Fix licensing: use ports' multi-license support.

• Fix typo: "swift-llbuild", not "switch-llbuild"!

• Change post-stage to post-install for docs.

Thanks for the comments: I think I've managed to address them.

• Add {BC,LL}OBJS to bsd.lib.mk's CLEANFILES.
• Remove redundant C++/non-C++ logic.
• Improve whitespace consistency.

The distinction between .bc and .bco was actually purposeful. The next step in the process is to add IR build rules for whole programs, and then we might end up with conflicts between the IR file that's analogous to cp.o and the IR file that's analogous to the cp binary (i.e., the result of llvm-link). So, we used .bco as the bitcode suffix that's analogous to .o (much like .pico is the PIC suffix for .o files).

This is a much simpler change after rS307075. How does it look to everyone now?

Looks like a good idea to me. Perhaps it's worthy of a comment explaining why we use abort() within a library? It could contain the same text as at the top of this review, but it might be a slightly surprising thing to discover if you haven't been party to the review.

Rework this change based on rS307075 (suffix rule files).

• Merge 'origin/master' into arcpatch-D6805

A fairly cursory look didn't turn up any obvious problems for me, but I would like to take a deeper look over the next few days.

Thanks for responding... sounds like a tough problem until we make the leap to Python 3.

Indeed, I did have that exp-run done:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210331

Not that we're well clear of code freezes on -CURRENT (and I think that I've addressed @bdrewery's comments), are folks ok with me committing this?

Very nice.

LGTM

Looks good to me in principle; see inline comment above.

I think that these are all fine to make readable, for the same reason that the hostname is ok: allowing information to "leak" in a way that enables more software to use Capsicum sandboxing is a net win. If we wanted to obscure the host UUID then we should also be hiding anything that could be used to identify the machine, which seems distinctly unhelpful in our overall goal of World Domination (tm).

In D8000#165698, @rwatson wrote:

I'm fine with exposing the hostname here -- the goal of Capsicum has always been to be pragmatic about getting software running where it doesn't violate isolation properties. You could argue that this is an information leak and/or might cause problems for deterministic replay-style applications of Capsicum -- but I'd rather we had more code working in a sandboxing. :-)

Agreed: this change makes perfect sense to me after rS305756.

• Simplify {BUILD,RUN}_DEPENDS.

• Remove superfluous GH_PROJECT variable.
• Move GitHub details to below LIB_DEPENDS.
• Clean up COMMENT to satisfy portlint -A.
• Change pkg-plist to PLIST_FILES.

I think I'd be more comfortable if the bug fixes were committed separately from the Capsicum changes (making everything easier to upstream?) and if the Capsicum-specific stuff could be refactored out as much as possible to reduce the in-line #ifdef content. In particular, it would be nice if there could be struct sandbox or the like to capture all of the additional state required by Capsicum, and the contents of that structure could be different on FreeBSD, OpenBSD, etc. If there were a function called start_sandbox(struct sandbox *sbp) or the like, possibly together with a set_flags(int fd, struct sandbox *) or something, it would allow a nice, fair comparison between the Capsicum and Pledge LoC.

In D7773#164148, @cem wrote:

I'm not a fan of introducing additional forks into otherwise straightforward programs. I think we might introduce more bugs that way than we mitigate with capsicum. I'd rather just allocate a list or array and preopen all inputs.

Updated port to Fix All The Things (TM)

• Remove PREFIX hack from libpolou-avr.
• Add RUN_DEPENDS to libpololu-avr.

Works for me.

Works for me with a variant of 11-STABLE when I use nvidia-modeset. If I just try to use kldload nvidia by itself, however, I get strange artifacts and no visible X.

Address @mjg 's point about EPERM.

• MFC r303406
• Treat EPERM slightly less specially.

This seems to have been obviated by rS303274.

Of course, if we wanted to ignore the --no-fatal-warnings flag altogether, we could just do:

• switch to Makefile-based patching with OSVERSION

• Extract suffix rules into bsd.suffixes[-posix].mk.
• Add bsd.suffixes[-posix].mk to share/mk/Makefile.
• Don't clear suffix rules in bsd.lib.mk.

• Move .SUFFIXES definitions into suffix rule files, too.

Thanks, I've added those to share/mk/Makefile and will request an exp-run.

• Add bsd.suffixes[-posix].mk to share/mk/Makefile.

• Generalize the metadata we can look for.
• Don't output None attributes.
• Normalize paths.
• Give re-definitions a different shape from definitions.
• Add more filename sanitizing.
• Add flags to filter singletons and unconnected components.
• Print the total number of files being parsed.

Obviated by rS300226.

Sorry, I slightly let the ball drop here. How do I create a patch that only applies on one major version?

Ping?

This was done independently by @gahr in rP412743.

So, I can't not approve... :)

• Update to v2.6.
• Add PyQt RUN_DEPENDS

I will now! :)

I suppose that's what I get for updating the port. :)

1. Updating D5547: Fix shebang lines in DTrace Toolkit scripts.