Emdebian Grip Guide

Handling a Debian release affecting Emdebian Grip

[ overrides ] [ building Grip ] [ testing suite ] [ handling a release ]

Sequence of operations

The order in which the tasks get done is vitally important. Make doubly sure that each stage is complete before moving on. The release process takes a couple of hours for a repository like the main Grip archive - it is not just a case of "moving a symlink".

Preparation

Run emgrip-dupes on the current testing suite (unstable is less important at this stage and can be left to later).
Run edos-debcheck against the most popular architectures.
```
$ edos-debcheck -explain -failures < dists/testing/main/binary-$arch/Packages
```
A similar report is included in all the grip build logs, generated via the cron task.

Now work out which packages need to be handled. (This task is one of those which should be done intermittently - leaving the entire task to the time of the release would be a bad mistake.) Bear in mind that some problematic packages may actually have been removed from Debian testing, always check with packages.qa.debian.org/$package-name.

The actual commands at this stage will vary each release. You may need to unconditionally remove packages from testing - emgrip-remove might be useful, you may need to issue reprepro commands directly (take care when removing binary packages which match the source package name - if you want another binary package from that source to be retained, you will have to remove each architecture - except source - individually. Other packages may need individual handling of versions which were put into testing-proposed-updates or otherwise missed by the grip migration process.

Only proceed when you are sure that the repository is in a suitable state, with as few dependency issues as possible. (The more often these tasks are performed during the release freeze, the easier it will be to manage the release itself.) It's not as if Debian releases happen suddenly, make use of the time spent in the freeze by trying to avoid problems when the release actually happens.
Stop the cron task

Editing reprepro files

If you are unsure of what needs to be done and what needs changing, it is often easiest to start with either the filter or locale repositories. Remember that all three repositories need to be "released" - the cron task will not restart correctly if the filter repository is not updated. Again, a strict sequence is useful:

Change stable to oldstable - you may need to turn off the ReadOnly: yes instruction in conf/distributions as well as changing the suite from stable to oldstable. No other changes are needed in this stanza.
Change stable-proposed-updates - decide if you are going to offer oldstable-proposed-updates and change stable-proposed-updates to the relevant suite. If you decide not to offer oldstable-proposed-updates, you will need to clear the old codename from the database after editing conf/distributions:
```
$ reprepro clearvanished
```
Backup the testing stanza as comments - this will save time later. Copy the entire testing stanza and comment out each line.
Change testing to stable - don't add the read only flag yet, remember to change the version number and update the description lines to indicate stable instead of testing. Comment out any update rules.
Change unstable version string - e.g. if you are releasing version 2.0, unstable is typically version 1.1 before the release and 2.1 after the release.
Export the repository - at this point, there is no testing suite but it is as well to export stable at this point.
```
$ reprepro -v export
$ reprepro --delete createsymlinks
```
Create the new testing - edit the commented out stanza to set the appropriate version (for testing, normally the same as sid) and enter the appropriate codename (e.g. wheezy instead of squeeze). Uncomment the stanza and export the new codename. e.g. for the squeeze release, the new codename was "wheezy".
```
$ reprepro -v export wheezy
$ reprepro --delete createsymlinks
```
Check the results - the critical part of a release is the dists directory. A simple ls -l dists/ will show what has actually been achieved. Make sure that the symlinks point to the correct places.

Repeat twice

Now repeat the process - ensure that all three of the Grip repositories are edited and released, grip, locale and filter.

Push to mirrors

Push the changes to the mirrors - depending on your push configuration.

Come back later

Take a break - come back later once the release itself has been tested. What remains now is to restart the cron task, first ensure that the filter repository updates cleanly:

$ reprepro -b ../filter -v update

Debian may well change the archive signing key shortly after a release, so check ftp-master.debian.org for updates and add this key to the gnupg public keyring of the user running the cron task.

Now reinstate the original cron task. Done.

Back to the Emdebian Project homepage.