Fix the title

I also see that we need an update, which I will also do after this lands.

I don't have AMD hardware to test, but the port changes look good. I like the sysutils/cpu-microcode-rc/files/pkg-message.in changes. Referring to the two methods as 'Early/Late loading' is clearer than the 'first/second method'.

Looks good. I'll commit with this log message unless there are objections.

Your approach of creating something here that is easier to review and referencing it in Bugzilla makes sense. There have been some recent investigations into switching our tooling to something that incorporates bug reports and reviews in one place.

I asked some doc committers on IRC to have a look.

Thanks. These are nice updates. I added a few mostly nit-picky comments and added a few other reviewers.

I don't have strong options either way. On the one hand, I can appreciate how this would confuse some users when they log in to a jail. On the other hand, I expect some users would miss seeing this information (by default) when they log in. While it may also be confusing, it's reporting accurate information that many would expect, i.e., version information about the running kernel.

Since this won't affect the official packages, and it's essentially the same as

.if ${PORT_OPTIONS:MBLAH}
RUN_DEPENDS+=	${LOCALBASE}/bin/bin:cat/port
.else
...
.endif

or

.if ${FLAVOR} == blah
LIB_DEPENDS+=	blah.so:cat/port
.else
...
.endif

it seems fine to me.

In D43770#999165, @imp wrote:

I can share the contract template with you. If there are any specific points about it not following project norms, I'll be happy to fix them, but again, I think these accusations are wrong.

I'd love to see the template. However, I make the comments in reviews they shouldn't do that, the reason proffered is because the contractors thought they had to do this for their contract. I've had this conversation many times, hence my grumpiness each time it comes up. I'd love to fix that issue, perhaps with better guidance in general that we could have in the project as well (and the template could refer to by reference).

In D43770#999126, @imp wrote:

In D43770#999112, @jrm wrote:

In D43770#999098, @cc wrote:

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

Thanks. This follows the contract text.

Consultant shall ensure that the copyright notice and license text attached as Exhibit B shall appear at the top of any new files that Consultant creates; and that the copyright notice and license text attached as Exhibit C shall appear at the top of any pre-existing files that Consultant significantly modifies during the course of providing the Services.

Yea, the Foundation needs to fix their contracts to be more in line with project norms. This isn't the first time it's come up. It just creates friction and provides no benefit because the project generally won't allow it for trivial changes.

In D43770#999098, @cc wrote:

Remove Copyright headnote and myself from if_iwn.c, as noted in review.

Ran poudriere testport for 13/14/15 amd64 with default options. Also ran it with all options on/off on 14.

The only failure I've seen so far is databases/emacsql-devel on 15amd64, but it also failed before the editors/emacs update from 29.1 to 29.2.

Abandoning this based on private conversations. @bapt is working on a real fix rather than this workaround.

I'm basically doing what the official repositories are doing, that is, building my own packages with poudriere. Bapt says this is a clang17+ ld behaviour change.

Without the PORTREVISION bumps, I see the issues below.

memcpy() d_reclen bytes rather than setting each field

Apply patch to all platforms

Looks good, but I see a build failure on 13i386. The easy workaround is to add NOT_FOR_ARCHS=i386.

Add missing path when adding to EXTRA_PATCHES

I lean towrads @rene's solution

Looks good to me. Thank you.

In D42900#980686, @emaste wrote:

We could perhaps address this by having daily_diff_flags="" by default (at least in what gets merged back) and use ${daily_diff_flags:-<whatever>}

Let me try stating my point another way, and please correct me if I'm wrong. People will see the new text in periodic.conf(5) and assume that they can customize daily_diff_flags, but when they do, it will have no effect.

I don't want to hold this up any longer, so don't let me stand in the way. That said, do we want to add an unused variable and document that it's doing something that it doesn't? In other words, this commit doesn't stand alone, unless I'm missing something.

Looks good to me.

I'm sorry to belabor this review longer. However, this commit *in isolation* seems strange to me. We are adding a variable and saying it controls how some periodic scripts are run, but that's not true because we are only defining (and documenting) an unused variable.

Thanks for catching that.

Looks good (assuming the commit title is updated). Thanks.

Seems fine to ignore these kinds of whitespace changes and have shorter emails by not providing diff context, but let's hear from a few others who have touched these files.