[libc][test] Fix dangling CString paths in copy_file_range_test (#241787)
Fixes the `aarch64` / overlay failure in
`libc.test.src.unistd.copy_file_range_test` introduced by #240018.
### Root Cause
1. `libc_make_test_file_path(...)` returns an owning `CString`
(non-copyable, non-movable). Storing it into `const char *in_path` /
`out_path` in `SetUp()` destroyed the temporary `CString` immediately,
leaving dangling pointers for `open()` and `unlink()` and causing
`ENOENT` in `SetUp()` (cascading into `EBADF` in `CopyNoOffsets` and
`CopyWithOffsets`).
2. `LlvmLibcCopyFileRangeTest::SetUp()` and `TearDown()` overrode
`ErrnoCheckingTest::SetUp()` / `TearDown()` without invoking the base
class methods.
### Changes
- Initialize `in_path` and `out_path` directly as fixture members using
`decltype(libc_make_test_file_path(...))` so the `CString` objects stay
[8 lines not shown]
[flang] Fix incorrect reallocation for host-associated main-program coarrays #231233 (#233361)
This fix resolves the issue #231233 involving incorrect reallocation of
a coarray when it is accessed via host association in a nested
procedure.
---------
Co-authored-by: Dan Bonachea <dobonachea at lbl.gov>
[Hexagon] Add local VTCM frames for HLX objects (#241650)
Move local HLX objects to a separate VTCM frame, address them through
VSP, and allocate and release the frame with vallocframe and
vdeallocframe.
Co-authored-by: Yashas Andaluri <yandalur at qti.qualcomm.com>
[flang][Semantics] Adding check integer kind on STAT= specifier #230463 (#231103)
This PR adds a pedantic warning to check whether the specified STAT is
an integer of at least 16-bit because
flang currently silently accepts 8-bit integers to `STAT=`: and F2023
9.7.4 says:
> R946 _stat-variable_ is _scalar-int-variable_
>
> A stat-variable should have a decimal exponent range of at least four;
otherwise the
> processor-dependent error code might not be representable in the
variable.
[SPIRV] Keep source location on OpAsmCallINTEL
insertInlineAsmProcess builds OpAsmCallINTEL with a MachineIRBuilder
whose debug location is empty.
The call therefore had no location, so the NonSemantic
debug handler emitted no debug line information.
sysutils/libmbus: [NEW PORT] Meter-bus library and utility programs
The Meter-Bus is a standard for reading out meter data from
electricity meters, heat meters, gas meters, etc. The M-bus
standard deals with both the electrical signals on the M-Bus,
and the protocol and data format used in transmissions on
the M-Bus. The role of libmbus is to decode/encode M-bus
data, and to handle the communication with M-Bus devices.
WWW: https://github.com/rscada/libmbus/
PR: 298095
Co-authored by: alven@
[Clang][NFC] Re-enable consumed analysis test for chained logical OR (#240849)
Re-enable the three-way logical OR test in `testComplexConditionals1` by
removing its `#if 0` guard and stale FIXME. The operands start in the
unknown consumed state. Keep all six existing expected warnings in the
true and false branches unchanged.
Prepared with assistance from Codex.
[Clang][NFC] Re-enable local-class static member diagnostic test (#240834)
Re-enable the local-class static data member example in
`clang/test/SemaTemplate/instantiate-static-local.cpp`. Keep its
existing `expected-error {{static}}`, remove the `#if 0` guard and stale
crash FIXME, and remove the conflicting `expected-no-diagnostics`
marker.
The crash was fixed by e2def106757534b07a2d3ff15ddd48e14b69a66d
(#182707). A targeted AArch64 snapshot search followed by native X86
assertions-on builds confirms the boundary: the parent
c1c4a5a870eb668fec480771c4d002e17362ed18 crashes in
`LocalInstantiationScope::findInstantiationOf` on both attempts, while
the fix emits only the expected illegal-static-member diagnostic and
exits normally on both attempts.
Prepared with assistance from Codex.
NAS-145210 / 27.0.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20200)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145210 / 27.1.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20201)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145153 / 27.1.0 / Fail graceful VM and container stop when the guest keeps running (by Qubad786) (#20202)
## Problem
A graceful `vm.stop` / `container.stop` (no `force`, no
`force_after_timeout`, the API default) waited `shutdown_timeout` and
then reported SUCCESS even when the guest ignored the shutdown request
and was still running. The UI showed the guest as stopped and a graceful
container restart then failed on start with "already started". A
suspended VM was also left suspended with a successful job, even with
`force_after_timeout`, because the post-stop check only looked for
`RUNNING`.
## Solution
After the shutdown request, both stop paths check the state again. If
the guest has not stopped, it is powered off when `force_after_timeout`
is set; otherwise the job fails with an ETIMEDOUT `CallError` saying it
did not stop within the timeout. A suspended VM is resumed before the
shutdown request so the guest can act on it, and library errors (e.g.
stopping a guest that is not running) are raised as `CallError` like
[5 lines not shown]
NAS-145155 / 28.0.0-BETA.1 / Harden container image pull (#20188)
## Problem
Pulling a container image leaked raw `requests` errors, had no timeout
on the tarball download so a stalled stream hung forever and never
checked the published sha256. The pull was a sync job, so it could only
stop at its own abort checks, and `container.create` wasn't abortable at
all. Two concurrent pulls of the same uncached image could also destroy
each other's in-progress dataset through the orphan cleanup.
## Solution
- **Readable registry errors**: registry index failures (connection,
HTTP status, timeout, bad JSON) are raised as `CallError('Failed to
query container image registry: ...')`.
- **aiohttp with timeouts**: the registry fetch and tarball download use
aiohttp with connect and per-read timeouts of `INTERNET_TIMEOUT` and no
total limit, so a stall fails the pull instead of hanging. `trust_env`
is set so the `http(s)_proxy` environment is still honoured, as it was
with `requests`.
[22 lines not shown]
[CIR] Use `cir.vec.fcmp` op for AArch64 builtins (#241404)
I've been splitting integer and floating comparisons and stumbled upon
these.
claude updated the test.
Harden container image pull
## Problem
Pulling a container image leaked raw `requests` errors, had no timeout on the tarball download so a stalled stream hung forever and never checked the published sha256. The pull was a sync job, so it could only stop at its own abort checks, and `container.create` wasn't abortable at all. Two concurrent pulls of the same uncached image could also destroy each other's in-progress dataset through the orphan cleanup.
## Solution
- **Readable registry errors**: registry index failures (connection, HTTP status, timeout, bad JSON) are raised as `CallError('Failed to query container image registry: ...')`.
- **aiohttp with timeouts**: the registry fetch and tarball download use aiohttp with connect and per-read timeouts of `INTERNET_TIMEOUT` and no total limit, so a stall fails the pull instead of hanging. `trust_env` is set so the `http(s)_proxy` environment is still honoured, as it was with `requests`.
- **Checksum**: the download is hashed as it streams and compared against the registry's sha256 before anything is extracted.
- **Registry lookup first**: the image/version lookup happens before `ensure_datasets`, the orphan destroy and the dataset create, so an unknown image or unreachable registry never touches a dataset. Cached images still return early without network access.
- **Async pull**: `container.image.pull` is an async job, so an abort cancels the network awaits immediately. File writes go through a thread, and progress is only reported when the integer percent changes.
- **Threaded extraction**: the tarball is streamed through `tarfile` in a thread that checks for abort before every member and raises `JobCancelledException`, so a partial rootfs is never snapshotted. On any failure or cancel the cleanup awaits the extraction thread until it has stopped and only then destroys the image dataset, since destroying it while the thread is still writing fails as busy.
- **Abortable create**: `container.create` is `abortable=True`. It forwards the abort to its pull job, because `job.wrap` doesn't cancel the subjob, and raises `JobCancelledException` if the pull was aborted on its own.
- **Per-image lock**: `container.image.pull` holds a lock keyed on pool, name and version with `lock_queue_size=None`, so each create waits for its own pull job and a waiter after a successful pull hits the cached snapshot.
[libc++] Fix generator dependencies for Clang modules
Include the internal headers that declare size_t and ptrdiff_t directly so generator can use both types when building the std Clang module.
[libc] Support execution of scripts without shebangs in execvpe (#240040)
Per POSIX.1-2024, if `execve` fails with `ENOEXEC`,
`execvpe`/`execvp`/`execlp` must execute the file using the system shell
(`/bin/sh`) with the file as the first argument and the remaining
arguments appended.
### Changes
- Implements `execve_with_shell_fallback` in
`libc/src/unistd/linux/exec_utils.h`.
- Falls back to `/bin/sh` on `ENOEXEC` both for direct slash paths and
`PATH` searches.
- Adds integration tests in
`libc/test/integration/src/unistd/execlp_test.cpp`.
Fixes #232374.
[AMDGPU] Pre-commit tests for isExtractHiElt with wide sources
Add tests where the high half of a pair is selected from a source wider
than 32 bits: f16 fpext, fma_mix and D16 loads at -O0, and packed f32
broadcasts of odd elements.
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
py-django-compressor: updated to 4.7.0
v4.7 (2025-11-12)
- Drop Python 3.10 (EOL), Add Python 3.15
- Add support for Django 6.1.
- Drop support for Django versions before 5.2.
- Replace deprecated codecs.open with builtin open
- Discover compress blocks inside Jinja2 elif branches
- Update BrotliCompressorFileStorage to compress each file in one go
- Add Subresource Integrity (SRI) support for compressed assets
py-publicsuffixlist: updated to 1.1.2.20261112
1.1.1, 1.1.2 (2026-10-21)
No code changes. This release only refreshes CI and development tooling.
Update astral-sh/setup-uv to v10.3.0 in the GitHub Actions workflows.
Refresh uv.lock, updating certifi to pick up the bundled CA certificate changes.
Fix the auto-release workflow so that it no longer bundles a stale PSL file.
1.1.0 (2026-10-10)
This version drops support for Python 3.5, 3.6 and 3.7, and now requires Python 3.8 or later.
Packaging has been migrated to PEP 621 metadata in pyproject.toml using hatchling, replacing setup.py, setup.cfg and MANIFEST.in. The version is now read from publicsuffixlist.__version__, and development dependencies are locked with uv.
Add PEP 561 py.typed marker and complete type annotations for the public API, including compat and the update script.
Add an accept_unknown keyword argument to is_private() and is_public().
[4 lines not shown]
ports-mgmt/pkg: update to 2.9.1
Changes:
Major changes:
- upgrade: be more verbose about why a package is being installed as part of an upgrade
- improvements in shlibs/provides handling in pkg add (for subpackages in ports).
Minor changes:
- Fix plugins
- Fix elf reading leading to crash
- Fix query %R
- Sync libfetch from current
(cherry picked from commit 603478f9f4b430b8262627d61c8efa3e7cc3fc5a)
