Note
It’s recommended to read this Quickstart on the mini-buildd instance in question itself, else some of the links here will not work as-is.
As a convention, we write code you should run as root like:
# apt-get install FOO
and code you should run as user like:
? mini-buildd-tool HOST status
In code snippets, names written all-capital (FOO, HOST) are not meant literal but placeholders for customized values.
Goal: Initial fully working setup with the sandbox repository test.
Prepare to set your admin password when installing, otherwise just stick to the defaults:
# apt-get install mini-buildd
Note
In case you are both, extraordinary hasty and adventurous, you may just run this:
? /usr/share/doc/mini-buildd/examples/auto-setup
This will basically try to run this whole section non-interactively, with all defaults. If you really just want a quick test-drive, this might be for you. All others should just read on.
Note
Read Setup below: Run the full prepare, check and activate treat (ugh!) from model’s list view to make them green.
Note
Using the wizards is mostly harmless; calling them is idempotent, and they will never touch any existing setup.
Enter the web application’s configuration section and login as superuser admin.
Daemon green? Go on.
Note
Daemon prepare will generate your instance ID (read: GnuPG key); you may need to generate some entropy (install haveged maybe) on the system if this stalls.
Note
The Daemon identity will hereafter be referred to as ARCHIVE.
All wanted sources green? Go on.
Note
Setup of Sources will implicitly pull in architectures and components, and also implicitly sets up the apt keys associated to them. Purists may want to re-check them manually.
test repository green? Go on.
All wanted chroots green? Done!
Note
Preparing chroots may take a while; if you cancel the HTTP request in your browser, preparation will continue anyway.
Note
Don’t add or delete Uploader instances manually; these are bound to users, and come automatically when new users are created. The administrator only changes these instances to grant rights.
Enter web application’s home (stay logged-in as admin).
Start the daemon.
Note
Just reload the home page to update the packager and builder status.
Note
Just show “Last packages”, and click on the keyring’s source package name to get to the package’s overview where you can migrate (also see the User’s Quickstart).
Optionally build the internal test packages.
When your are confident with the test repository setup, just create a new Repository instance with the actual ID you want to use for production.
Think about how you want to do upload authorization for that production repository; see authorization below.
Goal: Walk through the most important use cases.
The resp. archive’s keyring package includes both, the APT key as well as a “library” of all sources available (for easy integration via /etc/apt/sources.list.d/).
However, the keyring package also is in the archive, so we need some initial fiddling to get it installed in the first place.
1st, on mini-buildd’s home, jump to the repository overview page (if there are more than one, use the repository you intend to actually use on the system later). Select the stable suite of your base distribution’s (i.e., squeeze, wheezy, jessie,...) APT line, and then:
# echo "APT_LINE" >/etc/apt/sources.list.d/tmp.list
# apt-get update
# apt-get --allow-unauthenticated install ARCHIVE-archive-keyring
# rm /etc/apt/sources.list.d/tmp.list
Note
You may also get the resp. APT line via mini-buildd-tool via the getsourceslist API call in case you have it installed already.
Note
You may compare the key’ fingerprint (apt-key finger) with the one on mini-buildd’s home. There might also be other means set up by the local administrator to cross-verify the key.
2nd, re-add the stable sources.list back in via “sources.list library”, somewhat like:
# cd /etc/apt/sources.list.d
# ln -s /usr/share/mini-buildd/sources.list.d/CODENAME_ARCHIVE_REPO_stable.list .
# apt-get update
Now you can opt in or out other sources from the archive just by adding or removing symlinks.
Access API calls from the command line via mini-buildd-tool:
# apt-get install python-mini-buildd
The remaining Quickstart will just use mini-buildd-tool as example, however the API could also just be accessed via the web interface.
A user account may be needed to, for example, create package subscriptions, access restricted API calls, or upload your GnuPG public key.
Install dput, and setup your ~/.dput.cf:
# apt-get install dput
? mini-buildd-tool HOST getdputconf >>~/.dput.cf
Upload authorization works via a GnuPG allowed keyring.
Note
For the administrator: See /usr/share/doc/mini-buildd/examples/ssh-uploader-command should you be interested in manually setting up a ssh-based authorization wrapper.
As this depends on the setup of the mini-buildd instance and/or repository your are using, this cannot be answered generically.
You will be able to upload to a repository when
For the latter, the workflow is roughly:
Just like always, via dput. For the default configuration you get via getdputconf it’s something like:
? dput mini-buildd-ARCHIVE FOO.changes
Per web on mini-buildd’s home: You will always find the packages currently being build displayed here, plus a list of the last N packages build, and of course appropriate links to build logs, changes, etc.
You can search for (binary and source) package names via API:list, using shell-like patterns:
? mini-buildd-tool HOST list '*-archive-keyring'
You can view a source package overview via the API:show call (put in your actual daemon identity):
? mini-buildd-tool HOST show ARCHIVE-archive-keyring
You will find more options to manage packages like API::migrate, API::remove, API::port in this web page overview.
You can automatically port packages already in the repository (API::port) as well as arbitrary external source packages (API::portext).
For internal ports, checkout the options you have in the source package view; for external ports, go to mini-buildd’s home and check the options for the repositories.
Note
Internal ports may also be triggered automatically on uploads via a ‘magic lines’ in the Debian changelog, see (-> Manual).