is it helpful for me to test this? it's a bit awkward here due to the state of my VMs but i can do.

my comment about running update-packages without running buildkernel is still open, i don't think we should recommend that people do this (and i'm not sure it even works).

that depends on which version of libucl is in stable/15, which i don't know off hand. but if you like, i can MFC this along with the flua bits after testing it.

the commit message should probably indicate why this is being removed...

this looks okay, other than a couple of nits that i won't insist on. i do wonder if we want to be more explicit about how this affects pkgbase, but i don't think this is the right place for that.

this seems reasonable, and these lib32 issues are annoying, so i'd like to land this.

• build latest releng/15.0 on current main, update-packages fails
• apply this patch to the host, rebuild and upgrade
• build releng/15.0 again, this time it works

i'll run a test build now and let you know (this takes a couple of hours).

i think we need this for now, but we should back it out at some point to return to the upstream behaviour -- my preference would be after 15.0 is EOL (September), unless anyone prefers another plan.

• rebase on latest main
• fix license for lld and lldb
• use bootstrap flua in bsd.pkg.mk

btw, even if we revert that change, i think we should still land this commit: it's backward-compatible with the previous libucl (where flags just defaulted to zero) and it will be useful if we want to un-revert the libucl change later.

i briefly discussed this with kevans and he suggested we could revert the specific libucl commit which broke this[0] which i would be inclined to support.

In D56271#1287496, @emaste wrote:

I think this is sensible. Could this also be achieved via USE_STRICT_TMPPATH? I'd like to see that (eventually) become the default, and we could remove the PATH= setting then.

unfortunately, even if we land this fix, it will be impossible to build any version without the fix (e.g., 15.0 or 14.4) on a version post libucl 0.9.3. this is a rather less than ideal situation, so perhaps someone has a better suggestion.

other than one minor comment (that i won't insist on) this looks good to me now.

• rebase on a newer main
• fix the REPODIR issue (hopefully)
• add remaining arch-specific Makefiles

In D54548#1286203, @emaste wrote:

This seems like a good idea to me; will take a detailed look soon. Patch needs to be rebased.

In D56087#1286095, @emaste wrote:

It'd be nice if this review can be split into smaller pieces, but not surprising if there's no way to do so that makes sense.

i didn't report this, but i do think we should document it. about MFC, nothing changed here between 15.0 and 15.1, so it would be best if we can get it in prior to the 15.1 release.

fix remaining issues

i'm testing this now (which takes ~5 hours since i have to run two full builds) but i think it's correct :-)

also gate behind MK_CUSE, to match virtual_oss

i think it's okay to list src.conf changes in relnotes. there aren't very many of them, and it's the sort of thing users might want to know there -- there are some much less interesting things listed in relnotes.

i'll update RELNOTES after landing (i wish this didn't need to be a two-step process...)

closing in favour of the other diff

not tested, but this looks reasonable, thanks!

that sounds reasonable. note this blocks D56087, so i'm interested in the result.

In D56087#1283500, @jlduran wrote:

Thank you! It works well now (overall). There are a couple of things that fail on aarch64 (described inline). Other than that, this is great. Thank you!

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.