Main Components
mini-buildd does not re-invent the wheel, it’s rather a
sophisticated glue written in python to a number of
standard (Debian) or off-the-shelf software components. The most
prominent parts are:
Component |
Used for |
Realized with |
HTTP server |
Web application, repository delivery |
cherrypy3 |
Web application |
Configuration, package tracking |
python-django |
FTP server |
Incoming (user uploads, build requests and results) |
python-pyftpdlib |
Packager |
Source package manager, build distribution |
|
Builder |
Package builds |
sbuild / schroot combo using snapshot-able chroots. |
Repository |
APT package archive |
reprepro |
Features
Core features:
- Integrated HTTP server (webapp and repository delivery).
- Integrated FTP server (incoming).
- Web-based configuration, with integrated managing of chroots and repositories.
- Distributed builders.
- Web-based or command line repository maintenance via API calls.
Some prominent extras:
- mini-buildd-tool: Use from the command line, write scripts.
- User management: Package subscriptions, GPG key management, upload authorization.
- Package QA: Internal sanity checks, version enforcing, lintian.
- Package Tracking: Debian PTS-like web based source package tracker.
- No-Changes-Ports: Automates these ports for internal or external source packages.
- Rollback handling: Keeps N rollbacks for any distribution.
- Builds keyring packages automatically.
The FAQ, Hints, Todos, Troubleshooting, Bugs section may also help you to figure out what
mini-buildd is not, or not yet.
Basic Mode Of Operation
mini-buildd is a Unix daemon written in python. When
running, it provides a HTTP server (on port 8066 by default).
The HTTP server serves both, mini-buildd’s web application as
well as the delivery of the package repositories.
The instance is being configured in the configuration section of
the web application.
As soon as a mini-buildd instance has been configured to have
an active ‘Daemon’, you may start the engine, running an FTP
server (on port 8067 by default).
The FTP server acts on incoming *.changes files, both from
developers and other mini-buildd instances (via special
buildrequest and buildresult changes).
As soon as an instance of mini-buildd has active chroots
configured, it acts as builder. Chroots are completely generic
and interchangeable, and identified by codename and arch
only; distribution-specific build configuration is all carried
through the internal buildrequests. Thus, mini-buildd
instances may be interconnected as so-called ‘Remotes’ to share
builders.
This is a simplified example mini-buildd ‘network’ with three
mini-buildd instances ernie, grover and bert:
- ernie has repositories and chroots, and uses himself and grover as remote for building.
- grover only has chroots, and is used by ernie and bert for building.
- bert only has repositories, and uses ernie and grover as remotes for building.