Looks good, let me prepare the RC1 tarball so we can go to RC1 directly and skip beta5.

LGTM!

In D23544#518743, @jbeich wrote:

In D23544#518568, @ports_xanderio.de wrote:

As x11-servers/wayland-devel should not be dependencies.

As mentioned in D23544#517781 x11-servers/xwayland-devel is already pulled by x11-toolkits/wlroots since rP525681 because of x11-wm/sway, x11-wm/wayfire, x11-wm/cage.

Disabling the X11 option as upstream declared this feature unstable

OK, especially since upstream uses FreeBSD. ;)

In D23544#518568, @ports_xanderio.de wrote:

As x11-servers/wayland-devel should not be dependencies.

Disabling the X11 option as upstream declared this feature unstable

xwayland-devel package should be available tomorrow or the day after. Kwin may follow soon, leaving xwayland package to bitrot on its own.
However, until libepoll-shim is updated none of the compositors in ports tree are stable (even if Xwayland is disabled) because libwayland itself uses libepoll-shim.

And yes epollshim is another issue. I've already talked to @zeising at the FreeBSD devsummit about it, and he is aware of this issue.

In D23544#517942, @jbeich wrote:

In D23544#517935, @raichoo_googlemail.com wrote:

It would lead to a binary package that would not be usable for daily use

What? I'm daily using x11-servers/xwayland-devel. Staying on snapshot also makes it easy to adopt https://gitlab.freedesktop.org/xorg/xserver/merge_requests/111 or similar. Wayland is only good when fresh. ;)

In D23544#517781, @jbeich wrote:

In D23544#517432, @raichoo_googlemail.com wrote:

I'm currently running a self compiled Xwayland server.

Then rP525681 should help. Until bug 244010 lands expect minor annoyance when building outside of poudriere.

For the record, I think the last commit I've used for Xwayland was a026972776b303fa640f54e5e8f0fc1abf879071 from their HEAD. It turned out to be pretty stable for me. Can't recall it ever crashing on me.

Disabling XWayland was my call, since I don't have the best experience with the Xwayland server that is shipped with FreeBSD. It was quite unstable, and crashed on me several times. I haven't checked stability in quite a while though, I just found it to be near unusable last time I checked. I'm currently running a self compiled Xwayland server.

XWayland support is currently incomplete and I was planning to take a look at it tonight. I didn't maintain it for a while since I ditched it entirely on my setup.

In D23544#516930, @jbeich wrote:

Some places hardcode /usr/local:

$ rg /usr/local
Makefile
45:WAYLAND_PROTOCOLS ?= /usr/local/share/wayland-protocols

Ignoring doc/example_hikari.conf as unlikely to be used "as is", `/usr/local/share/wayland-protocols` should be replaced with ``pkg-config --variable pkgdatadir wayland-protocols``.

Adjusted the Makefile in hikari upstream. This changed the checksum for the provided tarball (which is currently only meant for this port anyway).

It makes sense to me to include command line arguments in the man page. What I'm not clear on is how far you want to go here. Are you going to document the entire language? Just variables? Variables, subroutines, and aggregate functions? Why take this approach instead of converting the docbook source to something that can be read in a terminal? There is, e.g., docbook2mdoc available in ports.

To be clear, I would very much like to see improvements in FreeBSD's dtrace documentation. I'm not convinced that importing text from dtrace.org is a good way to go about that.

What "examples" do you mean here? It's basically just describing the variables. I could certainly rewrite the sentences. It admittedly feels a bit weird to do something like this but if that's what the license requires I can take up on that task.

I have already made such a change by importing documentation from the Handbook into the manpage. I've talked to @bcr asking the same question at the Essen Hackathon and he told me it would be okay. I personally would like to have something like this in the manpage since I use dtrace quite a bit and I'm missing proper documentation that is being shipped with FreeBSD that I can consume on the terminal. The manpage seems to be the obvious place for this since it's where people look first.

Bumping this since it's been laying dormant for quite a while. Does this still need work to get merged? I've had people asking me things at 35c3 that have been documented here.

@bcr Noted. I'll keep that in mind in the future :)

@bcr The date has already been bumped in the last diff (which has already been merged). Both of these patches were written more or less at the same time, do I still need to bump the date, and if so, what date? :)

I have updated the patch regarding one of the comments. The other one should stay as it is since it's more consistent with the rest of the manpage is phrased.

Some options are missing because I'm not that familiar with them. I will certainly try to make the documentation exhaustive at some point ^^. By the way, I have another PR working on the documentation. https://reviews.freebsd.org/D16688 If you find the time, I'd appreciate the feedback :)

Drew some formatting ideas from the zfs(8) manpage in an attempt to be consistent with the rest of the world.

Added time units

I have moved the size portion up. Apparently this also applies to strsize which I wasn't aware of.

Added bufpolicy.

Fixed a typo

I have extracted the size options from the truncate(1) manpage since this is pretty much the same thing. I should probably also document the bufpolicy option.