Thanks, that makes more sense. Updated the diff now, and also removed an unnecessary check against DOING_TINDERBOX because rm -f succeeds when the file doesn't exist anyway.

Anything else here? Should be good to go.

This commit seems to break the https://ci.freebsd.org/job/FreeBSD-main-amd64-test/28201/testReport/junit/sbin.tunefs/tunefs_test/suj/ test in CI. Locally reproducible with the following Bricoler (master-python branch) command:

Superseded by c0d9a07101a1e72769ee0619a583f63a078fb391

Superseded by 7e509d50854e3f2ba38be3a5e640088c010333af

How about this instead? This keeps the old behaviour by default
for backwards compatibility.

Applied feedback in v2.

Thanks for the feedback, this approach looks good. I've tested it with 2000+ runs,
the flakiness is gone.

Since this is accepted, can we land this? There is a new upstream 0.9.4.

Any comments on this change?

In D55789#1276669, @jfree wrote:

In D55789#1276630, @markj wrote:

A bit tangential, but: we found a while back that it was possible to trivially livelock a core by scheduling timeouts of 1ns using EVFILT_TIMER or setitimer(). Basically, it takes longer than the callout interval to execute the callout handler, so the callout handler ends up running in a loop.

I should note that the current timerfd implementation fails to pass the timerfd__periodic_timer_performance test, which expects 400000000 individual nanosecond timeouts. I usually see 360000000 - 380000000 timeouts printed by the test case. I'm not sure if this performance issue is related to the core livelock in some way. The callout routine (timerfd_expire()) is fairly lightweight, specifying absolute expiration time with maximum precision (no C_PREL() or pr specified).

Isaac, let me know if you want to take over maintainership of this port for the long run. But if not, I'd be interested in keeping it going on the FreeBSD ports side.

Thanks! Also noticed that wireplumber needed an update, so sent the review out for that. I'll commit the two of them together.

Oops, fixed missing files/ncursesw.pc in v3.

You can just cat all these patches into a giant one and put it under files/, though.

@aokblast this commit breaks the following tests in CI:

How about this? I think keeping the static_cast instead is more consistent with the rest of this source file.

Fixed weird whitespace in v2

I think the convenience is nice for sure, but the flexibility of choice is reduced. If anything, maybe I can add a variable similar to FAILFILE that is configurable so that users can choose where it goes?

Thanks, abandoning this review in favour of D55800 and D55803 by the author then.

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