nvmm: Don't report physical lapic freq as virtual lapic freq.
The virtual lapic emulated by qemu in software always ticks at 1 GHz,
but the physical lapic on my laptop, for example, ticks at 24 MHz.
In order for this to work as iMil intended, we need some way for the
hypervisor (such as qemu) to tell nvmm what its lapic frequency is.
Until we have that, we can't correctly report any alleged lapic
frequency to the guest.
PR kern/59424: hardclock ticks run at breakneck pace under qemu
net/unison: Update to 2.54.0
Packaging changes:
Upstream NEWS:
## Changes in 2.54.0
Released 2026-05-01
* Drop old wire protocol. Unison will no longer interoperate with
versions before 2.52.0 and will no longer read pre-2.52.0 archive
files.
* Document that LLM output is unwelcome in the Unison project (code,
issues, mailinglists, etc.).
* Add desktop file.
Deprecation warning: support for external rsync will be removed;
[13 lines not shown]
geography/py-ubx2: Update to 1.3.0
Upstream NEWS, less minor improvements and bugfixes:
### RELEASE 1.3.0
1. Add support for UBX MGA advanced calibration support commands and polls (MGA-SF-INI, MGA-SF-INI2, MGA-INI-ATT, MGA-SF) - thanks to @ariansharifi for contribution.
### RELEASE 1.2.60
1. Add UBXReader `encoding` argument for chunked encoded socket streams.
1. Add a third value '2' to UBXReader and UBXMessage `parsebitfield` argument (*previously a simple boolean*); 0 = parse bitfield as bytes, 1 = parse bitfield as individual bits, 2 = parse bitfield as *both* bytes *and* bits (1)
t_sha512trunc.c: add some more test cases
These were randomly selected (biased for size) from the same source as
the original ones. If still more are needed, reading from an input file
would be the better (or, size-wise only) option, but this is simpler
as-is.
t_sha512trunc.c: fix test case iteration
The code in check() was repeatedly running the first element of the array
of test cases, rather than iterating. (Noted by human-powered code
inspection while preparing another commit that will follow shortly.)
firefox140: update to 140.10.1
Mozilla Foundation Security Advisory 2026-36
Security Vulnerabilities fixed in Firefox ESR 140.10.1
Announced
April 28, 2026
Impact
high
Products
Firefox ESR
Fixed in
Firefox ESR 140.10.1
#CVE-2026-7320: Information disclosure due to incorrect boundary conditions in the Audio/Video component
Reporter
Xuehao Guo
[45 lines not shown]
dasel: update to 3.8.1.
install man pages and shell completion
## [v3.8.1] - 2026-04-30
- `dasel man` now generates a reproducible manpage based on [SOURCE_DATE_EPOCH](https://reproducible-builds.org/specs/source-date-epoch).
sysutils/upower: update to 1.91.2
# upstream changes (since 1.90.9)
Version 1.91.2
--------------
Released: 2026-04-01
- Feature: Skip the systemd inhibitor when performing CriticalPowerAction (!309)
- Feature: Introduce "Auto" CriticalPowerAction using systemd-logind Sleep() (!309)
- Fix: Test CanPowerOff() availability before calling PowerOff() (!311)
- Fix: Add charge limit support for systems providing only charge_control_end_threshold (!310, #342, #285)
Version 1.91.1
--------------
Released: 2026-02-10
- Fix: a resource leak (!294)
- Fix: a NULL exception caused by a Non-NULL GError pointer (!295, #331)
[31 lines not shown]
glib2: avoid false g_module_symbol() failures on NetBSD
On NetBSD, do not turn a non-NULL dlsym() result into a
g_module_symbol() failure only because dlerror() has a non-NULL value.
POSIX specifies that it is implementation-defined whether dlerror()
is thread-safe:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/dlerror.html
as already noted in gmodule-dl.c comments.
On NetBSD, dlerror(3) state is process-global and not thread-safe,
so a non-NULL dlerror() value is not a reliable reason to reject
a non-NULL dlsym() result. Marking dlerror() as not thread-safe
in GLib by DLERROR_IS_THREADSAFE=0 would only serialize GLib's
own dynamic linker calls and would not protect against dynamic
linker calls made outside GLib.
POSIX also specifies that dlsym() returns a null pointer if the
symbol cannot be found. However, glibc documents cases where
[8 lines not shown]
Provide defaults for VM_PHYSSEG_MAX, VM_PHYSSEG_STRAT (single segment),
VM_NFREELIST, and VM_FREELIST_DEFAULT (single freelist).
Achievement unlocked: some platform <machine/vmparam.h> files are now just
simple wrappers around <m68k/vmparam.h> (and a few more are *very* close).
Centralize the definition of VM_PHYS_SIZE. While doing so, change
the logic for its value, eliminating the obsolete USRIOSIZE constant.
Previously, on Utah-derived platforms, USRIOSIZE was defined as the
number of PTEs used for phys_map, and VM_PHYS_SIZE was USRIOSIZE * PAGE_SIZE.
The USRIOSIZE was in turn derived from NPTEPG (number of PTEs in one page).
On 4K page systems, that was a 4MB phys_map. On 8K page systems, that
was a 16MB phys_map (4x muliplier comes from 2x PTEs per page, 2x bytes
per page mapped). These values are totally excessive; the most pressure
phys_map experiences on a typical system is boot-time fsck, and the max
mapping request it will see is MAXPHYS (64KB); it is generally not used in
steady-state operation. In contrast, alpha's phys_map is 512KB and 32-bit
x86 is ~1MB.
Instead, simply define reasonable values for VM_PHYS_SIZE independent of
PAGE_SIZE: 256KB for 68010, 1MB for everone else. Per-platform constraints
can override these values (although they happen to match what Sun2 and Sun3
use, respectively).
[3 lines not shown]
