boot.environment: replace zectl with the truenas_bootenv engine
The typesafe boot_environment plugin now calls the engine from the
truenas_pylibzfs truenas_bootenv package on the middleware
thread-local libzfs handle instead of shelling out to zectl. Mutations
serialize under an asyncio lock, the boot menu regenerates through
etc.generate('grub') behind a truenas:grub_pending marker that setup()
reconciles after a crash, activate rolls bootfs back when the menu
cannot be written, and the pool is synced afterwards so the menu
change is crash durable.
Re-activating the activated boot environment is allowed again as the
retry path after a failed menu regeneration; the api2 test asserting
the old rejection now asserts the retry succeeds. can_activate treats
a missing truenas:kernel_version as not activatable instead of only
the literal dash. The boot-time dataset promotion uses the engine
instead of parsing zfs list -j output.
NAS-141699 / 27.0.0-BETA.1 / fix duplicate From header in email (#19284)
`send_mail_queue()` updates the `From` address of queued messages with
`item.message["From"] = ...`, but `Message.__setitem__` *appends* a
second From header instead of replacing the existing one set by
`send_raw()`. The resulting message violates RFC 5322 and Gmail rejects
it with 550-5.7.1 "There are multiple From headers". Use
`replace_header()` so the flushed message keeps a single From header.
NAS-141699 / 26.0.0-RC.1 / fix duplicate From header and SMTP crash (#19286)
Two related bugs caused alert/test emails to be RFC 5322 non-compliant
(double From: header), which Gmail now rejects with 550-5.7.1:
1. When `fromname` is empty, `_from_addr()` returned an
`email.header.Header`; `Header.encode()` returns `str`, so the
`.encode().decode()` in `send_raw()` raised `AttributeError: 'str'
object has no attribute 'decode'` on every direct SMTP send.
`_from_addr()` now always returns `str`.
2. The failed message was then queued, and `send_mail_queue()` did
`queue.message['From'] = ...`, which *appends* a second From header
instead of replacing the existing one. Use `replace_header()` so the
flushed message keeps a single From header.
NAS-141699 / 25.10.5 / fix duplicate From header and SMTP crash (#19287)
Two related bugs caused alert/test emails to be RFC 5322 non-compliant
(double From: header), which Gmail now rejects with 550-5.7.1:
1. When `fromname` is empty, `_from_addr()` returned an
`email.header.Header`; `Header.encode()` returns `str`, so the
`.encode().decode()` in `send_raw()` raised `AttributeError: 'str'
object has no attribute 'decode'` on every direct SMTP send.
`_from_addr()` now always returns `str`.
2. The failed message was then queued, and `send_mail_queue()` did
`queue.message['From'] = ...`, which *appends* a second From header
instead of replacing the existing one. Use `replace_header()` so the
flushed message keeps a single From header.
PR/60362 (gdb can not insert breakpoints on aarch64)
Update aarch64-netbsd-tdep.c to use modern gdb initialisation method and
re-gen libgdb/arch/aarch64/init.c
[Hexagon] Use word splats for repeated HVX build-vector words (#204808)
buildHvxVectorReg packs small element vectors into i32 words before
using the most frequent word to initialize the HVX vector. For i8/i16
result vectors, the old lowering created SPLAT_VECTOR with the final
vector type, which selected a byte or halfword splat and broadcast only
the low part of the packed word.
The idea is to build the splat as a vector of i32 words first, then
bitcast back to the final vector type. This preserves the full packed
word while keeping normal byte and halfword scalar splat lowering
unchanged.
The test covers packed-word i8 and i16 cases, and also checks that true
i8/i16 scalar splats still lower to byte/halfword splats.
After testing with the SDK simulator, it looks to me like a larger
16-byte repeated-pattern case is still miscompiled after this change. It
appears to be a broader issue in this build-vector construction path, so
[7 lines not shown]
multimedia/qt6-multimedia: Mask X11-only headers
When the Qt stack is built with X11 disabled globally, certain private
headers should not be included in the final pkg-plist.
This does not affect the default settings, so not bumping PORTREVISON.
Reported by: angry_vincent on #freebsd-desktop
MFH: 2026Q3
[VPlan] Relax type of DerivedIV start value (NFC) (#206464)
Change it from VPIRValue -> VPValue, as several usecases require it,
while adding a check in the verifier.
[AArch64][InstCombine] Fold zext of all-active SVE cmpne-zero (#207720)
Fold zext(cmpne(ptrue, x, 0)) to umin(ptrue, x, 1).
Do not fold non-ptrue predicates, since cmpne zeros inactive lanes and
umin merges inactive lanes
[mlir] Fix RDV poison cleanup (#206270)
I moved the poison replacement step before cleanup paths that can drop
uses and leave queued operands temporarily null. This keeps region
branch operands valid while the later cleanup removes dead arguments and
results.
Fixes #206094
[clang][scan-build-py] Fix configure scripts when using Python 3.14 (#206792)
Python 3.14 (PEP 765) warns about return statements inside finally
blocks. This warning breaks intercept-build and friends for configure
scripts.
The bare except already catches everything, so falling through to the
return is equivalent and silences the SyntaxWarning.
runtimes: Don't set CMAKE_SYSTEM_NAME=Android
Cmake requires an NDK for android. Prior to 00b2f814182,
the default system name would be the host system. Take the
normal linux path, which is a more realistic approximation of
the old behavior.
cmake: Try to derive CMAKE_SYSTEM_NAME from unnormalized triples
get_triple_cmake_system_name() assumed a fully-normalized triple of the form
arch-vendor-os[-env] and read the OS and environment from fixed positions.
Unnormalized triples often omit the vendor and/or environment
(e.g. "aarch64-linux-android21", "aarch64-linux-gnu", "wasm32-wasi"),
so those fixed positions are wrong, and the function returned
bogus results, e.g.. "aarch64-linux-android21" -> Generic.
This was expecting to get a normalized triple by running clang -print-target-triple,
but that may not always work.
Scan all triple components for the known OS and environment tokens instead of
reading fixed positions. Ideally we would have a full triple normalization
function in cmake that mirrors the normalization in Triple.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[LV] Handle swapped blend inputs in predicated partial reductions (#208013)
Addressing case missed by #194859.
Detect the reduction update by checking both incoming values to
determine which is the single use incoming blend value, rather than the
previous approach which always assumed this would be incoming value 0.
