clang: Emit "long-double-type" module flag generically
Move emission of the "long-double-type" module flag out of PowerPC
and into generic code, so it describes the long double format for all
targets.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate.
- **Record removal moved to a `pool.post_export` hook**, which is the only place that can see whether the data actually went away. It keys off a new `destroyed` flag from `pool.export` rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The hook matches on the dataset and ignores runtime state, so stopped containers are cleaned up too.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
Report apps whose config cannot be read instead of hiding them
## Problem
An app whose metadata is intact but whose saved configuration cannot be read was dropped from the collective metadata, which left it invisible to `app.query` and so impossible to delete - the same dead end this branch set out to remove, reached by a different route.
Separately, an app's metadata is only checked for the keys we need, never for what those keys hold. A value of a type we cannot use - an unquoted `1.13` that yaml parses as a float, a `portals` that is a string, a mapping key that is not a string at all - flows into the query result and raises somewhere further down. Since every app is built in one pass, that takes `app.query` down for every app on the system rather than just the one at fault.
## Solution
- **An app's metadata is recorded even when its config cannot be read**, so it stays visible and deletable, and the config read itself can no longer escape into the caller.
- **Metadata values are type-checked, not just counted.** A key which is absent is still defaulted exactly as before: metadata written by an older release must not be mistaken for a broken app, since being reported as broken takes away every operation but deletion.
- **Version comparison trusts neither side to be parseable**, portal URIs which cannot be normalised are passed through untouched, and the check for apps which disallow multiple instances no longer assumes an entry of the collective metadata is a mapping.
- **Each row is converted to an entry on its own**, so an app the API model cannot describe is reported the way any other broken app is - with a warning naming it - rather than failing the query for everything installed.
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate.
- **Record removal moved to a `pool.post_export` hook**, which is the only place that can see whether the data actually went away. It keys off a new `destroyed` flag from `pool.export` rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The hook matches on the dataset and ignores runtime state, so stopped containers are cleaned up too.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
net-p2p/amule: Use cryptopp-modern shared lib
security/cryptopp-modern 2026.8.0 builds with shared libs.
Let's use shared lib instead of previous static one.
[NFC][AMDGPU] Add tests for an fmul split from its fadd/fsub user (#213303)
Record the current behaviour over the types and subtargets where the
fusion rules differ, f32, f16, bf16, f64, v2f32 and v2f16, with
denormals both enabled and flushed, with and without the contract flags,
and under -fp-contract=fast.
Contributes to https://github.com/llvm/llvm-project/issues/211092
cp: Correct description of SIGINFO
The manual page claimed that SIGINFO caused information to be printed to
stdout, when in fact it is printed to stderr, as one would expect. This
has been true ever since the feature was first added in 2003.
MFC after: 1 week
Fixes: 00d321a2b395 ("Add a SIGINFO handler.")
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D58392
(cherry picked from commit 5dc400ff452b0259f0c50474255ebe6e5e02edb9)
cp: Correct description of SIGINFO
The manual page claimed that SIGINFO caused information to be printed to
stdout, when in fact it is printed to stderr, as one would expect. This
has been true ever since the feature was first added in 2003.
MFC after: 1 week
Fixes: 00d321a2b395 ("Add a SIGINFO handler.")
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D58392
(cherry picked from commit 5dc400ff452b0259f0c50474255ebe6e5e02edb9)
libfetch: Fix handling of connection failures
After commit 848f360c8f9a, if one tries to connect to a closed port,
fetch reports "Operation now in progress", which is rather confusing.
Return a more useful error message, restoring the old behaviour.
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D58481
(cherry picked from commit b02e02958dad2d5ce3675cbc18b9a94635d09e66)
libfetch: Further improve connection polling
* Reorganize the connection loop to make it a little more readable
* Start the timeout clock earlier
* Correctly calculate the poll timeout before calling poll()
* Don't leak the socket on failure
Fixes: 848f360c8f9a ("libfetch: Apply timeout to connection attempts")
Fixes: b02e02958dad ("libfetch: Fix handling of connection failures")
MFC after: 3 days
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58512
(cherry picked from commit 351ed134887fe5b8da39d22fcb267c96ab009ca2)
