Is the "On FreeBSD" part redundant?

LGTM with or without the existing linux-firmware message left in place

With this change does the cross-compiled one now match the native one, or is it the other way around? It looks like we just mmap this file so I'm curious what will happen if the ordering changes.

LGTM with two little notes:

GCC's change, for reference: https://gcc.gnu.org/cgit/gcc/commit/?id=6271dd984d7f92

Fixes from @ziaee

Was committed in 6234a0bfc8630fc556295812c15d72bde0f6427a

Please upload with context (e.g. git show -U999999 or git diff -U999999) so that the lines in between the diff blocks can be expanded

Previous comment crossed paths with @olivier's update -- it seems we will need to revert the chroots and use DB_FROM_SRC and the similar support in etcupdate etc., all as done for the release artifact builds.

We're not going to break the running system, but chroot ${BE_MNTPT} make installworld could be more fragile than make DESTDIR=${BE_MNTPT} installworld if there's there's ever an error in installworld's install tools handling (see ITOOLS in Makefile.inc1). DESTDIR is used for installkernel. beinstall switched to using chroot in 16702050ac953d957a42fbc498e22c95078ad689 to fix "upgrading using beinstall past the new ntpd user change".

from generate-lua.sh to generate-lua.ucl.

looks ok

drm-kmod still has:

.  if ${OSVERSION} >= 1302000 && ${OSVERSION} < 1400097
RUN_DEPENDS+=   ${KMODDIR}/drm.ko:graphics/drm-510-kmod

I had a leftover compat.linuxkpi.80211.debug=0x00100000 in loader.conf

I'm getting a lot of these on my WIP kernel and am not sure if this is due to any in-progress changes or something in my wireless environment. That prompted me to look into the slightly odd-looking message format:

[428514.937200] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 7 100033 2575397956_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428514.937273] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 7 100033 2575397956_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428514.956024] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 4 100033 2575397974_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.238133] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 7 100033 2575398256_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.282541] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 5 100033 2575398301_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.354031] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 5 100033 2575398372_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.405563] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 3 100033 2575398423_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.573379] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 3 100033 2575398591_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.642131] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 1 100033 2575398659_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880
[428515.642251] LKPI_80211_TRACE_MO lkpi_80211_mo_wake_tx_queue:652: 1 100033 2575398660_hw 0xfffffe01810ae480 txq 0xfffff8000c5ff880

I'd recommend we not strip the tests out

This should address the remaining pkgbase nonreproducibility issue as a side effect https://github.com/freebsd/pkg/issues/2427

I think this is the only use of directories in pkgbase and as a side effect could address the last instance of pkgbase nonreproducibility - see https://github.com/freebsd/pkg/issues/2427 and https://tests.reproducible-builds.org/freebsd/dbd/repo/FreeBSD:15:amd64/current/FreeBSD-runtime-current.pkg.html

OK. For something that we expect might be used this is probably too verbose, but since we don't expect this to fire anywhere it won't matter.

I have no objection to this general idea but defer to @dim. I do think that there's value in having LLVM_ASSERTIONS enabled in head and disabled in stable branches in the coverage it provides in the window before the compiler makes it to the stable branch.

On the other hand, if a suitable JDK is already installed on the system, this will be used as the bootstraping JDK. This is no change from the previous behaviour. The only difference this patch introduces is that the bootrstrapping JDK, if it's needed, is not installed onto the system.

Slight clarification on comment -- MANIFEST provides checksums for the legacy dist sets

Combine with existing cross-build block

OK, but also curious why the ioctl is ..._WPAKEY for WEP support/warnings

You can use "Edit related revisions" to change the parent/child reviews

https://usb.org/document-library/hid-usage-tables-16

What's the reason for using Makefile.inc instead of just PACKAGE=smbutils in share/examples/smbfs/print/Makefile?

Discussed briefly with @kevans on IRC; the duplicate issues have been resolved with 269cbe092da38e1100df5008b664db89510c3604 I believe being the last one. I'm happy to go ahead with the switch to Lua and improve diagnostics over time.

Importing this via a vendor branch would indeed be the "correct" way to do it, but it doesn't much matter as the upstream is unlikely to see significant change from this point. I imagine this program is essentially complete. This is the way we've handled makefs(8) -- OpenBSD, NetBSD and FreeBSD all have copies with independent development and at this point OpenBSD and NetBSD are not really upstreams that we could use for contrib/.