x11-fonts/cantarell-fonts: update to 0.311
Update to 0.311
Release: v0.311
- Also provide a ss01 variant for the "fl" ligature, which I forgot in the last release.
- Relax Python version requirements to >= 3.10 when using uv.
Remove MESON_ARGS, useprebuilt option is enabled by default
PR: 292096
graphics/py-vulkan: Python binding for Vulkan API
vulkan is a Python extension which supports the Vulkan API. It
leverages power of Vulkan with simplicity of Python. It's a complete
Vulkan wrapper, it keeps the original Vulkan API and try to limit
differences induced by Python.
devel/py-cffi is also needed as a BUILD_DEPENDS (truckman)
PR: 289669
sys/abi_types.h: time32_t is 64-bit on non-x86 architectures
As long as 'sys/compat/freebsd32/freebsd32.h' is used unconditionally on
all platforms (in 'kern_umtx.c' at least), the rule of thumb is to
ensure that 'struct foo32' on a 32-bit arch is type-compatible with
'struct foo' on the same arch. In practice, this is very simple to
achieve: All 'foo32' types should be compatible with 'foo' on 32-bit
architectures, which is what we are supposed to do already for compat'
structures by design. The recently introduced 'freebsd32_uint64_t' type
typically supports that.
This change fixes commit 87632ddf67b0 ("openzfs sys/types32.h: use
abi_compat.h for time32_t") which was defining 'time32_t' to 'in32_t'
for all 32-bit architectures, which is wrong but on i386. By luck, this
did not change the size of whole 'struct ffclock_estimate32' (whose size
is compile-time asserted) because 'struct bintime32''s one would stay
the same, as even if its field 'sec' was incorrectly sized after that
commit, the 'frac' one is 64-bit and 64-bit aligned on all non-x86
architectures so its offset in 'struct bintime32' would stay the same.
[5 lines not shown]
sys/compat/freebsd32: FF clock struct: Don't pack, use 'ffcounter32'
Packing 'struct ffclock_estimate32', in absence of substitution of
'ffcounter' (some 'uint64_t') by a 32-bit compatible type, was necessary
on amd64 since 'uint64_t' is 8-byte aligned, which leaves a padding gap
of 4-byte between fields 'update_time' and 'update_ffcount'. This gap
does not exist on i386 (or amd64 32-bit mode), as 'uint64_t' there is
only 4-byte aligned.
Change the type of the 'update_ffcount' and 'leapsec_next' fields to the
recently introduced 'freebsd32_uint64_t', and adapt copy-in and copy-out
accordingly. Using `CP()` previously worked due to the '__packed__'
attribute.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55282
lagg: Make lagg_link_active() static
It is declared as static. Make the definition consistent with the
declaration.
It was ever fixed by commit 52e53e2de0ec, but the commit was reverted,
leaving it unfixed.
No functional change intended.
MFC after: 3 days
(cherry picked from commit 30988d0a7bd7ebd5f5825b9b7aa04ff0af788aa7)
lagg: Avoid dropping locks when starting the interface
The init routine of a lagg(4) interface will not change during the whole
lifecycle. So we can call lagg_init() directly instead of through the
function pointer. Well, that requires a drop and pickup lock, which
unnecessarily expose a small race window. Refactor lagg_init() into
lagg_init_locked() and call the later one to avoid that.
Meanwhile, delay updating the driver managed status until after the
interface is really ready.
Reviewed by: markj
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D55198
(cherry picked from commit c182cf646a4f995fa8506afd8afc9541c4d32905)
audio/shairport-sync: Update to 5.0.0
- Update to 5.0.0
- Drop SNDIO from default options (deprecated upstream)
- Add SNDIO deprecation note to OPTIONS
Changelog:
https://github.com/mikebrady/shairport-sync/releases
ports-mgmt/synth: update to 3.13 release (+)
Changelog:
* Attempt to fix prefetching with modern pkg
* Limit log preservation to the task that failed
* testing fix for missing synth scanner log file
* Add EXIT STATUS section to man page
* Set non-zero return code when problem encountered
* Create /etc/hosts in builder
net/py-trio: Update to 0.33.0
- Add PYTHONPATH=${WRKSRC}/src to TEST_ENV so pytest runs against
the in-tree sources (src layout)
- Disable pytest plugin autoload during tests to avoid interference
from unrelated globally installed pytest plugins
libusb: dequeue next transfer on completion to prevent stalls
The transfer proxy callbacks (bulk/interrupt, control, isochronous)
only called libusb10_submit_transfer_sub() in the START path to
pipeline the second kernel transfer slot. On completion or error,
no attempt was made to dequeue the next pending transfer from
tr_head onto the now-free slot.
When more than two async transfers were submitted on the same
endpoint, the third (and subsequent) transfers would remain stuck
on tr_head indefinitely, since no completion ever triggered their
submission. This caused a protocol-level deadlock in applications
like adb that submit header + payload + zero-length terminator as
three separate bulk transfers in sequence.
Fix by calling libusb10_submit_transfer_sub() after every
libusb10_complete_transfer() in all three proxy callbacks.
MFC After: 2 weeks
[2 lines not shown]
