Debian OpenSSH source package handling ====================================== The Debian package of OpenSSH is maintained in Bazaar (http://bazaar-vcs.org/, or the 'bzr' package in Debian). You will need at least version 1.16.1; the version in Debian testing as of the time of writing (2009-12-21) is fine, or you can use the version in lenny-backports. URLs are as follows: Anonymous branch: http://bzr.debian.org/pkg-ssh/openssh/trunk Web browsing: http://bzr.debian.org/loggerhead/pkg-ssh/openssh/trunk Authenticated, for developers with commit access only: bzr+ssh://bzr.debian.org/bzr/pkg-ssh/openssh/trunk Although it's possible that I may use something like bzr-loom in the future to better manage things like the Kerberos/GSSAPI patch, right now there's no funny business and all that developers need to do is: # To check out: bzr co bzr+ssh://bzr.debian.org/bzr/pkg-ssh/openssh/trunk openssh # To update: bzr up # To edit: # hack hack hack, and 'bzr add' any new files debcommit # or bzr commit # note that this pushes automatically; you can use 'bzr unbind' to # temporarily prevent this, or 'bzr branch' to create a local branch which # you can merge later # To release: dch -r && debcommit -r If you have lots of branches, you'll probably want to use a shared repository to save space. Run 'bzr init-repo .' in an ancestor directory of all your OpenSSH working directories. For example, I have a shared repository in ~/src/debian/openssh/, upstream checkouts in ~/src/debian/openssh/upstream/, and my own working trees in ~/src/debian/openssh/trunk/. Merging new upstream releases ----------------------------- (Most developers will not need to read this section.) Thanks to the import from Portable OpenSSH CVS provided by Launchpad (https://code.launchpad.net/~vcs-imports/openssh/main, accessible by the shortcut 'lp:openssh' from the bzr client), the Debian branch is a true DVCS branch from upstream. This is a worthwhile property, but preserving it does take a little bit of work. Launchpad only imports CVS HEAD, but upstream sometimes produces releases from a branch. We use the same software used by Launchpad to import the branch as well, but a few small hacks are necessary to do good branch imports. In Bazaar, it's important that the same file in different branches should have the same file-id, otherwise merge attempts will try to delete and re-add the file which usually doesn't work out very well. Occasionally a file is added to CVS HEAD and then also added to a branch, and cscvs isn't quite smart enough to spot this and copy over the file-id. We need to help it out. To fetch the necessary code: bzr get lp:~cjwatson/launchpad-cscvs/openssh-branch-imports # or 'bzr pull' in the appropriate directory to update this, if you # already have a copy To import a branch, V_5_3 in this example: export PATH="/path/to/cscvs/openssh-branch-imports:$PATH" export PYTHONPATH=/path/to/cscvs/openssh-branch-imports/modules:/path/to/cscvs/openssh-branch-imports # in a CVS checkout of :ext:anoncvs@anoncvs.mindrot.org:/cvs module # openssh: cscvs cache -b # or 'cscvs cache -u' if you've done this before and want to update cvs up -rV_5_3 # Now we need to get a few bits of information from cscvs' cache. sqlite CVS/Catalog.sqlite sqlite> select csnum,log from changeset where branch = 'V_5_3' order by startdate; # There will be a solid block of "Creation of branch V_5_3" changesets at # the start; look for the first revision *after* this. Substitute this in # the following wherever you see "CSX". sqlite> select revision,filename from revision where branch = 'V_5_3' and csnum >= CSX and revision not like '%.%.%' order by filename; # Anything listed here will need to be added to the openssh_ids dictionary # in modules/CVS/StorageLayer.py in cscvs. Please send Colin Watson a # patch if you do this. # Next, look up the branchpoint revision in the main bzr import (bzr get # lp:openssh). It's usually easiest to just look it up by commit message # and double-check the timestamp. Substitute this revision number for # "BPR" in the following. /path/to/openssh/main is wherever you've checked # out lp:openssh. bzr get -rBPR /path/to/openssh/main /path/to/openssh/5.3 # If you're using Bazaar signed commits with a GPG agent, make sure that # your agent has seen your passphrase recently. Now you can start the # actual import! cscvs -D4 totla -SC V_5_3.CSX: /path/to/openssh/5.3 # If this fails at the end with a "directories differ" message, you may # have forgotten to switch your CVS checkout to the appropriate branch # with 'cvs up -r...' above. Otherwise you'll have to debug this for # yourself. It's also worth double-checking that any files added to the # branch have file-ids matching those on the trunk, using 'bzr ls -R # --show-ids'. Now we have a Bazaar branch corresponding to what's in CVS. Previous such branches are available from Launchpad, for reference purposes: https://code.launchpad.net/openssh However, upstream releases involve a 'make distprep' step as well to construct the tarball, and we need to import the results of this as well to get a clean package. Start by unpacking the upstream tarball (remember to check its GPG signature first!). Copy the .bzr directory from the upstream branch you prepared earlier. Now we have another branch, but with a working tree corresponding to the upstream tarball. Modifications and deletions are handled automatically, but we need to handle additions explicitly to make sure file-ids are correct (see above). Run: bzr add --file-ids-from=/path/to/openssh/debian/trunk bzr st --show-ids # compare this with 'bzr ls --show-ids' in the Debian trunk to make sure # the result will be mergeable bzr ci -m 'Import 5.3p1 tarball' You should now be able to 'bzr merge' from the tarball branch, resolve conflicts, and commit. If you see lots of "Contents conflict" messages, you may have got the file-ids wrong. Once you've committed the merge, you can throw away the tarball branch, as all its history will have been incorporated.