fresh: fix CARGO_INSTALL_ARGS for workspace root
Upstream moved the Cargo workspace root to the repo root in 0.3.9.
CARGO_WRKSRC must stay at the root for correct Cargo.lock discovery,
but cargo install needs --path pointing at the installable crate,
not the virtual workspace manifest.
fresh: update to 0.3.9
- Bump version from 0.3.8 to 0.3.9
- Update CARGO_WRKSRC from crates/fresh-editor to workspace root
(upstream moved Cargo.lock to repo root in this release)
- Regenerate distinfo checksums
py-test-asyncio: updated to 1.4.0
1.4.0
Deprecated
Overriding the event_loop_policy fixture is deprecated. Use the pytest_asyncio_loop_factories hook instead.
Added
Added the pytest_asyncio_loop_factories hook to parametrize asyncio tests with custom event loop factories.
The hook returns a mapping of factory names to loop factories, and pytest.mark.asyncio(loop_factories=[...]) selects a subset of configured factories per test. When a single factory is configured, test names are unchanged.
Synchronous @pytest_asyncio.fixture functions now see the correct event loop when custom loop factories are configured, even when test code disrupts the current event loop (e.g., via asyncio.run() or asyncio.set_event_loop(None)).
Changed
Improved the readability of the warning message that is displayed when asyncio_default_fixture_loop_scope is unset
[7 lines not shown]
py-country: updated to 26.2.16
26.2.16 (2026-02-16)
- Dropped support for end-of-life Pythons 3.8 and 3.9.
- Added explicit support for Python 3.13 and 3.14.
- Updated to iso-codes 4.20.1.
- Added support for matching initials in ``countries.search_fuzzy``. For
example, results for ``countries.search_fuzzy("UK")`` will now include
GB (United Kingdom).
- Fixed ``subdivisions.add_entry`` and ``subdivisions.remove_entry``, which
would previously render the ``country_code`` index of ``subdivisions``
unusable causing ``subdivisions.get(country_code=...)`` to return a malformed
result.
py-tox: updated to 4.54.0
Features - 4.54.0
Declare the runtime dependencies of the tox.pytest plugin (pytest, devpi-process and pytest-mock) under a new testing extra, so plugin authors can pull them in via tox[testing] - by @gaborbernat.
Bug fixes - 4.54.0
Extend the generated TOML schema to cover every replace table form (env, ref, posargs, glob, if), including conditional replacements used inside commands. A guard test asserts the schema stays in sync with the loader implementation so future replace types cannot be added without a corresponding schema entry.
x86: use 0x40000010 cpuid leaf only on vmware and kvm
specifically, do not use it on nvmm.
these hypervisor cpuid leafs are basically hypervisor-specific.
(there was a proposal on commonizing these hypervisor leafs. [1]
but it doesn't seem agreed on.)
this cpuid leaf 0x40000010 was originally from vmware. although it
seems more common to use the GETHZ (45) hypercall instead these days.
kvm seems to implement it as well. (via qemu vmware-cpuid-freq)
i personally haven't tested this on either vmware or kvm.
for nvmm (netbsd), the leaf has been implemented in 2025. [2]
and then the lapic bit has been disabled in 2026. [3] that is,
we had no releases with it enabled. even if you are running the
-current version of nvmm, it's better to avoid using this leaf
[5 lines not shown]
nvmm: remove cpuid leaf 0x40000010
* given the lapic bit disabled, (PR/59424) [1]
this leaf doesn't seem to have much benefit anymore.
as nvmm is used in other platforms, (dragonfly bsd)
it's better to avoid guest ABI changes without clear benefits.
* I couldn't find any documenation about what RBX=0 means.
(vmware or kvm)
we can revisit this when/if someone comes up with a better
implementation. (probably userland-assisted one)
discussed on source-changes-d. [2]
reviewed by Taylor R Campbell.
[1] https://mail-index.netbsd.org/source-changes/2026/05/01/msg161786.html
[2] https://mail-index.netbsd.org/source-changes-d/2026/05/01/msg014654.html
gtk3: Make building wayland support conditional on GLAMOREGL on NetBSD.
While this seems... weird, at best, due to Historical Reasons
building libEGL was dependent on building the X server with GLAMOR
support in NetBSD. This is no longer true, but some problems linger
(e.g. with libepoxy in the base system).
As a special hack, for NetBSD with native X only, disable Wayland
support if the GLAMOR extension isn't enabled.
PR pkg/60295 x11/gtk3 does not build on NetBSD/macppc
libepoxy: Make EGL libs depend on EGL support rather than GLAMOR.
Build tested on sparc64, which has EGL but no GLAMOR x server.
If this is pulled up, it should happen before 11.0 is cut, since
it adds stuff to the ABI.
PR pkg/60295 x11/gtk3 does not build on NetBSD/macppc
ory-hydra: Add version 26.2.0
Ory Hydra is a server implementation of the OAuth 2.0 authorization framework
and the OpenID Connect Core 1.0. It follows cloud architecture best practices
and focuses on:
* OAuth 2.0 and OpenID Connect flows
* Token issuance and validation
* Client management
* Consent and login flow orchestration
* JWKS management
* Low latency and high throughput
py-oauthenticator: Add version 17.4.0
OAuth is a token based login mechanism that doesn't rely on a username and
password mapping. In order to use this login mechanism with JupyerHub the
login handlers need to be overridden. OAuthenticator overrides these handlers
for the common OAuth2 identity providers allowing them to be plugged in and
used with JupyterHub.
The following authentication services are supported through their own
authenticator: Auth0, Azure AD, Bitbucket, CILogon, FeiShu, GitHub, GitLab,
Globus, Google, MediaWiki, OpenShift.
There is also a GenericAuthenticator that can be configured with any OAuth 2.0
identity provider or can be used to create a new authenticator class when
py-jupyterhub: Add version 5.4.6
With JupyterHub you can create a multi-user Hub that spawns, manages, and
proxies multiple instances of the single-user Jupyter notebook server.
Project Jupyter created JupyterHub to support many users. The Hub can offer
notebook servers to a class of students, a corporate data science workgroup,
a scientific research project, or a high-performance computing group.
