Jean-Pierre MartineauandClaude Opus 5
839da9ab8f
The map is the only networked part of MeshTerm, and every failure on that path is logged at DEBUG while log_level defaults to WARNING: a reader whose tiles never arrive gets a blank ground and no explanation anywhere. On macOS that is routinely a Python with no certificate store at all, which no amount of looking at the app can reveal. scripts/basemap-doctor.py is the explanation. It reports the interpreter, the trust store, the tile source and the cached-tile count, then fetches the TileJSON and one real tile the way BasemapSource does, and turns the failure into one verdict with its fix. The verdict is an A/B rather than a reading: curl verifies against the OS trust store and Python against its own, so curl succeeding where Python fails is the app's store and nothing else, while both refusing the same certificate is TLS interception or a genuinely bad server — one exception, opposite causes, opposite fixes. Collapsing curl's exit codes into "failed" had it blaming the store and the network in the same breath. It also answers the other way a map looks wrong, since it costs nothing in the same round trip: an unset COLORTERM is 256 colours, where the basemap's greens and blues collide. Started under the wrong Python it finds the installed meshterm command, reads its shebang and hands itself over, so nobody has to know which of their three Pythons the app went into. By subprocess, not execve, which on Windows is not a real exec and segfaults under a redirect — and stdout is flushed first, or the banner loses the report it introduces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
scripts/
Repo-side tools. None of these ship in the wheel.
| Script | What it is for |
|---|---|
basemap-doctor.py |
Why a user's map has no basemap — certificates, DNS, proxy, or colour depth |
picocalc/ |
Calculinux device setup: console font, palette, Wi-Fi, radio bridge |
uconsole/ |
The uConsole SPI bridge service |
basemap-doctor.py
The map is the only networked part of MeshTerm, and every fetch failure on that path is
logged at DEBUG while log_level defaults to WARNING — so a reader whose tiles never
arrive sees a blank ground and no explanation. This prints the explanation and the fix.
Send a user this, to run on the machine with the problem:
curl -fsSL https://raw.githubusercontent.com/jpmartineau/MeshTerm/main/scripts/basemap-doctor.py -o /tmp/basemap-doctor.py
python3 /tmp/basemap-doctor.py
Any python3 will do: if that one has no MeshTerm, the script reads the interpreter out
of the installed meshterm command's shebang and hands itself over, so the answer always
comes from the app's own Python — a Mac routinely has three and only that one has the
trust store that matters. Save it to a file as above rather than piping into python3 -:
with no file on disk there is nothing to hand over.
Have them paste the whole output back. It names the interpreter, the certificate store,
the tile source, the cached-tile count, COLORTERM, and then one verdict:
- curl reached it, Python did not — the Python's certificate store is empty. A
python.org install on macOS ships that way until
Install Certificates.commandis run. - neither reached it — the network path: a firewall, a proxy, a DNS filter, or an outage. Nothing to fix in MeshTerm.
- both reached it — tiles are fine and the complaint is colour: an unset
COLORTERMmeans 256 colours, where the basemap's greens and blues collide. Terminal.app cannot do 24-bit colour at all.
Exit status is 0 when tiles arrive and 1 when they do not, so it can be scripted.