i'm curious why we have files with spaces in on the release to begin with. where do those come from?

looks fine from the pkgbase side.

In D59194#1357926, @dfr wrote:

I guess it could be a dependency of FreeBSD-ssh instead but adding it to FreeBSD-runtime covers both FreeBSD-ssh and e.g. openssh installed from ports.

use strdup() instead of __DECONST

In D58339#1349105, @vladlen wrote:

The reason is fundamental: it is technically impossible for pkg to know which package provides a required library in the new release

in pkgbase, we use " (debugging symbols)" for this. i think this change is fine to make the manifests consistent, but i wonder if it's worth changing everything to use the same term. (but with freebsd.org dist set builds going away in 16, this might not matter.)

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.