@@ -15689,3 +15689,24 @@ packages:
   status: blocked
   pr: null
   notes: 'Blocked, not no-gap. Accessibility/screen-reader candidate considered under this rounds screen-reader/accessibility-native-library sweep: BRLTTYs BrlAPI lets applications talk to a running braille display daemon, with Python bindings generated via SWIG from the brltty source tree at build time. Verified not already tracked: no docs/packages/brlapi.yaml, no `pkg: brlapi` in .queue.yml. However there is no `brlapi` (nor `python-brlapi`/`brlapi-python`) package on public PyPI at all - pypi.org/pypi/brlapi/json returns HTTP 404 - because brltty never publishes its Python binding as a standalone sdist/wheel; it is built only as part of a full brltty source build (autotools + SWIG) and installed as a system site-package, not pip-installed. (Separately checked `louis`, the liblouis braille-translation bindings module name: the PyPI package literally named `louis` is an unrelated squatted placeholder - homepage louis.com, summary "A simple louis .py file", version 1.3 - not liblouis; liblouis itself likewise publishes no PyPI package.) With no existing PyPI artifact for this repos workflow to extend (no sdist to build a riscv64 bdist from, no wheel-building CI to narrow), this is out of scope for the current porting model rather than a gap this repo can close today. No worktree/branch/PR created.'
+- pkg: wmm2020
+  version: 1.1.1
+  home: https://github.com/space-physics/wmm2020
+  repo: https://github.com/space-physics/wmm2020
+  status: no-gap
+  pr: null
+  notes: 'No-gap (borghash/parmed shape: no upstream wheel of any kind to close a riscv64-specific gap against). Aviation/flight-navigation candidate (World Magnetic Model geomagnetic declination/inclination, used for compass-variation and magnetic-heading corrections) considered under the aviation/flight-simulation-data sweep, distinct from already-covered orbital-mechanics (sgp4/skyfield-adjacent) and drone libraries. Verified not already tracked: no docs/packages/wmm2020.yaml, no `pkg: wmm2020` in .queue.yml. Verified real upstream (space-physics/wmm2020, MIT). Checked every PyPI release via the PyPI JSON API: every one ships only an sdist (meson-python backend that compiles the bundled Fortran/C WMM2020 reference code on first build), zero wheels for any platform or architecture ever, including x86_64 - so riscv64 is in the identical position as every other platform today, and there is no upstream wheel-building CI (goal 2 has nothing to narrow). Separately checked `wmm2020-cext` (a distinct, differently-maintained PyPI project by justengel): it ships only Windows cp37-cp39 wheels plus an sdist, no Linux wheel of any kind either, so the same no-gap reasoning applies and it is not tracked separately. No worktree/branch/PR created.'
+- pkg: pyudunits2
+  version: 0.1
+  home: https://github.com/pelson/pyudunits2
+  repo: https://github.com/pelson/pyudunits2
+  status: no-gap
+  pr: null
+  notes: 'No-gap (gotcha 27/50/126 shape). Unit-conversion candidate considered under the unit-conversion sweep alongside this rounds gimli.units port, distinct from both gimli.units (a genuine Cython/C binding to the real UDUNITS-2 library, queued this round) and the already-published cf-units: pyudunits2 is a from-scratch pure-Python reimplementation of the UDUNITS-2 unit-expression grammar (lexer/parser written in Python), not a binding to the C library at all. Verified not already tracked: no docs/packages/pyudunits2.yaml, no `pkg: pyudunits2` in .queue.yml. Confirmed via the real PyPI JSON (pyudunits2 0.1): ships only a `pyudunits2-0.1-py3-none-any.whl` plus sdist, zero ext_modules/compiled code anywhere in the project. `pip install pyudunits2` already installs identically on every platform including riscv64 today; there is no compiled content for a riscv64-specific wheel to add. No worktree/branch/PR created.'
+- pkg: pymodes
+  version: 3.6.0
+  home: https://mode-s.org
+  repo: https://github.com/junzis/pyModeS
+  status: no-gap
+  pr: null
+  notes: 'No-gap (gotcha 27/50 shape, with a historical wrinkle). Aviation/ADS-B-decoding candidate considered under the aviation/flight-simulation-data sweep alongside this rounds rs1090 port, distinct from rs1090 (the actively-developed Rust/PyO3 successor, queued this round): pyModeS (PyPI distribution name `pymodes`) is the original pure-Python/Cython Mode S and ADS-B decoder. Verified not already tracked: no docs/packages/pymodes.yaml, no `pkg: pymodes` in .queue.yml. Verified real upstream (junzis/pyModeS, GPL-3.0). Walked the full PyPI release history via the JSON API: releases through 2.22.0 (the last of the 2.x line) genuinely shipped compiled per-interpreter manylinux/macOS/Windows wheels (a real Cython-accelerated C module, no riscv64 among them), but every 3.x release (3.0.0 through the current 3.6.0) ships only a single `py3-none-any` wheel plus sdist - upstream dropped the compiled module entirely in the 3.x rewrite. riscv64 already gets the identical pure-Python wheel every other platform gets today, so there is no current riscv64-specific gap for a port to close (the historical compiled releases are an obsolete line no longer published). No worktree/branch/PR created.'