Titanium Devops Release Notes

Titan starts on a machine where no Tiiny answers. In 0.1.17 it did not: the search found nothing, and the app exited saying "Cannot read configuration; check config.json and your command-line settings." config.json was fine. The real reason was a refusal that said no Tiiny was found, and the sentence about config.json was printed over it.

That was a dead end with no way out. Settings > Model is where you type your device's address, and you cannot reach Settings if the console never comes up. Titan now starts anyway and says so, in the terminal and in the farm's log:

No Tiiny found on this machine, its USB links or its network. Titan is
starting anyway. Open Settings > Model to enter the address, or run
farm device and start it again.

A device that was never set up is no longer told to "check its address", which is no help to somebody who has never given one, and it is never called: nothing is sent to an address nobody chose.

A refusal now says its own sentence. Only a configuration that genuinely cannot be read gets the sentence about configuration. …

Titanium Tiiny Bot now runs on Windows. 0.1.16 stopped at its first import there, on import fcntl, which is POSIX only, so a person who installed it through the launcher got a traceback instead of an app. Both file locks now go through a small shim: flock on POSIX, msvcrt on Windows, with a refused lock looking the same to every caller.

Four more things behind it would have failed next: the memory reading in Settings, the O_NOFOLLOW flag on six file opens, the lock file's permissions, and a liveness probe that on Windows would have killed the process it was asking about.

The app had never been run on Windows by anything, so this release also adds CI on Linux, macOS and Windows, which found three more:

• Text files were read with the machine's own encoding. On Windows that is cp1252, which cannot decode the seed files, so the app crashed again as soon as the lock fix let it get that far.
• Memory recall returned nothing at all on Windows, silently. Saved facts were recorded with a backslash path that the code matching on "memory/log/" could never match, so every fact fell out of the prompt while the console still listed them.
• Starting up waited on a reverse DNS lookup of the address being bound. That measured 35 seconds on one machine, against a 5 second budget, and it was never a Windows problem: a laptop on a slow network is the same machine. …

Finds the Tiiny instead of shipping a hostname that resolves on one Mac.

The default model address was http://openai.api.tiiny/v1, a name the TiinyOS desktop app writes into /etc/resolver. It resolved on that Mac and nowhere else, and on that Mac the voice lifecycle path's Host: p8800.api.tiiny header reached the local proxy and came back 502.

• base now defaults to empty, meaning find the device. TIINY_BASE, then ~/.tiinyapps/device.json, then a search of every attached USB /30 peer and this machine's own /24 on :39218, which is unauthenticated and carries the serial so a box answering on both Wi-Fi and USB is recognised as one box. Then it asks the box which port serves the gateway: 1.0 refuses 8800 from another machine, older firmware serves it there. Empty stays empty in config.json, because writing today's DHCP address into a file is how this breaks next week.
• No subprocess, which the farm's scanner and tests/test_server.py both enforce: local addresses come from a UDP connect that sends no packet, and from bind(), which succeeds only on an address this host owns.
• lite/onelane.py replaced with the current OneLane library. The vendored copy predated the 1.0 port fix and hardcoded 8800.
• Device hands the lane its port, instead of letting the library spend two HTTP probes rediscovering it.
• voice.py sends the vhost header only when the gateway is on port 80, so lifecycle calls do not point at the wrong service on older firmware. …