What's the KBI impact of this? Does it need a __FreeBSD_version bump then? Would it make sense to add it to the end?

@bz Let me know if you've got any time to look over these changes. Thank you!

good catch!

verified, stack now has 3 commits

looks good, please add a second diff in the stack that increments sys/param.h __FreeBSD_version from 1600019 to 1600020 and add a quick note in UPDATING that the new video refactor has landed and sys/videoio.h is now provided as the API to communicate with it.

Review feedback

I am dropping this reviews, since the approach is wrong. A proper solution will be suggested in another one.

In D58792#1349067, @inquire_JohnEricson.me wrote:

Oh I didn't mean a real-world test with actual xorg, I meant a small test of connect/connectat itself ensuring we get the correct error code.

See D58406 for the sort of test I'm talking about.

In addition to the two cleanup tasks for later today (eliminating FONTCONFIG_FILE and setting only FONTCONFIG_PATH plus eliminating BRAVE_WIDEVINE substitution), I propose we move from GL rendering to vulkan when the wrapper detects it as viable (passing --use-angle=vulkan).

In D58792#1349067, @inquire_JohnEricson.me wrote:

Oh I didn't mean a real-world test with actual xorg, I meant a small test of connect/connectat itself ensuring we get the correct error code.

See D58406 for the sort of test I'm talking about.

In D58339#1343137, @ivy wrote:

I don't believe this is a bug in pkg(8). I reviewed a very long log file (with -dddd) and confirmed that library dependencies are not used during the scheduling stage.

that's the bug: a package's dependencies should be installed before the package itself. there's no reason for this to be different with shlib dependencies, especially since that will break many/most post-install scripts.

In D58784#1349097, @iwtcex_gmail.com wrote:

I don't exactly enjoy my time trying to understand LLM dumps on the bug tracker. That itself is pretty rude.

I don't exactly enjoy my time trying to understand LLM dumps on the bug tracker. That itself is pretty rude.

add more symbols

In D58784#1349069, @arrowd wrote:

dteske removed a subscriber: iwtcex_gmail.com.

What's this about?

In D58780#1349075, @monwarez_mailoo.org wrote:

Have you tested the impact with ports like:

games/linux-steam-utils
www/linux-widevine-cdm
emulators/wine-proton
emulators/libc6-shim

By testing I mean that steam should still run,
Games that was running with wine-proton before should still works, games that was running with either lsu chroot option should still works if they were working before.
For widevine, drm content should still be playable after this patch.
For libc6-shim, I guess that it is already tested with steam, but I would assume that if cuda was working before, it should still works after.

In D58788#1348937, @bnovkov wrote:

In D58788#1348916, @markj wrote:

Thanks, I've run into this problem too.

Rather than forwarding signals, why not have a pipe shared between the two processes? The child process can use it to detect when the parent goes away, and exit automatically. That should be simpler and will work for all cases where the parent exits (assertion failure, SIGKILL, etc.).

+1 for this approach, it's more robust than forwarding signals. I was planning to implement this pipe-based fix soon, but if you have the time and will to do so please go for it!