In D53350#1218507, @glebius wrote:

Can you please point me to how reproduce the problem? IMHO, we should just provide a KPI to register new sysevent_groups and pre-register them before the events.

Thanks!

Presumably tested, LGTM

Seems reasonable to me (from a flua perspective; I defer to bapt for nuageinit in general, of course)

Please be sure to include 0d4642a as Fixes metadata so that it's clear they need to go together both for MFCs and downstreams that might be consuming main.

Ahh, whoops- my bad!

We'll also need PACKAGE in libexec/flua/libfreebsd/Makefile.inc, but I think this covers everything else in main.

Whoops, good catch

In D52824#1213747, @des wrote:

@kevans did you get around to fixing the lua bootstrap issue?

Address review feedback; use stat -h and stop asserting on hole reporting

Add a create-kernel-flavored-packages level of indirection instead, which looks
a little cleaner

In D52904#1208870, @imp wrote:

This is obscure enough we may want to have a comment..

Noted in IRC, but needs to wait a minute until I land bootstrap flua and make the UCL generation stuff use libucl to avoid breaking cross-build of package repo from older freebsd with a broken libucl -- I'll try to make some time today

Add licensw from ncurses for description theft, add more words

In D52308#1205084, @emaste wrote:

Something like the patch below (applied to each virtual_oss subdir) works. It's gross, but we're already doing this in e.g. lib/googletest/gmock/Makefile

OBE

It does make me wonder about all of the freebsd11_* bits in the same file that we use for pre-ino64 stuff, but my main concern is just fixing initgroups(3) for stable/15... we can always haggle on any other details later, if we need to.

This fixes the AX210 in my frame.work that previously made it through association and DHCP, then stopped passing traffic. Thanks!

Yeah, I'm happy with that, thanks. I recognize this is maybe not ideal for more flexible system construction (piece together your own based on a set and removing some), but IMO we should err on the side of caution and consider whether we can do something to enable better behavior with the final form of pkg groups.

In D52562#1200178, @ivy wrote:

In D52562#1200173, @kevans wrote:

I think my complaint is that, iirc, all of the metapackage dependencies are marked as automatic. As soon as they break the set as you suggest, the remainder would be subject to autoremove

right, but if you run pkg remove FreeBSD-set-devel followed by pkg autoremove, don't you expect all of clang etc. to be removed?

if the user does this by accident then runs pkg autoremove, they will see it's trying to remove FreeBSD-clang or whatever and can abort and rectify the situation.

I think my complaint is that, iirc, all of the metapackage dependencies are marked as automatic. As soon as they break the set as you suggest, the remainder would be subject to autoremove

Yeah, this seems fine to me. I did wonder for a second if the /rescue variants of shells do or should assume setugid behavior and avoid loading dotfiles in case something in the profile or other bits finds a way to make the shell unusable, but I didn't really convince myself.

Account for origin not existing, use an empty string; add tests

In D52498#1199266, @tamelingdaniel_gmail.com wrote:

@kevans can you have a look at your patch in bug 266496? (link)
I think nvlist_lookup_string can also return non-zero if one uses "origin" as key and the boot environment doesn't have an origin data set.