tp_smapi-lts

Build times (auto-updated)

• x86_64: 1m29s (2026-09-08 17:19 UTC, serial)

---

Category: maintained/tp_smapi-lts (adopted from official Arch repos – flagged by buildmaster’s “Missing state file” checker as a candidate to move to the AUR; see https://buildmaster.archlinux32.org/checker/summary.html).

2026-09-08: adopted from official repos

• Dropped from: extra-x86_64
• Method used: B (no AUR repo existed, cloned straight from gitlab packaging repo)
• Reason dropped upstream: unknown, needs manual look
• Conflict notes: n/a (Method B, no merge performed)

2026-09-08: trial build against a modern kernel – succeeded cleanly

User: “you can try to build tp_smapi-lts” – a ThinkPad SMAPI kernel module (thinkpad_ec/tp_smapi/hdaps), last real upstream activity years ago. Expected real risk of failing against kernel API drift, but built cleanly against linux-lts 6.18.50-1-lts with zero warnings from the actual compile (only harmless namcap notes: “No ELF files” – normal for a .ko-only package – and a “linux-lts dependency may not be needed” false positive). linux-lts/linux-lts-headers resolve fine from the official core repo, no local naming mismatch.

Built only (staging clone at /data/INSTALL/tp_smapi-lts, x86_64 only per its own arch=()) – not signed/published, not pushed to AUR, not vendored. Awaiting a decision on whether to actually adopt this one for real.

2026-09-08: published to the private repo

User: “adopt tp_smapi-lts for real and publish”. Signed+published the already-verified trial build (same package file, no rebuild needed) – now live on archlinuxaba for x86_64. Still not pushed to AUR, not vendored into arch/maintained/ – per the standing “never git commit or push” rule, that step stays the user’s own (same split as [[perl-crypt-ssleay]]: this pipeline publishes the binary, the user does the real AUR push+vendor by hand, (cd /data/INSTALL/tp_smapi-lts && git push -u origin master) then scripts/add_aur_package.sh maintained tp_smapi-lts).