Hi again Marc, On Mi, 2015-07-01 at 18:36 +0200, Marc Haber wrote: > Source: mini-buildd > Version: 1.0.7 > Severity: wishlist > > I am currently in the process of migrating an old mini-buildd setup > from 0.9x to 1.0.7. Due to issues when the package was upgraded, I > took a backup of the old mini-buildd home directory, purged the old > package and started over from scratch. > > Hence, my new mini-buildd setup has gotten a new archive signing key. > Since I would like to save myself from logging in to all my machines > to install the new key, I'd like to import the old archive signing key > into the new mini-buildd instance. > > Is it ok to simply replace the keyring files and to re-create the > archive key packages? Please document this and if not, outline a > migration way.
actually, it should be (nearly) that simple. I have not tested this myself, but basically, something like this should work: --- Import a foreign archive key to an existing mini-buildd instance ================================================================ 1. Stop the mini-buildd service. 2. Become the mini-buildd user. 3. Manipulate the user's GPG keyring * Be sure it contains exactly one key (pub+sec) when done. 4. (Re)start the mini-buildd service. * Check that the Daemon key has actually changed (f.e., on the web home, right bottom). 5. Make a pseudo change to all repository instances. * Just enter the repo editor, don't actually change anything, but do "save". * This fixes the status to "Prepared (Changed)" (matching the external manipulation). 6. "PCA" ((re)prepare, check, create) all repositories. * This should bring the new key to the reprepro indices. 7. Re-create keyring packages. .. note:: The Daemon instance does not touch the GPG once it's created -- _unless you do an explicit remove_ on the instance. --- So this sketch may go to the docs later -- maybe when you have proven this actually works ;). Hth, S P.S.: Fwiw, just in case you should be so inclined to consider contributing documentation (or other things) yourself directly, I would really appreciate that ;): This is what could do, should that be the case: 1. clone the repo from alioth 2. branch from 1.0.x to something like feature/mhaber [Note: 1.2 dev on master hasn't even kicked off yet, and 1.0.x is frequently merged.] 3. add && push your proposed updates there To build the docs locally && test them, do s.th. like: 1. mk-build-deps --root-cmd sudo --install --remove 2. python setup.py build_sphinx --source-dir=build/sphinx 3. BROWSER build/sphinx/html/index.html Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
