libXfont2: update to 2.0.9.
This release contains the fixes for the issues reported in today's security advisory:
https://lists.x.org/archives/xorg-announce/2026-August/003734.html
- CVE-2026-59679: Font Server Client encoding Out-Of-Bounds Read/Write
- CVE-2026-44950: Font Server Client Cumulative Glyph Data Heap Buffer Overflow
Additionally, it changes a build-time default. Previously fontserver support
was compiled in by default unless --disable-fc was provided at configure time.
The new default is *disabled by default* unless --enable-fc is provided at
configure time. Doing so protects us from future fontserver-connection related
issues. Fontservers have been deprecated for many years and the vast majority
of users will not notice this changed default (Debian has built with
--disable-fc for years).
cut.1 & paste.1: add HISTORY and AUTHORS
Sourced from OpenBSD and FreeBSD, which both reference the same post[1]
for part of it. They differ in certain details.
FreeBSD puts the additional credit to Marciano Pitargue in the wrong
utility, going by the source code credits (and what OpenBSD has). There
is discussion in the FreeBSD review[2] about which originating release
is relevant for cut(1) (32V vs. System III), as both BSDs referenced
32V for paste(1). This was perhaps confused in the FreeBSD review,
which talks directly about cut(1), but was applied also to paste(1). An
earlier FreeBSD commit specifically lists 32V for paste(1)[3]. (I don't
have 32V to examine.)
These histories could be subject to further cut and paste...
1. https://www.tuhs.org/pipermail/tuhs/2020-January/019955.html
2. https://reviews.freebsd.org/D36048
3. https://github.com/freebsd/freebsd-src/commit/30f8b6c18279162a2f4efdc9e85a49683a8aafbf
py-fastjsonschema: updated to 2.22.1
2.22.1 (2026-07-27)
* Fixed min Python version
2.22.0 (2026-07-25)
* Fixed IPv4 validation (rejecting leading zeros)
* Fixed empty items and patternProperties
* Fixed protection from deeply nested schemas potentially causing denial of service
* Fixed comparing values for enum and const validations
* Fixed resolving plain-name ref fragments
* Fixed not throwing when unknown format is used
* Fixed compilation of not, if/then/else, items, additionalItems, propertyNames and schema dependencies when a subschema generates no validation code
* Added option to get all the errors (set `fast_fail` to `False`)
* Added basic type hints
* Added support of duration and uuid formats from draft-2019
py-flufl.lock: updated to 9.1.0
9.1.0 (2026-04-24)
* Small refactoring to provide a hook for custom synchronization of clocks in subclasses. (:GL:`40`)
* Switch to `pyrefly <https://pyrefly.org/>`_ for type checking.
py-flufl.bounce: updated to 5.0.1
5.0.1 (2026-05-21)
* Fix a false recognition of Microsoft bounces from the Groupwise detector. :GL:`16`
Found and fixed by Mark Sapiro.
5.0 (2026-05-20)
* Major project management modernization.
* Add Mark as a named co-owner.
* Drop Python 3.9, add Python 3.13, 3.14, and 3.15.
* Added recognition for a non-compliant Earthlink DSN.
* Fixed a long-standing bug in the Caiwireless detector that returned a set of individual address
characters instead of the bouncing address itself, and added a test exercising the previously
buggy return path.
* Replaced deprecated/removed pkg_resources.
* Replaced the ``zope.interface`` dependency with ``typing.Protocol``; the ``IBounceDetector``
marker interface has been renamed to ``BounceDetector``. **This is a backwards incompatible
[5 lines not shown]
All M68040 configs require FPSP, and all M68060 configs require M060SP,
so just make M68040 and M68060 dependent on their respective software
packages rather than having to duplicate the options across every kernel
config.
Re-factor the MVME-1xx kernel configs to reduce duplication. Further
shrink the VME* configs to be much closer to "bare minimum for this
machine" to help out small memory config units (4MB base RAM on some).
/bin/sh - builtin read command fixes (miscbltin.c)
This corrects a change made in the previous version, where
in addition to the intended change, making a read error be
treated differently than EOF, a change with unplanned
consequences was also made, to treat the EINTR read error
as a "try again" signal, rather than as a read error.
That meant that caught traps no longer interrupted the read,
and while that is how (some) other shells do it (like bash)
it was a change to how our shell does things.
So, now there is (in normal shells) a new -c (continue) option
to cause this behaviour, when given, a trapped signal will be
processed during the wait for input by the read built-in utility,
but not end the read. When absent, the trap will still be processed
while the read is in progress, but will be treated as a read error
(and produce the special (>1) exit code 130.
While doing this, revert all these changes for SMALL shells, they
[4 lines not shown]
/bin/sh - trap.c - new func and avoid lost memory
Add run_traps() - which is just dotrap() except that it
preserves the state of the stack around the trap executions,
so is safe to call with the stack in any state. It will also
preserve the state of the growing string at the top of the
stack if informed (by giving a non-zero value as its arg)
that such a string currently exists. This new function does
not exist in SMALL shells.
While here, fix an unlikely memory leak - if a shell error
(not command error) occurs while processing a trap in dotrap()
the copy of the trap string being parsed can be lost. This is
irrelevant in non-interactive shells, as the errors which would
cause this loss, also cause a non-interactive shell to exit,
the lost memory is only lost for a very short time. Interactive
shells rarely set traps (except possibly an EXIT trap - for which
the memory loss is also immaterial for almost the same reason) at
all, and if one were set, and generated a shell error (typically
[3 lines not shown]
/bin/sh - memalloc.h - added STSTRLEN()
Add a new stack string macro STSTRLEN() which returns the
current length of the string being accumulated at the top
of the (shell) stack. As with all the other Stack String
macros, it may only be used between a STARTSTACKSTR() call
and the next call which allocates stack space (often
grabstackstr(), but stalloc() stunalloc() grabstackblock()
all count for this). Use at any other time will give
meaningless unspecified results.
