palemoon: Update to 34.2.1
Many security issues were addressed, including potential crash
scenarios and code correctness issues. As a summary: 50 potential
vulnerabilities were found applicable and fixed, 20 issues had DiD
code changes applied, and 4 were already mitigated by us before being
reported. Of the reported vulnerabilities, 270 were not applicable to
our code (with the vast majority pertaining to e10s/multi-process
browser architecture) and 6 low-impact ones were marked for further
investigation at a later time.
textproc/treemd: update to 0.5.11
[0.5.11] - 2026-04-28
Fixed
Toggle details no-op after section navigation - In interactive mode, pressing Enter on certain <details> blocks reported "✓ Toggled details" but produced no visible change. InteractiveState::element_states is keyed only by ElementId { block_idx, sub_idx }, so a previous section's Table state at a given block_idx silently blocked a fresh Details from initializing at the same key (the indexer used HashMap::entry().or_insert(), a no-op when present). toggle_details then matched no Details variant and silently failed. Indexer now overwrites stale wrong-variant entries while preserving same-section toggle state. Regression test added.
--filter and --level ignored in --tree mode - CLI now honors both flags when rendering the tree output (c3c3fcd)
--at-line not wired up; -s mismatched formatted headings - --at-line resolves to the enclosing heading; section selection (-s) now matches headings that contain inline formatting (36c4e60)
Changed
Upgraded all dependencies to latest - Refreshed clap_complete 4.6.2 → 4.6.3, mermaid-rs-renderer 0.2.1 → 0.2.2, turbovault-parser 1.4.0 → 1.4.1, turbovault-core 1.4.0 → 1.4.1, open 5.3.3 → 5.3.4, plus transitive refreshes (plist, wasm-bindgen, tokio, libc, js-sys, cc, etc.)
Tests
Added end-to-end CLI integration suite covering --tree, --list, --filter, --level, --at-line, and -s (471d9d5)
Added coverage for JSON output builder and config loading (ef250da)
Added coverage for document tree/search and palette command matching (f185c4b)
[3 lines not shown]
opendmarc: Default to mariadb instead of mysql.
The pkgsrc default is mariadb so it makes sense to avoid conflicts. While
here fix pkglint. Bump PKGREVISION.
macekbc: fix byte transmit to properly inhibit clock line first
The PS/2 "specification" requires the controller to inhibit
the clock line for 100uS before trying to transmit. This tells
the device (in this case a bunch of ps/2 mice) to stop transmitting,
get ready for receive and get ready to send the clock out to the
controller to send said bits.
The mice in question work fine on the O2 PROM, so it's not a
hardware issue per se.
After staring at traces with a logic analyser it looks like the
controller is NOT doing this in hardware - it immediately attempts
to transmit bytes and if the ps/2 device doesn't handle that,
it will simply never send out clock pulses for the controller to
clock the byte out.
So:
[10 lines not shown]
old malloc(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
osnet libuutil: Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
libbsdmalloc: Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
arc4random(3): Use mutex_init, not mutex_unlock, in child post-fork.
Using mutex_unlock may try to wake a thread that doesn't exist in the
child, which could lead to trouble such as crash or deadlock. But
since the child is single-threaded, it is safe to just reinitialize
the mutex memory anyway.
PR lib/59237: postfork mutex audit: mutex_init, not mutex_unlock
devel/mise: update to 2026.4.24
2026.4.24 - 2026-04-27
🚀 Features
(ls-remote) add prereleases setting and --prerelease flag by @jdx in #9415
🐛 Bug Fixes
(http) retry transient HTTP failures with backoff and warn on rescue by @jdx in #9414
(release) purge mise.en.dev CDN zone after each S3 publish by @jdx in #9416
📚 Documentation
prefix GitHub star count with ★ glyph by @jdx in #9417
update intro messaging by @jdx in #9418
