In D14819#351249, @0mp wrote:

I've reviewed the mdoc side of this change. Looks fine!

BTW, should we add some cross-references from other manpages to config.lua(8)?

PVE_NEXT() becomes unused in the kernel after the change. Might be move the macro to usr.sbin/pciconf for its only use ? Or change PVE_NEXT() to take the length.

The diff looks good. Did you checked that the current output is the same after your change?

In D14721#357180, @theron.tarigo_gmail.com wrote:

I propose a different possibility for consideration: Build Wine's 32-bit dependencies by invoking a sub-make which has had ARCH, PREFIX, LOCALBASE, WRKDIRPREFIX, and other needed variables and environment overridden to force the compilation of i386 libs and exes despite the build system being an amd64+lib32 installation. I named by PREFIX /usr/local/i386.

Fixed style issues

In D16404#356932, @kbowling wrote:

I've tested basic functionality (nvmecontrol, mount, bulk data transfers) on ppc64

Ping. I'd really like to have this one reviewed rather than relying on maintainer timeout since the previous version broke the build.

I added Justin and Nathan (who I meant to include from the start).

Thanks. This looks perfect to me.

There were a couple of changes which are largely cosmetic to do with #if logic. Change if you want, otherwise LGTM.

In D16743#357113, @manu wrote:

In D16743#357090, @jhb wrote:

This looks ok to me, but I'm not a ports committer so I can't approve it. :)

Do you know if we will need to exclude the plugins for the various devel/{amd64,i386,aarch64,mips,mips64,powerpc64,sparc64}-gcc pkg-plist files as well? That is, do they build cleanly now on arm64? Removing BROKEN_aarch64 from powerpc64-gcc/Makefile means all those packages will try to build on the next aarch64 package run.

Ah right, I just assumed that it was marked broken twice, I’ll run a poudriere on my aarch64 box when I get home and properly mark/fix the broken ones

Update powerpc-gcc plist too

Fine by me.

Adding Brad to at least know about it (CC). The WITH/WITHOUT options determine in a large part how many packages pkgbase will have and perhaps we can determine (with the help of this script) which of these options are obsolete or do not make a big difference. It's a bit tangential to this work, but maybe there is something useful in there that can be considered for pkgbase.

Looks good, thanks for working on it!

blacklist
don't reload unloaded drivers, part 2

Remove manual page for arc4random_stir and arc4random_addrandom.

My "LGTM" assumes requested changes are taken.

LGTM

Move handler prototype to SYNOPSIS.

Drop chacha_private.h and address various reviewer comments.

In D16785#357262, @brd wrote:

In D16785#357233, @will wrote:

Sorta weird to set an empty FILES=, perhaps bluetooth.device.conf should be moved first, so this file can be moved along with deleting the etc/defaults directory altogether.

We do it in many places already, is it worth worrying about for a few days until the other move happens? The bluetooth move is a relatively bigger move so I was waiting a bit for that.

I ran the packetdrill tests from rcv-data-segments and they all pass.

In D16772#356739, @hselasky wrote:

Can you explain the change with a few words?

In D16721#356744, @zeising wrote:

I'm not sure that the actual devices need to go into generic, perhaps they can be loaded by devmatch or similar. I haven't looked into this though.

Sorry for late response. Thank you for your help!