Centos and Debian packaging

diff --git a/release.mdwn b/release.mdwn
index 5285d93..067ae6f 100644 (file)
--- a/release.mdwn
+++ b/release.mdwn
@@ -4,3 +4,10 @@ This page describes the release process used to generate new builds and packages
 
 * [[Test Builds|release/test]]
 * Committing to [[master|release/master]]
+* [[Centos Packaging|release/centos]]
+* [[Debian Packaging|release/debian]]
+* Producing [[Live DVD|release/dvd]] images
+
+In general, changes should be committed to master.  Test packages or
+test builds should be used to confirm they work with the automated
+tests.  Then packages should be built.

diff --git a/release/centos.mdwn b/release/centos.mdwn
new file mode 100644 (file)
index 0000000..7412953
--- /dev/null
+++ b/release/centos.mdwn
@@ -0,0 +1,59 @@
+[[!meta title="Releasing for Centos"]]
+
+Centos packages are built from [[master|branches]].   The procedures roughly works as follows:
+
+1. A normal configure; make; make install on Painless Security machines
+2. If this succeeds then a build is started on Janet machines
+
+1. Another round of configure; make; make instal.  This round include a make dist to produce distribution tar files.
+1. Run "rpmbuild -ta" on the distribution tar files.
+
+1. Copy the results back to moonshot.suchdamage.org
+
+# Spec file
+
+Centos packaging is controlled by a .spec file.  In most packages the spec file is produced by a .spec.in file.  This controls dependencies, installation procedures, etc.
+
+It's important that once a Centos package is placed into the archive it is never changed.  So, some component of the version number needs to be incremented whenever a new Centos package is desired.
+
+The version number is spread across two fields in the spec file:
+
+* Version: the upstream version number 
+* Release: a RPM-specific release number
+
+If the spec file is a .spec.in the upstream version number is probably auto-generated from configure.  Whenever the upstream version changes the release should be set back to 1.
+
+# Steps
+
+* Update the spec file, either resetting the release for a new upstream version or incrementing it.
+* Commit the spec file; make sure not to commit a .spec in a package with .spec.in
+* Push the submodule
+* Commit and push the master repository
+* Monitor the [build](http://www.project-moonshot.org/buildbot/builders/) until the Centos packaging succeeds
+
+# Installing packages in Archive
+
+At this point the packages have been copied to a file "~buildbot/rpm-packages.tar" on moonshot.suchdamage.org
+
+    ssh buildbot@moonshot.suchdamage.org
+    mkdir rpm-unpack
+    cd rpm-unpack
+    tar xvf ../rpm-packages.tar
+
+Confirm the packages look reasonable.  Copy only new packages into place.  It's quite important not to copy packages whose  version number did not change.
+
+    rsync --ignore-existing -v -a . /srv/rpms/centos6
+
+Sign the packages
+
+    cd /srv/rpms/centos6/RPMS/x86_64
+    rpmsign--addsign *rpm
+
+Now update repository metadata:
+
+    cd /srv/rpms
+    createrepo -u http://repository.project-moonshot.org/rpms/centos6 centos6
+
+
+At this point the Centos packages are available for installation.  Clearly more automation is desirable.
+

diff --git a/release/debian.mdwn b/release/debian.mdwn
new file mode 100644 (file)
index 0000000..d7d2b06
--- /dev/null
+++ b/release/debian.mdwn
@@ -0,0 +1,63 @@
+[[!meta title="Debian Packaging"]]
+
+Debian packages use the debian branch of the master repository.
+
+# Selecting the right branch
+
+In the master repository:
+
+    git checkout debian
+    git submodule update --init
+
+# Per package Instructions
+
+In each package you wish to update:
+
+## Select Debian Branch
+
+Change directories into the package and run:
+
+    git checkout debian
+
+## Updating Package with New Code
+
+Merge in the source code changes.  To merge in master:
+
+    git pull origin master
+
+Now run:
+    dch -i
+
+This brings up a changelog where you can describe the changes in this
+version.  Check the version number on the first line.  If the upstream
+has changed then update the version number to be
+upstream_version_number-1.  Otherwise if the upstream has not changed, then a new debian revision should have been created.
+Describe the changes in the space provided.  Make sure that the "distribution" on the first line is "unstable" not "UNRELEASED".
+
+    git add debian/changelog
+    git commit
+
+Push the debian branch:
+
+    git push origin debian
+
+## Update Master Repository
+
+"git add" each updated package to the bmaster repository and then commit.  Push the debian branch of the master repository.  This will trigger builds for 64-bit and 32-bit.  Check the status [here](http://www.project-moonshot.org/buildbot/builders/).  Once the builds succeed, the packages will be in the wheezy-proposed area of our archive.
+
+# Wheezy and Wheezy-proposed
+
+We maintain two areas of our Debian archive described by the following /etc/apt/sources.list lines:
+
+    deb http://repository.project-moonshot.org/debian-moonshot wheezy main 
+    deb http://repository.project-moonshot.org/debian-moonshot wheezy-proposed main
+
+The wheezy-proposed  archive should be used to grab the latest software, and the wheezy archive should be used for known good software.  When Live DVD images are produced, they install the software from wheezy-proposed.  However, the resulting image will only upgrade software from wheezy.  The intent is that you probably want to test the latest software when building a new DVD image, but until it is known to work, others may not want to upgrade to it.  To copy all software from wheezy-proposed to wheezy:
+
+    ssh buildbot@moonshot.suchdamage.org
+    cd /srv/debian
+    reprepro pull wheezy
+
+The "reprepro copy" command can be used to move individual packages.
+
+

diff --git a/release/master.mdwn b/release/master.mdwn
index 3450e52..4aa0d2d 100644 (file)
--- a/release/master.mdwn
+++ b/release/master.mdwn
@@ -18,7 +18,7 @@ Commit all the desired changes to the submodule.  Use the appropriate branch for
 
 # Update Upstream Version?
 
-Consider updating the upstream version number in configure.ac.  It's in the call to AC_INIT.
+Consider updating the upstream version number in configure.ac.  It's in the call to AC_INIT.  :If the upstream version is incremented then set the release back to 1 in the [[spec file|centos]].
 
 # Make sure to push