Great work with the MFH (MFC is for src)!

Thank you!

Thanks!

Just one more issue with the manual page.

Thanks!

In D33137#749028, @driesm wrote:

Base >= on setup.py upstream. Poudriere testport still looks good.

Assuming that the versions for RUN_DEPENDS come from the port's setup.py or an equivalent, I think that this change looks great.

Thanks!

In D33105#748418, @driesm wrote:

In D33105#748417, @0mp wrote:

Personally, I'd skip it. :)

^^ So to be clear: you would skip bumping PORTREVISION? Right? (like sunpoet's commit)

Personally, I'd skip it. :)

Just a note: sometimes people don't bump portrevision when adding NO_ARCH (e.g., https://github.com/freebsd/freebsd-ports/commit/8918d79d4efdaf2ed1ac659d51e77913f439da7f). The reason is that this is not an important change from the user perspective and perhaps it's not necessary to trigger a package rebuild. However, according to PHB, PORTREVISION must be bumped whenever the contents of the final package change AFAIR. When in doubt, ask fellow committers. As always, if you are unsure about some part of the change, note it in the commit message.

The change looks fine. We need the maintainer's approval to commit this update (or a maintainer timeout). Not everyone is checking phabricator notifications regularly, so it maybe a good idea to create a PR on bugzilla and point to this patch. Then the maintainer will get an email and if they don't respond in 2 weeks, you'll be able to proceed with the commit. In theory, if you know that the maintainer is responsive, then you can ask for an approval via a private email. Again, keep in mind that there is no other way to reach the "maintainer timeout" without a ticket on bugzilla.

Thank you for the review! I committed the patch in https://cgit.freebsd.org/src/commit/?id=169e06fa7852810f4ced2cce7a3c14ca9443bf39.

In D33092#747700, @imp wrote:

From the standard:

The application shall quote the following characters if they are to represent themselves:

& ; < > ( ) $ ` \ " ' <space> <tab> <newline>

and the following may need to be quoted under certain circumstances. That is, these characters may be special depending on conditions described elsewhere in this volume of POSIX.1-2017:

• ? [ # ˜ = %

None of these are possible with the freebsd-version -u output. A number of other things break if people use 'custom' release names with spaces in them...
I'm OK with this change, but the need to do it seems quite low and edge-casey.

Just one minor nit. Otherwise looks nice.

I'll see to it when I have some time. If anyone wants to MFC that earlier than let me know or just commandeer it straight away.

In D32985#745570, @trhodes wrote:

Here is a new version based on all the feedback from everyone, keep the good comments coming please!

diff_vmrun.diff5 KBDownload

In D31929#744866, @trasz wrote:

It would be nice to have some sort of man page, even a short one to briefly describe the purpose of this utility.

Well, the change seems alright. Assuming that the default value for nfs_server_maxio makes sense and that sysctl vfs.nfsd.srvmaxio=${nfs_server_maxio} is useful for nfsd.

Hmm, if the maintainer says it helps the port to use a newer version of mono because of it having less bugs it's probably the way to go...

It would be great to also document this variable in rc.conf.5.

1. If it changes the contents of the package and fixes some bug, then bumping PORTREVISION is needed.
2. This port is maintained by mono@. Usually, it is necessary to get approval to modify ports maintained by someone else. In this case, however, I'd say it's fine to use Approved by: portmgr (blanket).

In D33000#745175, @driesm wrote:

In terms of maintainer approval, is it typically the e-mail address or the full or first name that is used in the "Approved by"?

That's definitely a nice addition. Thanks for working on that.

The manual page change seems fine. Please remember to bump the date when committing.

BTW, should we MFC this?

In D32463#744552, @trasz wrote:

There is a somewhat related issue in https://reviews.freebsd.org/D26240. Do you think you could fix it as well, by throwing in an mkdir(1) somewhere in linux_mount?