net/bone-utils: Add port

[dave_freedave.net]

Summary

This adds utilities for working with the netgraph nodes provided in net/bone-kmods.

Test Plan

I use jeiface and ngportal via jail.conf to create and destroy numerous wormholes per day.
I use ngpcap while developing new netgraph nodes.

Rather than go through everything I'll point back to D50245

[adamw]

net/bong-utils/Makefile

21 ↗

(On Diff #176893)

I mean, if it needs exactly those two to build and exactly those two to run, then I absolutely get the intent. It's not wrong per se, but I want you to think it through first.

Ask yourself: what situation are you guarding against?

Let's say bong-kmods is installed but the first header is missing. What will the framework do when it goes to build this port?

27 ↗

(On Diff #176893)

As in bong-kmods, why a hash instead of tagging a release?

29 ↗

(On Diff #176893)

What does this line accomplish?

[dave_freedave.net]

net/bong-utils/Makefile

21 ↗

(On Diff #176893)

Yeah I have a long history with more primitive implementations of make. With those the right thing was always to give make as much info as possible and let it decide. But only one is needed will fix

27 ↗

(On Diff #176893)

yeah I'll go make some tags. I got no reason not to.

29 ↗

(On Diff #176893)

nothing. and it will be pulled out of both. funny (now) story. i didn't see uidfix and was manually changing my makefiles so that UID/GID wouldn't blow up. I somehow missed uidfix when looking at other examples. I had patches for every makefile before I saw that.

[adamw]

net/bong-utils/Makefile

21 ↗

(On Diff #176893)

It's a perfectly valid (and not uncommon!) pattern, but there's a tradeoff, and it doesn't do what most people who use it are intending for it to do.

Ostensibly, it's guarding against a build or install failure, right? If one of the headers (or a library) from the kmods port is missing, the framework will dutifully build and attempt to install bong-kmods. But because it's already installed, it will produce.... a build or install failure.

So, this approach doesn't actually guard against a build or install failure, what it does is change the error and make it occur earlier. In this case, the user will get an error about bong-kmods already being installed. With only one BUILD and RUN dependency, they'd get an error about a missing header or a missing library.

It's NOT an anti-pattern, so there's no requirement to change it. The decision point for you is which type of error you're more comfortable with.

27 ↗

(On Diff #176893)

As with the double-listed dependencies, it's not *wrong* and there's no requirement to change it. I'm thinking about it more from a UX standpoint. I'm automatically suspicious of ports based on hashes, because I don't know whether upstream is trying to tell me that the code's not ready.

29 ↗

(On Diff #176893)

Aha, that makes sense. It's been a very long time since I've seen that pattern in a port, so it definitely caught my eye!

[dave_freedave.net]

• create MY_DEPENDS that depends on port/pkg not header/kernel module
• have BUILD_DEPENDS and RUN_DEPENDS refer to MY_DEPENDS
• remove GH_TAGNAME it has calver release tag now.
• update pkg-description with acronym

Also now I remember: without the release tag you can't do bong-kmods>=0 so I went with file dependencies.
Another reason to create tags and not use GH_TAGNAME.

[dave_freedave.net]

poudriere testport -j FreeBSD15 -p local net/bong-utils output:

bong-utils-2026.05.03.log29 KBDownload

[dave_freedave.net]

s/bong/bone/g

[dave_freedave.net]

this has to use matching FLAVORS with net/bone-kmods

[dave_freedave.net]

I found this thread when trying to find a way to have bone-utils depend on any flavor of bone-kmods. Doesn't appear possible. This change achieves bone-utils depends on bone-kmods and bone-utils@invariants depends on bone-kmods@invariants.

It just isn't satisfying since the two bone-utils packages will literally be bit-for-bit identical and only differ in package dependency. But I still think its better than having an option for bone-kmods.

[adamw]

In D56744#1305309, @dave_freedave.net wrote:

[...] the two bone-utils packages will literally be bit-for-bit identical and only differ in package dependency.

Is there any value in combining them into one port? Will users want the kmods without the utils? Combining them would mitigate the dependency question. Just food for thought.

[dave_freedave.net]

In D56744#1305345, @adamw wrote:

In D56744#1305309, @dave_freedave.net wrote:

[...] the two bone-utils packages will literally be bit-for-bit identical and only differ in package dependency.

Is there any value in combining them into one port? Will users want the kmods without the utils? Combining them would mitigate the dependency question. Just food for thought.

I am considering this. And I think the answer is I should look into this before we merge either one. Its also an excuse to create a combined github repo calsed "bone". Give me a few days to look into combining things. I bet its doable. And while the kmods are valuable without utilities, maybe that's where the port option lies, having a utilities be optional.

[dave_freedave.net]

Switch to new mono repo for bone-kmods/bone-utils

This one doe NOT have flavors. It also has neither a build dependency (mono-repo means it has its headers) nor a runtime dependency. Now ngportal(8) and ngpcap(8) will be useless without the appropriate bone-kmods. They will err out. But in the same way ngctl(8) does if you try to mkpeer with a non-existent node.

This is a compromise. This means there is only one package flavor for bone-utils and it doesn't care which (or even if) you installed bone-kmods.

@adamw I know you haven't had a chance to reply to email but I figured its easier to show you what I mean here than try to describe!

[dave_freedave.net]

I'm sorry about the long delay I updated my ports tree (yes I know ccache is the answwer).

I can verify that this port behaves reasonably without having bone-kmods:

# pkg info | grep bone
bone-utils-2026.05.13          Collection of netgraph utilities for bone-kmods
# jail -i -c name=test host.hostname=test.example.net vnet persist
1
# ngportal :wh0a test:wh0b
ngportal: kld_ensure_load: unable to load kernel module "ng_wormhole": No such file or directory
# jeiface test tst0
tst0
# pkg install bone-kmods
...
# pkg info | grep bone
bone-kmods-2026.05.13.1500506  Collection of netgraph kernel modules
bone-utils-2026.05.13          Collection of netgraph utilities for bone-kmods
# ngportal :wh0a:br1:link test:wh0b:tst0:ether
# ngctl show wh0a:
  Name: wh0a            Type: wormhole        ID: 0000000f   Num hooks: 2
  Local hook      Peer name       Peer type    Peer ID         Peer hook
  ----------      ---------       ---------    -------         ---------
  evthorizon      br1             bridge       00000004        link0
  jid=1           wh0b            wormhole     00000003        jid=0
# ngctl -j test show wh0b:
Name: wh0b            Type: wormhole        ID: 00000003   Num hooks: 2
  Local hook      Peer name       Peer type    Peer ID         Peer hook
  ----------      ---------       ---------    -------         ---------
  evthorizon      tst0            eiface       00000002        ether
  jid=0           wh0a            wormhole     0000000f        jid=1
# jail -rv test
test: removed

So I'm pretty happy with where we have ended up.

[dave_freedave.net]

update DISTVERSION

[dave_freedave.net]

poudriere testport -j FreeBSD15 -p local net/bone-utils

bone-utils-2026.05.16.log31 KBDownload

attaching recent poudriere test build.