Build status
Ditana maintains its own pacman repository of 56 packages on top of Arch. 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 to 56 packages it can vouch for together.
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.
Recent runs
One square per run, newest on the right. Select one to see what happened to every package.
Loading the build record…
How to read a run
Section titled “How to read a run”Each run visits all 56 packages in order and gives every one of them a verdict:
| Verdict | Meaning |
|---|---|
| already 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 that 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 run as a whole ends in one of three states:
| Outcome | Meaning |
|---|---|
| published | Every package passed. The artefacts were signed, uploaded, and the repository was replaced as a unit. |
| built | Every package passed on a build host that holds no signing key. Signing and publishing happen afterwards on a separate machine — see below. |
| held back | Something did not pass. Nothing was uploaded and nothing was promoted; the published repository is untouched and still consistent. |
Why a run stops
Section titled “Why a run stops”Ditana rebuilds 43 third-party AUR recipes 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
Section titled “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
Section titled “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 end in built. A separate machine, holding the key, collects those artefacts, signs them, assembles the repository database and publishes it — and that run ends in published.
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
Section titled “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, with every package’s verdict./build-history/logs/<timestamp>/<package>/— whatmakepkglogged 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
Section titled “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.