Nice!

In D37210#856150, @asomers wrote:

@markj @jlduran_gmail.com I fixed the network errors that markj found. A necessary side effect seems to be the pep-8 style warnings, and I don't see any way to suppress those. Are there any other problems here?

In D37210#851432, @asomers wrote:

@thj already has a fix prepared.

Remembering the late Mike Muuss, I decided to take a stab at this problem while we wait for the cavalry to arrive.
The short version is revert d9cacf605e2ac0f704e1ce76357cbfbe6cb63d52, and start from that.
Let me know if you are interested, and I can open a Draft Pull Request on GitHub.
Without knowing the full picture, here is the full version:

Thank you!

Remove the manual page part. It will be removed entirely.

GitHub Pull Request with commits for D37248 and D37250:
https://github.com/freebsd/freebsd-src/pull/625

GitHub Pull Request with commits for D37248 and D37250:
https://github.com/freebsd/freebsd-src/pull/625

In D37247#845961, @markj wrote:

Could I ask you to make your git commits available somehow, either by email or in a pull request?

GitHub Pull Request: https://github.com/freebsd/freebsd-src/pull/623

In D37249#845933, @markj wrote:

I'm not sure this works? It's not very clear to me what can and what cannot be in the header, but it's usually just used to define test metadata.

If I try adding an unconditional atf_skip to one of the test headers, I get:

markj@nuc> kyua list ping_test
ping_test:__test_cases_list__
markj@nuc> kyua test ping_test
ping_test:__test_cases_list__  ->  broken: Invalid test case definition; must be preceeded by the identifier  [0.001s]

Results file id is usr_tests_sbin_ping.20221103-125835-090128
Results saved to /home/markj/.kyua/store/results.usr_tests_sbin_ping.20221103-125835-090128.db

0/1 passed (1 failed)

Move the atf_skips to the body section.

Use the right diff.

In D37210#845076, @asomers wrote:

In D37210#845043, @jlduran_gmail.com wrote:

I may also have a slight suspicion you applied your diff to a different ping.c base. After all, the idea was just to add test cases.

Yes I did. But I can't figure out how to make the ping.c changes go away from phabricator. Can we just pretend, for the sake of review, that they aren't there?

I may also have a slight suspicion you applied your diff to a different ping.c base. After all, the idea was just to add test cases.

Although fearing my suggestions could make the tests more brittle, I'm still interested to know what do you think?

I have created a pull request with a rough sketch of what has been discussed here:
https://github.com/freebsd/freebsd-doc/pull/91
Please discard the Pull Request, it was used just to illustrate a point.
Thank you!

This looks great! Give me some time to test it on all three platforms.
It may still need a few minor adjustments.
Thank you!

I prefer the direction this is heading to!
There is one thing that bothers me with the current diff, but it can be easily solved: If I a person is a FreeBSD user and a Ruby developer, the GEM_PATH might be already defined (see other reserved names).
Let's try to tackle this from the end user's perspective:
FreeBSD:

$ bmake run

Linux:

$ bmake run LOCALBASE=/usr

macOS:

$ bmake run USE_RUBYGEMS=YES GEM_PATH=/usr/local/lib/ruby/gems/[ruby_version]

If the macOS user has already defined GEM_PATH, then the command would just be bmake run USE_RUBYGEMS=YES. USE_RUBYGEMS or something along those lines.
Then, a FreeBSD/Linux user, that is also a Ruby developer —and hates installing Ruby gems via package managers— now has the ability to USE_RUBYGEMS.
What do you think?

Here is a branch on the same repo with the approach suggested by this diff of adding the symlinks (but just for ruby and rougify).

In D37143#844015, @fel1x.mintchoco.development_gmail.com wrote:

In D37143#843876, @jlduran_gmail.com wrote:

I took a closer look at this, and I think one solution could be just to patch the Makekile in the documentation directory.

The problem is that the rouge binaries (rougify), installed by gem are in a different path. This predicament is not present on FreeBSD/Linux because you are instructed to install everything with a package manager, which installs all the binaries in the same place.

I have deployed a simple GitHub repo illustrating this issue. It patches the Makefile. You can verify in the artifacts for each run that the documentation builds successfully (it uploads a documentation.zip file containing the public directory).

In the meantime, perhaps a quick solution would be to define:

ROUGIFY_CMD?= ${LOCALBASE}/bin/rougify

So it can be overridden:

$ bmake run ROUGIFY_CMD=${GEM_PATH}/rougify

My main issue with this patch are the symlinks.

This looks fine, but we have to make each if case for FreeBSD, Linux, and macOS. Unfortunately, I don't know how to make a variable of 'uname -s' in bmake. Is there such a way in bmake?

I took a closer look at this, and I think one solution could be just to patch the Makekile in the documentation directory.

Thank you! I remember trying to fix this issue a while ago.

At this point in time, it might be easier to revert d87e0e8e230495df3be59a8a5c173aafc83bc450 😓

Update with the right diff.

Update diff to include context.

Update diff (to include context).

Update diff.

Even better!

Sorry I missed this review,

No problem!

Closed by 6e6c45e66f68e68b451a27430f51a687e00bad15.

I'll have to make a rescue image to verify, but I think we can drop these two files, and let cust_allow_ssh_root handle it.

Is this an April fools' joke?, if not nice!

Thanks, I appreciate it!

This was much needed, thank you!

Landed as 325ebf37d8efc6488754051fcc2b1aaa40cefd8b.

More testing is needed on frame buffer consoles.

In D34532#782394, @imp wrote:

A lot depends on which terminal emulator you are on.

Briefly mention the new function in rc.subr(8).

Thank you. I’ll add a brief mention to it in rc.subr(8).

Sorry, for a moment I doubted about changing echo -n to printf.

Add missing $@.

In D34426#780372, @markj wrote:
I'm not too familiar with the history of zpool versions - isn't the problem really with feature flags? I suppose we'd need to identify the set of pool features supported by a reasonable range of FreeBSD releases, and ensure that only those features are enabled. A firstboot rc.d script could be used to upgrade the pool.

This is a nice addition!