Build natively on the development Orin

Two units with different jobs: one builds and runs CI, the other is the
deployment target. Building on the target architecture makes the glibc
constraint structural rather than configured.

The remaining risk is version parity between the two units, not architecture.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
This commit is contained in:
2026-09-05 15:23:10 +09:00
parent 23ee20f9be
commit f49af26898
2 changed files with 32 additions and 20 deletions
+1
View File
@@ -316,6 +316,7 @@ rewriting the document.
| 5 | Rust for on-Orin services, Python for off-car tooling, Dart for the display client | Accepted | 2026-09-04 |
| 21 | Two clocks per envelope; `monotonic` orders, `timestamp` references | Accepted | 2026-09-05 |
| 22 | `signals.json` is the single source for signal name and unit; both are derived, never authored twice | Accepted | 2026-09-05 |
| 23 | Services build natively on the development Orin; both units stay on the same L4T release | Accepted | 2026-09-05 |
| 6 | Local logging first; off-board LTE telemetry deferred | Accepted | 2026-08-14 |
| 7 | Camera/AI inference is a later, separate task | Accepted | 2026-08-14 |
| 8 | Self-hosted offline navigation (MapLibre GL + Valhalla + PMTiles) over a cloud maps SDK | Accepted | 2026-09-03 |