Requesting review from rust

Looks good, modulo adding numpy to TEST_DEPENDS

The package (sdist) ships with tests: In these cases add TEST_DEPENDS and a (do)-test target so runtime QA can be executed easily.

Separately, I note upstream docs for installation on FreeBSD are outdated: https://docs.wand-py.org/en/0.6.7/guide/install.html#install-wand-on-freebsd

Note: @sunpoet took maintainership in dc41320718b8

In D32031#741436, @diizzy wrote:

Change DOCS_BUILD_DEPENDS to >=0
USES= python is the same as python:3.6+ ( https://cgit.freebsd.org/ports/tree/Mk/Uses/python.mk#n27 )

In D32031#722834, @diizzy wrote:

fwiw, I see this at the end of the build but these errors seems to be bogus?

...
===> Creating unique files: Move MAN files needing SUFFIX
===> Creating unique files: Move files needing SUFFIX
====> Compressing man pages (compress-man)

Do emulators/wine and emulators/wine-devel in quarterly support i386? If so:

Thanks Felix!

Ping portmgr

Additionally: Should we move games/lwjgl to games/lwjgl2 leaving the portname open for this, or are both 2.x and 3.x going to be long-lived concurrent branches in the long-term?

Does lwjgl3 have a test suite? If so, it would be great to hook it up in a test target with TEST_DEPENDS where necessary

Already accepted :) Nice work @Alexander88207_protonmail.com

Thanks for this Charli

Pending QA confirmation LGTM 👍

• Does this pass QA (portlint (and or portfmt) and poudriere?)
• Replace hard-coded /usr/local with PREFIX [1]

• Is the current SUMMARY the complete proposed commit log message?
  • Is this a bugfix release? Will it be MFH'd?

In D31782#718519, @kai wrote:

In D31782#718446, @koobs wrote:

I'm -1 on a new/separate variable, and maintain that having an expiration date (end-of-life etc) being 'deprecated' (now) logically and semantically makes sense. The reason why porters handbook
says otherwise [1] is because these variables have ports/framework/implementation specific meanings, somewhat more overloaded than a pure metadata or only-descriptive definition. For example EXPIRATION_DATE is used to delete ports, where from a maintainer perspective, its valuable to be able to describe an end-of-life date at any time, all the way from port creation to the time its deleted. This would for example allow for automatic 'messages' to users as they 'approached' that date, progressively getting 'stronger' as they got closer.

[1] "It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, recommending a newer version of the port), but the converse does not make any sense."

Ah, ok, I got somewhat misled by the phrase I wonder what breaks if EXPIRATION_DATE is set without DEPRECATED. :) from https://reviews.freebsd.org/D30977#700968. :)

Of course, this makes sense, provided that an EoL date is known from upstream, to put it into DEPRECATED without an EXPIRATION_DATE in a timely manner. A new variable would then be completely superfluous.

• Use upstream language in messaging (this is distinct with ports descriptions/uses of variables)
• 3.6 is currently in security 'maintenance status', and has an 'end-of-life' date of 2021-12-23
• Link to upstream refs where they exist and are beneficial to the user

I'm -1 on a new/separate variable, and maintain that having an expiration date (end-of-life etc) being 'deprecated' (now) logically and semantically makes sense. The reason why porters handbook
says otherwise [1] is because these variables have ports/framework/implementation specific meanings, somewhat more overloaded than a pure metadata or only-descriptive definition. For example EXPIRATION_DATE is used to delete ports, where from a maintainer perspective, its valuable to be able to describe an end-of-life date at any time, all the way from port creation to the time its deleted. This would for example allow for automatic 'messages' to users as they 'approached' that date, progressively getting 'stronger' as they got closer.

• Use terminology upstream uses
• Link to the upstream url so users have details
• Mention the EoL date(s) in the message
• 'Has expired' is not accurate/correct semantically, particularly for a port that hasn't reached the EXPIRATION_DATE yet.

Ping portmgr

No objections, lets just explicitly include/explain that in the commot log message, and include any upstream references (if they exist)

Forgot one other thing in previous review. dtrace has been an option in Python for a (long) while, and we would want to add this option across all relevent Python ports

Question, are these the port changes logically related in some way, or need to be committed together, or just as a convenience in a single differential revision?

Format Summary like a well-formed commit log message, in this case two of them, and include QA in test plan section:

@madpilot Yep, sure, those are the things that just stood out to me as odd, or in need of improvement.

Ping on portmgr

Thanks you for rebasing/updating this differential Derek. Minor update request (MOVED reason)

man iwn shows the 8265 is now supported:

Apart from requiring new copies of django ports for each supported version, where proper django support in the framework would be preferred, the change good @kai

Note also that with poudriere you can easily test i386 (and other ARCHs) on an amd64 host, which uses jails. If you need help #freebsd-ports @ Libera IRC

@me_cameronkatri.com Could you provide this change (new port) as a diff against the existing games/lwjgl port and add a comment regarding patch-build.xml and why its necessary.

@danilo 👍 just update the test plan section to mention those combinations that were tested

@loader This can land if its all up to date (now that the shared options description change has landed)

@dereks_lifeofadishwasher.com Can you check if this still applies and update it if necessary? @danilo is current maintainer and can handle resolution

Change looks good. Can we confirm successful QA for the three supported modules, by forcing BUILD_DEPENDS on them so it can be tested in poudriere

@loader Thanks for adding everyone to review. Commit does not block on maintainer approval.

If you'd like, feel free to email maintainers privately as a heads up (in case they don't notice).

I'm happy if you're happy. Ship it when ready :)

In D30475#691877, @AMDmi3 wrote:

Latest change from python39: https://gist.github.com/54c25485e2052743c6f8bdd85f56452e
Please state clearly which changes are still required to get this landed.

All looks good, except:

Technical Approved by: portmgr (blanket: ports / python compliance) but if you'd like to wait for @sbz that's fine :)

ISC DHCP client/relay end of maintenance:

In D30475#691792, @AMDmi3 wrote:

Patch against python39:
https://gist.github.com/99f0226febf227ca49b6133b3b8cb1da

See minor comments to clarify before landing this. Would still like to see this as a diff against the port it was based on

In D30651#690197, @sbz wrote:

Thanks @loader, just a minor nit in your commit message, it should be (full URL and no underscore for tags):

Differential Revision:        https://reviews.freebsd.org/D30651