Two branches described under three names, and the default build waits on a menu

One stable line, three names, and a misspelled heading

The section that explains the branches has a heading saying the repository is split into stable and master, and the paragraph underneath describes a line called Ciao and a line called Master. The badge row at the bottom of the page then calls the reliable line firmware-stable, and the continuous integration workflow behind it is named for the same thing. So the same line appears as stable, as ciao and as firmware-stable in three places within one page, and the default branch of the repository is the development one. The heading itself is also misspelled. None of this breaks anything, since branch names and workflow names are free text, but it is the kind of drift that makes a newcomer unsure whether they are reading about one line or two.

Tags are dates, and the prefix tells you the line

The three visible releases are named by date rather than by version, and they carry two different prefixes. Two start with the reliable prefix and one starts with the master prefix. That is a sensible scheme for firmware, where a build is identified by the day it was produced rather than by a marketing version, and it means the tag itself records which line a given image came from. The visible history is tight: two images four days apart on the reliable line and one on the development line. Nothing on the page maps those tags to model numbers of cameras, so matching a tag to a device model means reading the build configuration rather than the release list, and the supported-hardware list lives in a separate document for the same reason.

The default build asks a question that automation cannot answer

The build makefile contains a comment block explaining two environment flags, and the first one exists because the default build is interactive. Without a flag, running make runs a dependency check and then waits for you to pick a camera from a menu, using either a fuzzy-finder or a dialog program depending on what is installed. In a pipeline there is nobody to answer, so the build would hang on input that never arrives. That is what the workflow flag is for: it skips both the dependency check and the interactive selection, on the assumption that the environment is already good and the camera is always passed on the command line. The dependency check also leaves a marker file behind, so it runs once rather than on every invocation, and it is skipped entirely for the update target.

A pristine mode points the user directory at nothing

The second flag is about reproducibility, and the mechanism is blunt. The pristine flag sets the user configuration directory to the null device, which means every layer that a local build would normally read simply does not exist. The comment spells out what that is protecting against: local user fragments, overlays, and a local settings file leaking into the image. That is aimed at people shipping the firmware on their own hardware rather than for themselves, where a stray local file would make two units built from the same commit differ. The documentation also describes how those layers normally work, and the layering is more granular than a single override: a shared layer, then per camera, then per device address, so a build can differ by unit without a separate branch.

The development line needs a serial console to recover

The warning above the branch descriptions is the most operationally important sentence on the page. The development line uses a highly experimental mainline build of the bootloader, and having access to the camera's serial port plus the ability to recover a bricked device is described as highly recommended before building images from it. That is a much stronger caveat than the one attached to the reliable line, which simply receives critical fixes and otherwise waits for features to mature on the development side and be brought across. The two lines also differ in their video stack, not only in their feature set: the reliable line keeps the original network video server and the original processor acceleration library, while the development line has moved to a newer streamer written by a third party.

Two build routes, one of them a container from a registry image

Building natively is three commands after the clone, with submodules fetched in the clone itself, an update step and then the build:

git clone --recurse-submodules https://github.com/themactep/thingino-firmware
cd thingino-firmware
make update
make

The container route replaces the last two with a script:

git clone --recurse-submodules https://github.com/themactep/thingino-firmware
cd thingino-firmware
./build-container.sh

That script uses a prebuilt builder image from the project's own container registry, pulled automatically on first run, and needs either a container runtime. So the two routes differ in what they assume: one wants the toolchain on your machine, the other wants a runtime and a network. Neither route is described as producing an image you can flash directly from the page, and the makefile carries variables for a file-transfer server address and root, which suggests the build can also upload the result somewhere rather than leaving it in a directory.

A vendored build system, six makefile fragments and a trash directory

The root shows how the project is put together. A build system is vendored as a directory, with its external-tree mechanism represented by two files at the root, and beside it sit a kernel directory, an overlay directory, a package directory of build recipes, and separate directories per board and per chip family, which is what makes one repository cover a range of cameras. Configuration is split across four template files, one for the host and one each for the sensor and the chip family. The build logic is fragmented across six makefiles, including ones for guided builds, over-the-air updates, containers and shared utilities, plus a top-level file and a per-board fragment. There is also a directory called trash whose purpose the page does not explain, and the documentation covers image layout, backing up existing firmware, recovering from a failed update, and the layered local settings.

Editorial conclusion

This suits someone running their own IP camera who wants community firmware instead of the vendor image, and who can read a serial console if an update goes wrong. Two things to know before you flash anything. The line described as reliable for general use also uses the older network video server and processor configuration, so it is not simply a subset of the development line; you are choosing between two stacks. And the development line's bootloader is described as highly experimental, with the documentation recommending serial-port access and recovery skills before you build from it, which is not a warning to disregard lightly on hardware you cannot easily reach.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes