1.6.0 release QA follow-ups #925

Follow-ups found during the 1.6.0 release QA. None blocked the release.

1. Unguarded train()/val() scripts crash on macOS and Windows

On macOS and Windows, a script that calls train() or val() without an if __name__ == "__main__": guard crashes with RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase. DataLoader workers (default workers=4) use the spawn start method and re-run the script's top level. Single-GPU and CPU runs are affected, not only multi-GPU. Same behavior in 1.5.0.

Repro (macOS, libreyolo 1.6.0), s.py:

from libreyolo import LibreYOLO
LibreYOLO("LibreYOLO9t.pt").val(data="coco8.yaml")

python s.py fails.

Most docs snippets are unguarded, so copying one into a script hits this.

Proposed fix: in the shared train() wrapper and BaseModel.val(), when the start method is spawn and the script has no main guard, fall back to workers=0 with a warning (or skip train()/val() in the re-run worker process). This covers every family in one place.

2. CLI train ignores the family recipe for D-FINE, DEIM, EC, SegFormer and others

libreyolo train does not use the family training recipe for D-FINE, DEIM, EC, SegFormer, LingBot-Vision and V-JEPA 2 (no TRAIN_CONFIG / not in _FAMILY_RESOLVED_TRAIN_DEFAULTS), so the generic CLI defaults are sent.

• SegFormer fails outright: libreyolo train model=LibreSegformerb0-sem.pt data=<semantic yaml> → Unknown SegFormer scheduler: 'yoloxwarmcos'.
• D-FINE trains with lr0=0.01 instead of 2e-4; DEIM CLI uses lr0=1e-4 while Python train() uses 4e-4.
• --dry-run shows generic defaults for YOLO-NAS, PP-LiteSeg and GTR although training uses the family recipe.
• YOLO-NAS pose CLI logs 300 epochs but trains 1000.

Found in 1.6.0 release QA.

3. RF-DETR n/s/m/l pose weights download, then fail to load

LibreRFDETR{n,s,m,l}-pose.pt are published on Hugging Face, but 1.6.0 downloads them (~121 MB) and then raises Invalid size: n. Only LibreRFDETRx-pose.pt loads.

Either support the n/s/m/l pose presets or reject the names before downloading (and keep them out of the website registry, which rebuilds them from the HF repos).

4. LibreYOLOX("LibreYOLOXn.pt") ignores the checkpoint size

LibreYOLOX("LibreYOLOXn.pt") (direct class, not the LibreYOLO factory) ignores the size in the checkpoint name: the state dict does not match the default size, and the file is downloaded into the current directory instead of weights/.

5. TensorRT export fails with TensorRT 11

export(format="tensorrt") fails with TensorRT 11 (current tensorrt-cu12 is 11.3):

libreyolo/export/tensorrt.py:299
network_flags = 1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)
AttributeError: ... has no attribute 'EXPLICIT_BATCH'

The [tensorrt] extra pins 10.16, where it works; users who install TensorRT themselves get the newer one. Explicit batch is the only mode in TensorRT 10+, so create the network without the flag when it is missing.

6. from_fiftyone() drops instance masks

libreyolo.integrations.fiftyone.from_fiftyone() exports through FiftyOne's YOLOv5Dataset, which writes boxes only: instance masks on Detection.mask are dropped, so an exported segmentation view trains detection. Reproduced with fiftyone 1.22.0 (a detection with a mask exports as 0 cx cy w h).

Listed as a known limitation in 1.6.0.

7. Moondream 3 mirror does not load

LibreVLM("moondream-3") does not load: the LibreYOLO/LibreMoondream3 mirror (pinned revision 27c8082b) has the older model-0000N-of-00004.safetensors shards, but its model.safetensors.index.json (copied from upstream) maps every tensor to modelv2-0000N-of-00004.safetensors, which the mirror does not hold. The old shards also lack model.region.ln.*.

Fix: copy the four modelv2-* shards (~18.5 GB) from moondream/moondream3-preview@5112966d, delete the old model-* shards in the same commit (snapshot_download pulls every file), and bump HF_REVISIONS["3"] in libreyolo/models/vlm/moondream.py. Listed as a known limitation in 1.6.0.

