In D58495#1345206, @markmi_dsl-only.net wrote:

A note on some terminology in the summary (and for the related commits):

In D58495#1342835, @ziaee wrote:

You do need to be subscribed to the list to post it. The format they prefer is the CVS equivalent, but I use git send-email and Ingo has never objected.

In D58553#1343846, @emaste wrote:

Have we explicitly decided that we won't MFC the googletest addition (as opposed to having just not gotten to it yet)?

Either way this change is correct for stable/15 right now, but I'd like to ensure that we either revert this along with an eventual MFC or make it clear that we should not MFC.

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.

i landed this a couple of weeks ago, it just didn't get auto-closed.

In D58495#1342419, @ziaee wrote:

Thanks for tagging me! We just mail the patch to tech@mandoc.bsd.lv. I can do it if you don't want to.

i was trying to avoid adding extra allocations for this group of patches, but i suppose this is not a performance-critical code path, so i'll switch it to use strdup if we think that's neater (i tend to agree, since __DECONST is at least a code smell).

i've asked dlg@openbsd.org about upstreaming this.

i think this should be upstreamed, but i'm not sure who's in charge of this -- @emaste?

this should be upstreamed. @ziaee how do you prefer to handle that?

this probably needs to be upstreamed - i'd like to land it in src to fix the build error in the mean time, though.

this breaks buildworld for me, i believe due to the changes in bsd.incs.mk:

we don't want to add manual dependencies on library packages; these are supposed to be handled automatically by pkg. if that's not working properly, it's a bug in pkg(8) and should be fixed there.

i can try backporting this to 15.0 (or maybe 15.1) and running it on a couple of BIRD routers here to see how that goes. that will take a few days though.

Relnotes: yes (although i doubt many people are using this, i do think we should highlight package moves like this).

seems to work fine with a basic pkgbase build, and i don't see any code changes that would cause issues.

this might be a good time to move this to the FreeBSD-efi-tools package. it's probably a bug/oversight that it isn't already there.

by the way, there seems to be a typo in the review title :-) (RTA_PERFSRC)

with D58305 + the new version of D58294, everything seems to be working fine, including with BIRD. (i only did cursory testing, though.)

In D58294#1337460, @pouria wrote:

1. Did you use the last version of this patch?

i've done some basic testing with this. IPv4 seems to work with both route(8) and BIRD. IPv6 works with route(8) but not with BIRD:

i'll try to test this later today. is this compatible with the Linux netlink API? it would be nice if it worked out of the box with BIRD.

In D56474#1317500, @markj wrote:

I don't really see how this is going to stay up-to-date: this seems to depend on developers remembering to update the file each time they add a dependency.

In D58287#1336898, @pouria wrote:

Thank you so much for your explanation @ivy

In D58287#1336891, @pouria wrote:

I'd appreciate if you could test this patch in your lab and see if it does really affect it or not.

In D58287#1336894, @pouria wrote:

Oh, so my original thought was correct, we don't need the ip address on the loopback, we only need its route to the loopback:

[...]
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=880028<VLAN_MTU,JUMBO_MTU,LINKSTATE,HWSTATS>
inet 172.23.1.101 netmask 0xffffffff broadcast 172.23.1.101

In D58287#1336891, @pouria wrote:

Same result.

In D58287#1336891, @pouria wrote:

With this patch, you're still able to do this.

i really don't like the filename /usr/include/profile.h, it's very generic and seems certain to conflict with something else in the future.

as an aside, for the ICMP case i believe you can work around this using the sysctl net.inet.icmp.reply_src=lo0 -- although i haven't tested this on a fully unnumbered interface, i would assume it works. but this doesn't affect outgoing non-ICMP connections, and it doesn't let you choose the source address per-interface, so it's not a replacement for the existing functionality.

In D58287#1336793, @pouria wrote:

Can you explain this please? The local address will be added as a loopback route anyway, with or without this patch.
Therefore, this should not break your use case.

In D58287#1336724, @pouria wrote:

Assigning the same prefix (e.g. in your case /32) to two different interfaces in the same FIB shouldn't be allowed.

i would rather not go with this approach as it will break my existing, functional network configuration:

this makes the sample commands more difficult to copy and paste for no clear benefit. i'm not sure this is an improvement.

sorry, i am unexpectedly busy irl. as you are more familiar with the docs style than me, it's probably easier for you to land this.

i've added mark's ZFS change and also documented this for the dist set path, as it's not pkgbase specific. i've added a new step for pkgbase to update the installed system, since we want users to be in the habit of doing this.

rf