www/pocketbase: Update 0.40.4 to 0.40.5
Changes:
- Minor improvements for the JSVM migration error handling
- Updated modernc.org/sqlite to 1.60.1
- Bumped the min Go GitHub action version to 1.27.2
Full list of changes:
https://github.com/pocketbase/pocketbase/releases/tag/v0.40.5
Switch MAINTAINER to my FreeBSD.org address.
Approved by: jrm (mentor)
Differential Revision: https://reviews.freebsd.org/D60609
wxGTK32: updated to 3.2.12
3.2.12: (released 2026-10-10)
All:
- Update Unicode mapping tables to current versions (Scott Talbert).
- Add wxPATH_RMDIR_PARENTS flag to wxFileName::Rmdir().
All (GUI):
- Handle mouse capture loss when using wxContextHelp (Richard Thomson).
- Always recognize common file types in wxHTML (Richard Thomson).
- Respect background colour when printing in wxHTML (Richard Thomson).
- Fix handling of image map coordinates in wxHTML (Richard Thomson).
- Don't show modal HTML help window for not found topic (Richard Thomson).
- Recognize "Dstrok" as an entity in wxHTML (Richard Thomson).
- Fix XRC unknown-control size hints after attaching (Richard Thomson).
- Fix handling spacing in wxGridBagSizer (Richard Thomson).
[21 lines not shown]
zig: updated to 0.17.0
0.17.0
Notable changes:
aarch64-openbsd is now tested natively in Zig's CI, ensuring high-quality support going forward.
aarch64-freebsd and aarch64-netbsd CI jobs now run on pull requests too, in addition to master pushes.
An LLVM bug that broke most aarch64-windows binaries, including the Zig Compiler, has been worked around.
The Zig Compiler now applies mandatory code hardening techniques when targeting aarch64-openbsd so that the resulting binaries actually work.
Zig now provides stack traces on crashes and failed assertions on 32-bit ARM. Some work still remains for Thumb-only targets.
Zig now provides stack traces on crashes and failed assertions on SPARC.
Zig now handles pointer authentication opcodes when doing stack unwinding on AArch64.
Support for the loongarch32-linux-gnu[sf] targets has been added.
Zig now has generally usable support for 64-bit SPARC, and especially sparc64-linux. This is largely thanks to Zig's new ELF linker which now has better support for this target than LLD.
The Zig Standard Library has been ported to the x32 and N32 ABIs on x86-64 and 64-bit MIPS, respectively. These are niche ILP32 ABIs that allow using the 64-bit instruction set while only having 32-bit pointers - the idea being to trade available address space for lower memory usage and better cache utilization.
Target information has been added for some game consoles: aarch64-switch, arm-gba, mipsel-psx, and powerpc-wiiu
Very early xtensa-linux support has been added to Zig. Note that, for now, this support can only be exercised via the C backend or the experimental LLVM backend.
The Zig Standard Library now has support for arc[eb]-linux, csky-linux, and m88k-openbsd when using the C backend.
[18 lines not shown]
Simplify iterator lowering and trim duplicate tests
Use capture-only iterator callbacks and bind induction variables as block
arguments are created, eliminating the temporary induction-value vector.
Remove unused-iterator HLFIR cases covered by the per-locator and LLVM
checks. Reduce repeated stride diagnostics and remove unused declarations
from the positive AFFINITY tests.
safe_eval.sh fix description of safe_set_var returns.
The description was out of sync wrt return values.
1. invalid var
2. invalid val
3. var not in allowed list
pocl: updated to 7.2
7.2
Highlights
Support for LLVM version up to 22 with CUDA and LevelZero devices
Support for LLVM version 22 & 23 with CPU device
Minimum supported LLVM version raised to 18
Official OpenCL 3.0 conformance achieved using OpenCL-CTS tag v2026-03-25-00, with the CPU device running on RISCV and x86-64 CPUs.
CPU driver gained support of a few new extensions: cl_khr_extended_bit_ops, cl_khr_device_uuid,
cl_khr_suggested_local_work_size, cl_khr_integer_dot_product, cl_khr_kernel_clock, cl_khr_spirv_linkonce_odr,
cl_khr_spirv_no_integer_wrap_decoration ; additionally, support for program-scope variables has been re-enabled.
py-numba: updated to 0.68.0
0.68.0
This is a major Numba release. Numba now supports Python 3.15. This release
also expands Windows ARM64 conda packages and wheels from Python 3.12 through
3.14. Linux x86_64 and aarch64 wheels are now tagged to be compatible with
GLIBC >= 2.27.
safe_eval.sh: add safe_set_var
Get the log message right!
Fix default allowed chars (untabify clobbered TAB)
Add a couple more : messages to help debugging.
safe_eval.sh: add safe_set_var
Get the log message right!
Fix default allowed chars (untabify clobbered TAB)
Add a couple more : messages to help debugging.
py-numpy: updated to 2.5.4
2.5.4
MAINT: Prepare 2.5.x for further development
BUG: Reset an unrepresentable fill_value on a dtype change
BLD: work around MSVC 19.51 bug
BUG: fix np.strings.replace truncating old/new to a's
BUG: fix _ureduce reshape when a kept axis has size 0
BUG: fix two possible crashes in the ufunc.accumulate implementation...
BUG: Reset an inherited fill_value in MaskedArray.__new__ as...
ENH: Improvements and fixes for stringdtype hashing
CI: increase ppc64le timeout to match other timeouts
BUG: fix memory leak in legacy ArrayMethod wrapper code
BUG: check for non-finite input before calling gesdd/gelsd and...
BUG: fix segfault in as_arrays() on self-referencing pyscalars
TYP: Various typing improvements.
BUG: Fix canonicalization/promotion of nested subarray types...
MAINT: Update vendored-meson to match main.
[2 lines not shown]
Keep zettarepl's encrypted record call working on targets
## Problem
Replication sources call `pool.dataset.insert_or_update_encrypted_record` over midclt on the target to store the target dataset's key. That private method was removed when encryption moved to `zfs.resource.encryption`, so replicating to a target on this version would fail after the stream was received and leave the encrypted dataset without a stored key, meaning it would not unlock on reboot.
## Solution
Restored the private method on `pool.dataset` with its original payload, forwarding to `zfs.resource.encryption.store_key`. Also trimmed encryption docstrings that repeated the API model field descriptions and corrected which supplied keys get stored on unlock.
Unlock zfs resources through typed models
## Problem
Internal callers (failover, boot import, KMIP) started a private dict-based unlock job with its own private models, and results were read with dict indexing. Changing a key from a pipe also rejected valid keys with a leading zero, and change_key accepted keys and passphrases that ZFS would later refuse.
## Solution
- **Unlock**: `zfs.resource.encryption.unlock` gains `start_attachments`, and internal callers start the public job with `ZFSResourceEncryptionUnlockArgsData` and read the returned entry by attribute. `unlock_impl` is now the non-job implementation that takes the model and unwraps secrets once; pool.dataset.unlock calls it directly since it already holds the same job lock.
- **Change key**: the key must be 64 hex characters and a passphrase 8 to 512 characters; a key read from the input pipe is matched as hex text instead of round-tripped through int.
- **Cleanup**: shared `secret_value`/`ancestor_chain` and `is_internal_dataset_name` live in one place each, store_key receives the lowercase ZFS key format while hook payloads are uppercase, and the sync_keys failure is logged with its traceback.
Move dataset encryption to zfs.resource.encryption
## Problem
Dataset encryption still lived in the `pool.dataset` namespace even though `zfs.resource` is now the dataset API, and zr's own create path had to call back into `pool.dataset.insert_or_update_encrypted_record` to record keys.
## Solution
- **New `zfs.resource.encryption` sub-service** owning lock, unlock, unlock_summary, export_key, export_keys, export_replication_keys, change_key and inherit, with zr conventions (`path`, lowercase enums, `Secret` keys, `ZFS_RESOURCE_*` roles, audit). Public methods delegate to private `*_impl` methods for thread local storage, as the rest of zr does, and everything is synchronous except starting attachment delegates, whose API is async.
- **Private methods moved and renamed** (store_key, delete_keys, stored_keys, sync_keys, encryption_roots, encryption_state, replication_keys, encryption_root_mapping, unlock_impl), together with the `storage_encrypteddataset` model. Every internal caller (failover, pool create/import/export, KMIP, replication, zfs events, zr create) now calls zr directly; no `pool.dataset` alias is left.
- **`pool.dataset` encryption methods are thin shims** keeping their models, roles and pipes. They call the zr `*_impl` methods through the namespace with their own job, so no nested jobs are created, and they share zr's job locks so both APIs serialize on the same dataset. Error messages are unchanged; validation attributes now follow zr names.
- `unlock_impl` has a private Secret-typed accepts model so passphrases handed over by failover stay redacted in job listings.
- Hook names and payloads, including the uppercase key formats failover relies on, are unchanged, and nothing renamed is called across HA controllers.
Tidy dataset encryption naming and readability
## Problem
The encryption move left `zfs_resource` wording on the `pool.dataset` side (shared job lock names, the `zr_args` helper, "compatibility wrapper" docstring lines, a `PoolDataset` message raised from zr), and a lot of the moved logic was dense comprehension and `filter`/lambda one-liners that were hard to read.
## Solution
- Job lock names live once in `plugins/zfs/encryption_job_locks.py` with neutral `dataset_encryption_*` names, used by both `pool.dataset` shims and `zfs.resource.encryption`, so both APIs still serialize on the same lock per dataset.
- Shims build zr arguments with the existing `validate_model` instead of a local helper, and their docstrings no longer describe the wrapping.
- zr raises "Dataset {path} does not exist", and the key table model is renamed `EncryptedDatasetModel` (table unchanged).
- Comprehensions, generator expressions, `filter`/`map` lambdas and inline ternaries in the encryption code are plain loops and `if` blocks, with behaviour unchanged.
Type check pool.dataset encryption shims
## Context
The pool.dataset encryption methods are new code in this branch but were declared without annotation checks, so their bodies worked on raw dicts while the zfs.resource.encryption methods they wrap are type-safe.
## Solution
All shims now use `check_annotations=True` with signatures matching their models and attribute access in the bodies. Secrets are handed to the zfs.resource models as `Secret` objects rather than dumped, and keys or passphrases left out by the caller are passed as None. The option and result sub-models are exported from the API package so the shims can annotate with them. Wire arguments, results and errors are unchanged.
