roro9stack

233 Commits 43 Branches 27 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
twislaandClaude Opus 5.5	472f13260f	Updates: a download that breaks is carried on Site / build (pull_request) Successful in 11s Details CI / build (pull_request) Successful in 2m6s Details When the connection breaks during a release download (issue #54), the device waits up to a minute for Wi-Fi, asks for the rest of the file with a Range request and carries on: the slot and the hash so far are kept. It gives up after three tries in a row that bring nothing. Nothing is kept across a restart. Carrying on asks for 64 KB free, not 80: between two connections of an install 78 KB is free, and the first attempt on the device was refused for that. update damage cut now breaks every connection after n bytes. Tried on the device: v0.23.0 installed over four connections, and a download that brought nothing given up with nothing switched. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0162FokPdvY2KsS4NBfwyWPk	2026-10-11 18:26:39 +02:00
twislaandClaude Sonnet 5.5	510ce42a99	Updates from Gitea, step 3: install from Gitea, and IRC steps aside for it A release downloads straight into the inactive slot through the existing install path: the signature is checked after 160 bytes, before anything is written, the hash at the end. Tried on the device against the real server: a download cut short, a flipped byte in the signature and one in the image are each refused with the running firmware untouched; the real v0.10.0 installed, restarted, and confirmed itself on Probation. A TLS connection to Gitea peaks at about 52 KB of heap whether or not the certificate is verified. With IRC connected (66 KB free) a check left 3 KB and a download 836 bytes. A check, list or install a person asks for now makes IRC step aside (holdForUpdate) and come back after: the lowest free heap during a full download with IRC connected is 38 KB. The daily check never interrupts IRC; with IRC up it waits. A TLS connection starts with 80 KB free (it was 55). Debug Builds get test knobs: update probe <host>, update damage cut\|flip, update pretend <version>. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT	2026-10-06 15:51:10 +02:00
twislaandClaude Sonnet 5.5	5754ae5b57	Updates from Gitea, step 2: the connection (check and list work on the device) The roots (ISRG X1 and X2), an HTTPS client that reads the answer as a stream, GiteaReleases (the latest and a list of ten), the Update Service's requests, install from Gitea through the existing install path, the daily check's schedule, the Check for updates setting, and console commands: update check \| list \| status \| install <tag>. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT	2026-10-06 15:20:58 +02:00

Author

SHA1

Message

Date

twislaandClaude Opus 5.5

472f13260f

Updates: a download that breaks is carried on

Site / build (pull_request) Successful in 11s

Details

CI / build (pull_request) Successful in 2m6s

Details

When the connection breaks during a release download (issue #54), the
device waits up to a minute for Wi-Fi, asks for the rest of the file
with a Range request and carries on: the slot and the hash so far are
kept. It gives up after three tries in a row that bring nothing.
Nothing is kept across a restart.

Carrying on asks for 64 KB free, not 80: between two connections of an
install 78 KB is free, and the first attempt on the device was refused
for that. update damage cut now breaks every connection after n bytes.

Tried on the device: v0.23.0 installed over four connections, and a
download that brought nothing given up with nothing switched.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0162FokPdvY2KsS4NBfwyWPk

2026-10-11 18:26:39 +02:00

twislaandClaude Sonnet 5.5

510ce42a99

Updates from Gitea, step 3: install from Gitea, and IRC steps aside for it

A release downloads straight into the inactive slot through the existing
install path: the signature is checked after 160 bytes, before anything
is written, the hash at the end. Tried on the device against the real
server: a download cut short, a flipped byte in the signature and one in
the image are each refused with the running firmware untouched; the real
v0.10.0 installed, restarted, and confirmed itself on Probation.

A TLS connection to Gitea peaks at about 52 KB of heap whether or not the
certificate is verified. With IRC connected (66 KB free) a check left 3 KB
and a download 836 bytes. A check, list or install a person asks for now
makes IRC step aside (holdForUpdate) and come back after: the lowest free
heap during a full download with IRC connected is 38 KB. The daily check
never interrupts IRC; with IRC up it waits. A TLS connection starts with
80 KB free (it was 55).

Debug Builds get test knobs: update probe <host>, update damage cut|flip,
update pretend <version>.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

2026-10-06 15:51:10 +02:00

twislaandClaude Sonnet 5.5

5754ae5b57

Updates from Gitea, step 2: the connection (check and list work on the device)

The roots (ISRG X1 and X2), an HTTPS client that reads the answer as a
stream, GiteaReleases (the latest and a list of ten), the Update
Service's requests, install from Gitea through the existing install path,
the daily check's schedule, the Check for updates setting, and console
commands: update check | list | status | install <tag>.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

2026-10-06 15:20:58 +02:00