Published: Fri Jul 19 13:20:37 UTC 2019
Updated: Sun Sep 01 16:47:32 UTC 2019
By Stephan Sürken
In 2019 .
The Debian buster release implicitly inflicts some mandatary (new
apt keys!) as well as some minor recommended housekeeping on an
existing mini-buildd installation.
So this is what I would recommend you to do -- assuming a basic
setup, near to what the wizards would set up automatically.
Given how the configuration currently works (i.e., affecting
dependencies when you change things), you might want
to stop the daemon before starting your housekeeping
and try to get all your changes done in one flow (to minimize the costly "PCA action" on repos and chroots later...)
1.0.42 adds wizard-support for new sources now available (like
buster, buster-backports, stretch-backports-sloppy, and also the new
Ubuntu release). Obviously not mandatory, but it will really helps in
housekeeping.
Please read why and where 1.0.x maintenance has moved to and
check the home page overview if that version is
available for the system your mini-buildd runs on.
With 1.0.42 installed, run (in the admin configuration):
Sources:Sources Debian wizard: Will get you new Debian sources the wizard knows about.Sources:Priority sources Extras wizard: Adds prio sources for new sources from last step.
There are three new keys from Debian:
Chances are they have already been added by the source wizard run
before. Make sure you have these as AptKeys instances, verify
and make them shiny green.
With the release of buster, repo keys have also changed in
non-buster|bullseye|sid sources. Previously existing sources need to
be updated manually. For convenience, here is a list you will likely
need to fix up:
sid: DC30D7C23CBBABEE, E0B11894F66AEC98
buster: E0B11894F66AEC98, EF0F382A1A7B6500, DCC9EFBF77E11517, DC30D7C23CBBABEE
buster/updates: EDA0D2388AE22BA9, 4DFAB270CAA96DFA
stretch: 7638D0442B90D010, E0B11894F66AEC98, EF0F382A1A7B6500
stretch-backports: 7638D0442B90D010, E0B11894F66AEC98
stretch/updates: 9D6D8F6BC857C906, EDA0D2388AE22BA9
jessie/updates: 9D6D8F6BC857C906, EDA0D2388AE22BA9
This manual update process is currently a PITA really, and there
should be something way more convenient eventually.
See: https://ftp-master.debian.org/keys.html , debian-archive-keyring package, apt-key.
Buster's release version (as configured in the buster Source )
should currently be "BUSTER" or "~BUSTER". Now with buster
released, this must be replaced by the actual release version.
FWIW: This default scheme will put you in the position to distinguish
between packages build while buster was rolling, and after buster
was released, just via the package version -- hinting you on what
packages you might want/need to rebuild on the actual finsihed stable
release.
To do this, just go the the buster Source instance, reveal the "Extra" section, and either
Recommended : Override with "100" or remove the override string (this let's mbd guess on check , which will lead to "100" for 1.0.x).Override with "10" (this is the current Debian scheme using only one number as main release version. New default in development mini-buildd).
Note that using option 2 may lead to dist-upgrade issues for packages
from, for example, a stretch distribution using "90" -- for packages
with otherwise the very same versioning. So only use that if you
(understand this and) are up to instruct your repo users on remedies,
or if you are using the new scheme consistently already anyway.
bullseye should be available as new testing. Be sure to have the new
bullseye Source activated (PCA):
Run Repositories:Distributions:Default wizard, which should give you the new Distribution for bullseye .
Add the new bullseye Distribution to the resp. repositories.
Run Chroots:Default wizard (on the backend you are using). Thus should give new buster chroots.
... now that you are at it anyway :).
mini-buildd always keeps the base chroots up to date, so this is
actually not strictly really necessary. However ;), as a safeguard
against any possible evilry that might have crept into your existing
base chroots, you might want to do this; there are no drawbacks, it
just take some time.
Just Remove the chroots you want to recreate, and then run PCA on it again.
Be sure everything you want is finally "green " in the admin config
overview (merciless run "PCA " on everything that's not ;).
Then, don't forget to restart the Daemon once (either by clicking an
stop/start as admin in the web app) or just by just restarting the
service:
# service mini-buildd restart
-- else you might experience subtle misbehaviours ;).
In case you have mutiple instances, you unfortunately need to do these
manual updates (or at least parts of it) on each of these.
In case you created new Distributions, you should build new keyring
packages (and migrate the new packages up to stable , at least for
new Distributions).
Hth!
S