Yeah, I don't like the way we now have the master files. I think I was too much focussed on keeping the file size small and opted to compress, followed by uuencode. But it's a real pain to work with. For one, you can't diff the rebased files after a code change and see if the new behavior matches the expectation. And on top of that, diffs tend to be much bigger than a one-liner of the hexdump output.

Thanks for pointing out that OpenSSL 1.0.x needs to be supported.
OpenIKED 2.1 has support for OpenSSL 1.0.x and OpenSSL 1.1.x.

Upgrade to openiked-2.1

LGTM

This is opposite the direction taken already. The low-level console is defined in terms of hardware resources only. The uart(4) driver will map the low-level console to the newbus device during bus enumeration. The unit number is not a hardware resource. It's a newbus device property.

LGTM.

I'm ok with the changes. I'll trust Ed to give others a chance to chime in. Speculatively accepting the revision on everyone's behalf.

I feel that using GEOM::media as a way to signal a label change is missing the more fundamental problem: the code change is based on the assumption that labels can't change, which ae@ showed is false.

LGTM...

Two comments:

1. I see that there's an unvis(3) function as well. That seems like a good way to handle escape sequences in read_word() and not have callers of read_word() handle escape characters.
2. makefs needs to be portable. Do you know if vis(3) exists on macOS and Linux?

First the quick answer: The pf_state structure as sent by the INS, DEL and UPD actions is not a multiple of 4-bytes on amd64. All the pfsync structure are indeed.

The updated diff addresses your concern and eliminates incompatibilities. Your comment tells me that you haven't seen the updated diff...

If there are no objections, I'll commit this in a few days.

Don't change the version in the header (i.e. keep at 5), and
instead use the subsequent _pad field for a revision. The
revision allows minor changes to the definitions while not
breaking compatibility with previous revisions.

In D10863#225094, @glebius wrote:

Is this part of a bigger change? What's the final goal.

LGTM. Thanks!

Already fixed.

I'm seeing this with a slightly older 11-stable. I see that r305055 has been MFC'd as r313129 on 2017-02-02. which means the fix is not present on the system I see it in. Both my up-to-date -current and -stable systems seem to work (see example below). So it looks the problem was already fixed!

Going for the workaround I see! :-)

Got it! Thanks for the explanation.

First of all: You may want to change root_mount_rel() as well: h cannot be NULL anymore. A KASSERT would be appropriate...

I don't want to assume I remember all the details with respect to compiling libc from a different locations, but what I recall is that it's only about building libc using a different makefile that lives in a different directory and thus having the object files go to a different object directory. Thus any mention of ${.CURDIR} had to be replaced with LIBC_SRCTOP and LIBC_SRCTOP was effectively set to ${SRCTOP}/lib/libc.

Self-approved

Is there anything that needs to be done, except committing this?
If finding a committer is a challenge, then I can do i myself.

Self approve.

Incorporate review comments from Mathieu.

Great review! I very much appreciate your attention to detail!

Incorporate review comments from mat@ (thanks!):

• Add WWW line to pkg-descr.
• Use make makeplist to generate pkg-plist. Manually edited to declare sample configuration with @sample
• Added libtool and ssl to USES
• Remove MASTER_SITES

We can't use the required_files variable given that start_precmd creates files mentioned there. Manually check for having the required files in start_precmd.

LGTM -- I don't think this will impact building makefs on non-FreeBSD...