Build status

Ditana maintains its own pacman repository on top of Arch — a few dozen packages, listed in full in every run below. Every night a build host pulls each package’s recipe, decides what needs rebuilding, and builds it in a clean container. The rule that governs what happens next is the only one that matters here:

If a single package cannot be built, or its sources cannot be verified, nothing is published.

Not “the rest ships and that one is retried tomorrow”. Nothing. The repository you install from is either the complete, mutually consistent set that came out of one run, or it is yesterday’s complete, mutually consistent set. A smaller repository can promise that; a large one, updating package by package, cannot — which is why Ditana keeps its own small enough to vouch for as one set.

A claim like that is worth exactly as much as its evidence, so the record below is written by the pipeline itself, including the runs where nothing shipped.

Loading the build record…

How far a run got

Every run passes through the same stages, and its outcome says which one it reached. These are the four states, and the colours above:

outcome	What it means for you
released	This is what you install. Every package built, every signature verified, and the whole set replaced the repository your system updates from.
in-testing	Built and signed, sitting in a separate testing repository while it is checked. Your system still installs the previous release.
built	The build host finished, but it holds no signing key — signing happens afterwards on another machine. Nothing has moved yet.
held-back	Something did not pass, so nothing shipped at all. The repository you install from is untouched and still consistent.

Only released means the packages reached you. The other three are stages on the way there, or a stop.

What happened to each package

Within a run, every package gets one status:

status	Meaning
current	The recipe has not changed since the existing package was built, and for a -git package the upstream commit has not moved either. Nothing to do.
rebuilt	Sources were fetched and verified on the host, then the package was built in a fresh container.
review-stopped	The recipe changed in a way a human has to look at. The run ends here.
build-failed	The package did not compile, or produced no artefact. The run ends here.

The last two are why a run ends as held-back: one package is enough.

Why a run stops

Most of what Ditana rebuilds are third-party AUR recipes, packaged into a repository its users trust through pacman’s signature configuration. The AUR is a supply chain, and it has been attacked as one: orphaned packages have been adopted and given malicious commits, which is why the AUR disabled adoption and pushes in August 2026.

So every git pull in the pipeline is classified before anything is built. Version bumps, comments, whitespace and checksums that accompany a version change are waved through. A change to source=, to a url=, to a VCS revision, to anything inside a function, to install=, to provides=, conflicts=, replaces= or validpgpkeys=, a checksum that changes without a version changing, a new dependency pacman does not know, a changed or emptied # Maintainer: line — each of those stops the run. The recipe is never sourced to do this: executing the file under suspicion is precisely what has to be avoided, so the analysis is static, and it fails closed when it is unsure.

Measured against the last twelve months of real package history, this stops a run roughly once every three and a half days. That is not a defect to be tuned away; it is the price of the all-or-nothing rule, paid in advance.

What this does not check

The review covers packaging metadata, not upstream source code. When a recipe builds from a git revision, that revision’s contents are not reviewed by anything in this pipeline. Ditana’s advantage over an unreviewed rebuild service is real but bounded, and stating the bound is part of the claim.

Where the signing key is

The machine that builds is not the machine that signs.

The build host compiles unreviewed upstream code, so it holds no key at all and cannot reach the publish servers. It produces unsigned artefacts and a record like the ones above, and its runs stop at built. A separate machine, holding the key, collects those artefacts, signs them, assembles the repository database and publishes it — and that run reaches in-testing, then released.

What this protects is the key, not the packages: the signing machine signs what the build host produced, without reviewing it. What it prevents is the machine that runs foreign build scripts being able to have arbitrary data signed at any time.

Verifying this yourself

The record is plain JSON and is not generated by this website:

• /build-history/index.json — the rolling index of the most recent runs.
• /build-history/<timestamp>.json — one file per run: outcome, counts, and a packages array whose entries carry name, status, seconds, any detail, and the paths of that package’s logs.
• /build-history/logs/<timestamp>/<package>/ — what makepkg logged while building that package, split by stage (prepare, build, check, package). Every rebuilt package in a run is linked from its row above, and a package whose build failed is logged too — that is the one worth reading.

Server names, addresses, paths and the build account’s login name are removed from the records and from the logs before they are written. Nothing else is filtered; the failure text you see is the failure text the pipeline saw.

Under which licences

Every package here is built from a publicly available recipe that names its upstream source. Licensing says where to find both, and covers the one case where the licence itself is contested: the ZFS packages, of which Ditana distributes the sources and the userspace tools but never a compiled kernel module.