Installing¶

Release binaries¶

Each release has a ready-built rettui for:

Unpack it and put rettui somewhere on your PATH. SHA256SUMS has the checksums.

• Linux: the binaries need glibc 2.35 or newer (Ubuntu 22.04, Debian 12 or later).
• macOS: the binaries aren't notarised. If macOS won't open one, run xattr -d com.apple.quarantine rettui.
• Docker: see Docker for the image.

Packages¶

• Debian, Ubuntu, Raspberry Pi OS: each release has a Debian package for x86-64 (rettui_<version>_amd64.deb) and ARM64 (rettui_<version>_arm64.deb): sudo apt install ./rettui_<version>_amd64.deb. It puts rettui in /usr/bin; a newer release's package installs over it the same way.
• Arch Linux: the AUR's rettui-bin package (the ready-built binary): yay -S rettui-bin, or any AUR helper. Each release also has its PKGBUILD: put it in a folder of its own and run makepkg -si there.
• Homebrew (macOS and Linux): brew install zevaryx/rettui/rettui, from rettui's tap.

Installed by a package manager, rettui leaves updating to it.

Building from source¶

git clone --recursive <this repo>   # or: git submodule update --init
cargo build --release

The three libraries are git submodules under deps/. Each one expects the others to be checked out next to it (for example ../rsReticulum). They are pinned to revisions that build together:

Once ratspeak/rsReticulum#26 is merged, point deps/rsReticulum back at ratspeak/rsReticulum in .gitmodules and pin its main.

Updating¶

rettui can check once a day whether a newer release is out. It's recommended, but off until you turn it on: tick Check for updates once a day in the getting-started guide, or turn on Check for updates (Status, update_check). When a newer release is out:

• the version beside the name, top left, is marked ↑ (in yellow, in both UIs), and opens the new release's page;
• Status says which release, with a link to what's new;
• the log says so, once.

Version, under Identity in Status, says which version this is and what kind of build (a release build, and for which system, or one built from source), and what the last check found and when. To check now, whether or not Check for updates is on: u in the terminal UI's Status tab, or Check now in the web UI's Status page. It says what it found (this is the newest release, a newer one is out, or why it couldn't check), and a newer one found this way shows as above, ready to install. With Check for updates off and nothing checked by hand since rettui started, Version says so rather than show an older check's answer.

Checking downloads and installs nothing. To update:

• A binary from the releases page can install the new release itself, when you ask: U in the terminal UI's Status tab, Install beside the update in the web UI's Status page, or rettui update (which checks first, whether or not Check for updates is on, and asks before installing; --yes doesn't ask). It downloads the release's archive for your system from GitHub with its SHA256SUMS, checks the one against the other, and runs the new rettui once (--version) to be sure it works on your computer before it replaces the old one. rettui carries on as it was: start it again (for a service, restart it) to use the new one. The checksums come from the same release, so they catch a download gone wrong, not a release that isn't rettui's.
• By hand: put the new release's binary in place of the old one, and start it again. The data directory stays as it is.
• Docker: docker compose pull, then docker compose up -d. (A container's rettui doesn't replace itself: it would be lost with the container.)
• From source: git pull --recurse-submodules, and build again.
• A package manager's (a Debian package, the AUR's, Homebrew's): update it with that one, as with anything else it installed.

The check is one HTTPS request a day to GitHub's API (api.github.com), through the proxy set in the environment if there is one, with rettui's name and version as its user agent. Like rettui's other requests to the web (background notifications, map tiles), it trusts this computer's certificates as well as the ones rettui comes with, so it works behind a proxy that inspects HTTPS. What it found is kept in update-check.json in the data directory, so starting again doesn't ask again. If it can't reach GitHub (offline, say), it tries again an hour later, without a word. GitHub sees your IP address, as any website does, so leave it off if you use Reticulum to stay off the internet (over Tor or I2P, say). Off, it never asks.