In D30661#689063, @arrowd wrote:

I'd agree with @skozlov here. IIRC, it is even recommended to use GitHub releases instead of tags, if releases are available.

Looks good. Approved if it passes QA for different values of USES=ssl (base, ssl, libre), otherwise add blocks to BROKEN, or IGNORE them, or report issues accordingly

Could you update review summary (proposed commit log message) & test plan (list of qa tests run), for our future selves

In D30475#688272, @AMDmi3 wrote:

Apart from the hard-coded version in MASTER_SITES (minor)

Fixed. I've hardcoded it as it would have to be changed anyway for release, but with cutting away prerelease suffix it would work for both pre- and release versions.

What's the explanation for the NEWOPENSSL variable? Is the behaviour the same with ports versions of openssl, libressl?

python310 does not support archaic openssl from 11.x and fails to build crypto related modules there. The same for libressl. But with openssl from ports it's good even on 11.
I've updated the condition. Not sure if it should be BROKEN instead or should output some kind of warning.

Also the LIBFFI option needs to be removed, originally only done in python37 see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244782

Outstanding/open PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256141

Done.

Can this be run through complete QA?

What do you mean by "complete QA"?

The threshold to commit isn't really no objections, no?

The approval may not be required but as you can see this review led to some improvements.

In D30475#687859, @AMDmi3 wrote:

This is now ready to land. I take it as there are no objections?

In D30475#687087, @AMDmi3 wrote:

In D30475#686878, @koobs wrote:

Is it possible to get this as a diff from python39 (or whatever its original source was)?

Available in the related PR https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256150, or do you need complete diff with plist?

In D30473#687107, @AMDmi3 wrote:

Thanks! This is now waiting for updates of 3 ports which break because of this change:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256308
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256307
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256306

Is it possible to get this as a diff from python39 (or whatever its original source was)?

@loader Looks good. Note you're implicit on all ports changesets, but its always good to get at least one independent review:

portmgr is not blocking. If this needs extra QA (exp-run), request via Bugzilla

• For changes that are not feature additions, MFH. For all differentials, so its obvious and explicit, add to commit log message (summary)

Looks good, nice work Alexander

Nice work Alexander. Minor case nit in COMMENT, otherwise looks good

Yep, rule of thumb:

One other note. When taking maintainer'ship or when combining multiple changes, land all changes that can be MFH'd first , and the version update separately.

Understood. Just be careful with PORTVERSION/DISTVERSION going backward for future tagged versions. See:

I've tweaked the commit log message. This change also comes under implicit

Can/should this port just be included (bundled as a dep) for www/pydio-cells?

Good to go mate

• Include all context/why in the commit log message. The entire differential summary should only need to ever be what the full commit log message will be, which includes all necessary detail for someone with zero knowledge to grok the full context of the committed change. I've updated the commit log message as an example of what I mean.
• fetch, build, run, package failures are always Approved by: portmgr (blanket: <type> fix). The same reason can be used for the MFH <reason>. Update commit log message accordingly

Capitalize "N" in COMMENT=nextgen but otherwise looks good

Does testport pass?

Bugfixes are:

@gerald mentioned a desire to find new maintainers for wine ports, so this is timely, thank you :)

@gerald mentioned a desire to find new maintainers for wine ports, so this is timely, thank you :)

Thanks for offering to take maintainership and supporting our Wine ports @Alexander88207_protonmail.com

In D29872#672742, @kbowling wrote:

In D29872#672741, @koobs wrote:

Just a Q: Are any of these changes likely to cause issues with respect to scripts / devd rules, or other 'automatic' things that might leverage these description? If so, is there anything in particular we might be able to do to mitigate that?

Hi, not that I know of. Because the names were all the same in a family, I predict most people would sooner script off of 'em', 'igb' before reaching for these unwieldy strings. It appears in dmesg during attach i.e. em0: <Intel(R) I211 (Copper)"> or sysctl dev.em.0.%desc. That could change now that they are more useful, but I would encourage folks to script off of PCI ID numbers before reaching for strings. Even the pci-ids database strings change frequently enough when corrections come in, but I do suspect people occasionally script off of those despite the lack of stability (i.e. pciconf -lv em0). Let me know if you find out anything different as I would like to MFC this after 1 month to stable/12 and stable/13.

Just a Q: Are any of these changes likely to cause issues with respect to scripts / devd rules, or other 'automatic' things that might leverage these description? If so, is there anything in particular we might be able to do to mitigate that?

FWIW, portmon has been dead due to 'python' for more than a few years. It is unrelated to 'latest Python updates' which is ambiguous.

In D29424#660866, @emaste wrote:

In D29424#660862, @koobs wrote:

Apologies, recent edits come up in RecentChanges so they tend to get more eyes and in my case, natural follow-up :)

No worries, better that it moved before commit :)

In D29424#660129, @emaste wrote:

@koobs moved the wiki page

Thanks @rmacklem :)

@rmacklem Good to commit if it passes QA

Also when (arc) creating reviews, include full context (I believe this is -C99999)

Change looks good.

Apologies, had to reset 2FA creds (lost) before I could login to review.

In D28135#639065, @lwhsu wrote:

@koobs If you really don't have time, how about passing maintainership to @nyan_myuji.xyz ? He has more changes planned and is willing to take care of this port. I will help him to land more patches.

@philip I may not have time to day, but the change is otherwise approved

@loader Feel free from now on to:

Nice work @loader!

@philip @lwhsu Thank you both for review. Feel free to commit this (pending adding upstream comments to patches).

This needs:

In the absence of poudriere (one should set it up), you can run the set of commands outlined here:

In D27778#623886, @adrian wrote:

hi!

In D27778#620891, @bofh wrote:

In D27778#620866, @koobs wrote:

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

All qemu-* ports needs to be updated.

Can I just try to land this one first, and worry about the others later? I'd at least like to see a working qemu port with user networking available for other freebsd users to test with.

For future reference sake: Ports compliance/recommendations require ports to 'unbundle' any bundled libraries (in this case slirp) except in cases where that is creates an unnecessary or inappropriate support or maintenance burden (such as go / node modules). We'll land this change in the short term until a slirp port can be produced

Also Question: do any of the other qemu-* ports need to have this change made too, or do they all inherit/child port off the main one (I haven't looked)

@adrian Can you confirm QA passes (portlint/poudriere, filling out TEST PLAN section) and add MFH: value <branch|no> <reason> in commit log message

LGTM

• Add <reason> to MFH: line regardless of value
• Any reason for not renaming the port per the upstream rename, or is the product name still the same with only the repo name changing?

Perfect :)