Start9Labs/start-technologies start-cli/v2.0.0

start-cli v2.0.0

on GitHub

What's Changed

Added

• server epp shows or sets the CPU energy/performance preference. The setting persists
  across reboots and reports the values available on the server.

• s9pk pack packs the package's README.md. It sits beside instructions.md in the
  archive and is readable with S9pk::readme(). The point is what runs on the server: an AI
  assistant administering a service can now read the package's technical reference from the
  installed .s9pk — offline, and describing the version actually installed — instead of
  fetching a repository's default branch, which has usually moved on. Unlike instructions.md
  it is optional, so a package without one still builds; it is simply absent from the
  archive and the accessor returns None. Nothing is packed for an s9pk built before this,
  and v1 packages migrated forward carry no README either.

• An s9pk command says when start-cli is behind the published release. It compares
  itself against the start-cli version named by the workspace's start-technologies
  checkout and prints a one-line notice. start-cli installs outside the workspace, so
  nothing else would have told you: on Debian apt upgrade carries it forward, and
  everywhere else re-running the installer is the only update path.

Changed

• server governor replaces server experimental governor. Scripts that set or inspect
  the CPU governor need to use the direct server subcommand.

• server set-hostname takes one required hostname, and setup execute no
  longer takes --name. A StartOS server carries a single name — its .local
  hostname — where it used to carry a separate display label as well. Setting it
  moves the address the server answers to. A provisioning script that passes
  --name to setup execute, or a name and a hostname to server set-hostname,
  needs updating. server set-hostname and setup execute --hostname also
  reject a name longer than 32 characters, or one starting or ending with a
  hyphen, which 1.1.0 accepted.

• s9pk init-workspace clones the monorepo's live-docs branch rather than master, so a
  workspace's packaging guide, package template, and SDK source describe the
  @start9labs/start-sdk its packages install, and match the pages on docs.start9.com. An
  existing workspace moves over with git -C start-technologies checkout live-docs.

Fixed

• s9pk init-workspace no longer scaffolds a placeholder host — dev-vm.local resolved
  nowhere, failing every command in a fresh workspace; comment it out in an existing one.

• registry os asset remove can be run. Its iso/img/squashfs handlers were registered
  as RPC-only, and — unlike add, sign, and get, which each pair their RPC handlers with a
  CLI counterpart — nothing was registered in their place. remove was left parsing as a leaf
  that accepts no arguments: it listed under registry os asset --help with a blank description,
  and naming an asset type came back unexpected argument 'iso' found with exit 2. The three
  subcommands now take <VERSION> <PLATFORM> and reach the registry directly, mirroring
  registry os asset get, so a single platform's asset can be dropped without removing the whole
  version and re-adding every other platform. Asking to remove a platform the version has no
  asset for now says so instead of reporting success.

• The local authcookie now reaches a registry or tunnel daemon that listens on a
  non-loopback address. Run on the server itself, the CLI presents the daemon's local
  authcookie as an Authorization: Bearer header — but it attached that header only when
  the URL was literally loopback. With no --registry/--tunnel the CLI derives the URL
  from the daemon's own registry-listen/tunnel-listen, which is commonly the wildcard
  0.0.0.0:5959; that is not loopback, so the request went out unauthenticated and came
  back Unauthorized. start-cli registry admin list on the registry host failed this way.
  A wildcard listen address is now dialled over loopback — binding every interface is not a
  destination — and an address derived from the daemon's own listen configuration counts as
  naming this machine, so the token is attached. An explicit --registry/--tunnel target
  is unchanged: the token still goes only to a loopback URL.

start-cli Checksums

SHA-256

63b067c3491a29bfbcd0424fff4bc04f6baaf501146b55d495563fc9e98cff0f  start-cli_aarch64-linux
ccb68e3c390959bbb4ab74d105dd753504b3f73833670149bc909cc49d10be02  start-cli_aarch64-macos
4c080f04c5e8747ecfabc2a888aae394a546d28c409c4fdc80b2568cd07a9e98  start-cli_riscv64-linux
830c3b25833fed7cfb16b377172125e35aa75a27a356862776358bd21293023d  start-cli_x86_64-linux
84116b53a4f4a6f349f1c02bdb9c90375726d50a8d8166b9167e1cbabd6f4613  start-cli_x86_64-macos

BLAKE-3

7849ef9035ee0ee53332e8eb94d91b99bf4173e698eca8c71683802fc7e65919  start-cli_aarch64-linux
18463fce9d51dbc7f45669af719ba9ea57f8c4148e86f8c17edf9b180f5a19d9  start-cli_aarch64-macos
7c7cc7d9d7b0bc8f726b0f7eee21e96809dbff371ec7b6d0b5ed88941437c064  start-cli_riscv64-linux
4325519150f550ac24d4148e4d4284490754e3d4e23b8d3e6ddaed3c628bbd66  start-cli_x86_64-linux
7ce97010e1fbfbae88f94dd35b936382d07b3705637025af50128186317157a3  start-cli_x86_64-macos

start-cli packages Checksums

SHA-256

439cf6f195d8cd19f927319eb269a73493512f7d7fcfd0236034f49493982ab2  start-cli_2.0.0_amd64.deb
528fef27353f5b853f94f655daae1bced8926fccd46a9dbb0ed869598d306cd9  start-cli_2.0.0_arm64.deb
37a13f2109d818f98f60d6b885fcbbaff41c61659fe7663d77fcb5db64c6c93b  start-cli_2.0.0_riscv64.deb

BLAKE-3

e1e6a867bf543cbaa5e8f228bacd68649673843fea26120b86219275df2db5ff  start-cli_2.0.0_amd64.deb
20db4872d15451a8546aaad16ea5a96457eb7993c5b2b992e722c20c24499a2d  start-cli_2.0.0_arm64.deb
1bb2b1f5dd7c5789229dcefc341a9a20ce711169fa700ce6f03c02bec0814452  start-cli_2.0.0_riscv64.deb