Superseded by 56ce17a57a84d3de205162ba1ad2a64bd91ae18a.

If PKG_CREATE_THREADS_NUMBER <= 0, it gets kern.smp.cores || nproc. But aren't -T0 and -T$(sysctl kern.smp.cores) expected to mean the same thing?

1. 0 is a perfectly valid value for -T, as your comment notes. But if that's what the user requests, it gets overwritten by...
2. kern.smp.cores, which should be identical to just doing -T0 but with an extra shell call.

Committed in D55634 with f26cb4757eb74ceace39144933ae198ebf1b4f28.

Sounds good, I'll commit mine and show the warning in the commit message.

Ah sorry, I accidentally submitted a review for a similar thing, but I think BUILD_BUG_ON(swap) is cleaner?

Duplicate of D55554.

It seems that the test added by this commit is failing in CI: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/27898/testReport/sys.netlink/test_rtnl_gre/test_rtnl_gre/

Applied feedback, will commit this version.

I already have an update to an older development snapshot prepared and will work off that.

Thanks for the feedback. I like the plan of going ahead with emulators/rvvm-devel. I'd like to start using this in projects like Bricoler to speed up riscv64 CI and clean up failing tests, so tracking the latest improvements is important to me.

Cleaning out stale reviews.

Updated from discussion offline. I will commit this version instead. I will figure out a way to add "skip reason" metadata to Kyua in a future patch.

Added a comment pointing to the pkg origin of dhcpd

Thanks, will do. Abandoning this now then.

Closed by https://cgit.freebsd.org/ports/commit/?id=c4faf46ff4741f016c5196e1de77822733ff4a1f, I had linked the wrong review in the commit message, sorry about that!

Closed by https://cgit.freebsd.org/ports/commit/?id=919a4da7ff9794ffa53dbdd972ae25ec30368fa0, I had linked the wrong revision in the commit message so the automation didn't pick it up.

Removed python314 from this review, will post in a separate review.

Abandoning this revision since it's already merged in.

Does this have anything to do with Rust ports specifically? This review is tied to the deprecation of the --ar flag in Rust (which is documented to do nothing).

Yes, it passes a make test after successfully building in poudriere testport.

In fact, it looks like Uses/go.mk now has built-in functionality for make gomod-vendor, in the sense that we don't need to update the distinfo or *_TUPLE at all. It builds perfectly fine in a poudriere testport that restricts networking access after the FETCH stage.

Anything further for this review?

Abandoning old stale review.

Sure, I'll commit it then. Thanks for the approval!

Thanks for the clarification, I'll keep that in mind for future patches. I think for this case, it's better if you commit it as the maintainer, especially since I'm a new committer.

Here's an example from the attached full build log of devel/nextest:

Thanks! Although I don't have a ports commit bit yet, so you'll have to do it :)

Removed test suite after comments from D54668.

That reasoning makes sense, it's not worth it then. Abandoning this revision now. I'll change the meld update review to avoid adding a test suite.

Added better description and link to changelog for evidence, bumped PORTREVISION.

Sorry about the confusion. I had a patch ready to update meld locally that depended on this change. I have submitted it in the patch stack now.

Narrowed down review to purely need-driven changes in v2. textproc/meld needs this for its test suite to pass in a future upgrade.