@If you accept this review + maintainer-approval + the patch in bugzilla, @wulf is clear to self-assign and commit+merge with my ports approval (already added).

@imp I've approved (ports) the updated patch in the bugzilla issue

Is -werror now disabled /overridden in upstream sources?

LGTM

@kevans is now the maker of his own fortune as of rP542829

bsd.options.desc.mk changes are not blocked by anyone, the file is explicitly available for anyone to commit to. update reviewers accordingly

@kevans is assisting me with my mentorship duties, to otherwise unblock this review/change, because I am super occupied for at least a week

MFH candidates are not 'explicitly' or only in the domain of the maintainer

In D25391#563016, @dbaio wrote:

Hi @koobs , about the MFH, I don't mind in MFH it to 2020Q2 branch, but soon we will have 2020Q3.
Do you have other concerns here?

And thanks for taking a look.

How awesome are you, thank you so much :D

Missing MFH: <branch|No> <reason> and Approved by:

In D25391#560268, @koobs wrote:

Thanks for this!

Missing explicit QA confirmations in TEST PLAN section and please add Approved by: ??? and MFH: <branch|No> <reason> to Summary commit log message

Ping @bapt

In D24937#560621, @neel_neelc.org wrote:

I have a new patch making net.iflib.tx_update_freq a sysctl. I attempted to net.iflib.tx_update_freq=32 from 16 (without rebooting!) and it worked.

Luckily with a brand-new and fast dev box, I could compile and test quickly.

Might there be ways to make this run-time tunable, or is it fundamentally not possible even in principle?

@loader Let's get this sorted/complete so we can concentrate on graduating you (See D25395)

Congratulations Kyle, you've been an excellent mentee (I'm not surprised) and its been my pleasure!

Thanks for this!

Should separate out the maintainer such from the rest such that it can be MFH'd to quarterly so that MAINTAINER is consistent between branches

Nice work~

For future reviews/commits, always good to mention whether something is a MFH: <branch> (reason) candidate or not MFH: No (reason)

LGTM, nice work @loader!

Oh btw, did the tests pass? :)

Nice work.

In D24816#546375, @tagattie wrote:

Update the patch to address the inline comments.

Regarding testing, the port seems to require pyxattr and pylibacl. However, pyxattr cannot seem to compile (on FreeBSD 12 amd64).

I'd ask portmgr explicitly about PORTEPOCH. It would be nice to remove if it can be. There are few opportunities to do that, so worth taking that time while other change are being made.

Approved by: koobs (python, maintainer)

Python Porting Policy

In D24743#544856, @dbaio wrote:

In D24743#544817, @koobs wrote:

iirc mock is just a test dependency, incorrectly specified in install_requires instead of tests_require. It would be nice if upstream removed it. Personally I'd just leave it in the main port for now, until that's done

simple and harmless, thanks

iirc mock is just a test dependency, incorrectly specified in install_requires instead of tests_require. It would be nice if upstream removed it. Personally I'd just leave it in the main port for now, until that's done

• If quarterly is also affected (I assume it is), please add MFH: 2020Q2 to commit log message
  • If there are any existing open Bugzilla issues, please include PR: references as well
  • Re QA, if you haven't already please confirm that !arm architectures also successfully build with this change

Looks fine other than the different syntax than other areas of the ports framework

Bugzilla issue 244212 mentioned several CVE's associated with this update.

• TEST PLAN section empty
• Since this is a version update, needs Approved by: <maintainer>) or maintainer timeout (I added this to Summary section)
  • At the moment, reviews without accompanying Bugzilla issues can't be ''maintainer timedout''
• These are all bugfix/maintenance releases, is there a reason not to MFH?
• I tend not to enumerate changelogs entries in ports commit log messages themselves, unless specific entries re FreeBSD are indicated.

New port commit log format:

LGTM, nice root resolution and one less port with specific compiler dependency

Approved, please add clear ($reason) to MFH

So this fixes a runtime issue when built with Clang/LLVM, but that was mitigated with/by USE_GCC ?

Thanks for this @andrew_tao173.riddles.org.uk

Background on request/motivation:

Approval for FLAVORS for x11-toolkits/guile-gnome-platform please portmgr

Otherwise accepted. Thanks @kevans!

I added (blanket: build fix) to MFH line. This positive note allows ports-secteam not to manually respond to the automatic MFH email to approve it, since its blanket

LGTM, but passes QA? TEST PLAN is empty