8. [all], [vlm], [ground] extras cannot install on macOS arm64 and aarch64

pip install "libreyolo[all]" (also [vlm], [ground], [vlm-train]) cannot be resolved on macOS arm64 and aarch64 Linux: decord==0.6.0 has no wheels there. Same in 1.5.0. The install docs now mention it; the extras could make decord conditional on platform or switch to a maintained video reader.

9. Segmentation val reports mask mAP 0 for box-only label rows

Segmentation validation on a YOLO dataset whose label rows are box-only (no polygon) reports mask mAP 0: libreyolo/data/yolo_coco_api.py writes "segmentation": [] for those rows. Skip them for mask evaluation or warn that the split has no masks.

10. CLI and output polish

Smaller CLI and output issues found in 1.6.0 release QA:

• Predict --json has two shapes under schema_version: 1 (streaming vs not), and class changes type between them.
• quiet=true does not silence stderr (val with json=true, the video progress bar).
• half is forwarded to exported runtimes where it is a no-op; the code comment says FP16.
• export nms=true on YOLO9-E2E exits format_precision_unsupported, a misleading code.
• CLI pose val prints an all-zero summary; CLI semantic predict prints "(no detections)".
• eval_backend shows "pycocotools ?".
• libreyolo models --json omits SenseNova-Vision and LibreMODUS.
• CLI run names are exp where Python uses <family>_exp (e.g. dfine_exp).
• A fresh run logs "Resumed past no-aug threshold (epoch 0 > -14)".
• coco8-pose leaves ~811 MB of COCO annotations behind.
• The GTR semantic LoRA error message names the wrong task.
• README "One API, twenty tasks": act (LibreVLA) and detect3d need more than a different checkpoint; say so next to the example.

11. Weight licenses that add dataset-derived non-commercial terms (decision)

Policy: weights keep the license their authors declare. Some 1.6.0 code, notices and HF cards still add dataset-derived non-commercial terms instead:

• PP-LiteSeg and ViTMatte (code notices and HF cards), FCOS3D (code notices).
• weights/convert_gtr_sem_weights.py stamps PP-LiteSeg's Cityscapes non-commercial license into LibreGTR*-sem.pt metadata, while GTR upstream declares MIT.
• DetAny3D: the changelog says CC-BY-NC-4.0, the website registry says no license was declared, licensing.md says "restrictive weight terms".

Needs a maintainer decision per model; U-Net was already moved to its upstream Apache-2.0 in #908.

12. Release GPU nightly has no runner

e2e-nightly-release.yml runs its e2e job on [self-hosted, gpu, libreyolo-e2e], and the repo has no registered runner, so the post-publish nightly for v1.6.0 (run 36343418148) stays queued forever. The v1.6.0 tag was verified by running tools/ci/modal_nightly.py --ref 809009bc directly (passed). Either reconnect the runner or run the release job on Modal like the dev nightly.

13. Website docs follow-ups (LibreYOLO/libreyolo-website)

Docs follow-ups from the 1.6.0 docs QA (not blocking):

• About 190 Python train()/val() snippets have no if __name__ == "__main__": guard and crash when saved as a script on macOS/Windows (library side: Unguarded train()/val() scripts crash on macOS and Windows #913).
• 100 pages still say last_verified: 1.5.0.
• About 20 families have no Sizes row; new families sit unsorted at the end of the models nav.
• /docs/librevlm and /docs/experimental still say "dev branch / v1.3".
• export/jetson.md (and twins) still says it is the one page carrying a 1.4.0 verification.
• Missing mentions: the unknown-key "did you mean" suggestion, EdgeCrafter pose output change, COCO prediction-id fix, MiDaS bicubic resize, graphql-core<3.3 cap for [fiftyone], CLI error-code names, Qwen3-VL resume.
• Translation quality: Korean results.ko and stability-tiers.ko ("수업" for class, "통화" for call), one mistranslation in gaze-estimation.id.
• PLAN_docs_v1.6.0.md in the repo root is stale.