Monthly Archives: June 2011

PPA management tools

We use PPA’s quite heavily in OpenStack. Each of the core projects have a trunk PPA and a milestone-proposed PPA. Every commit to our bzr trunk branch results in an upload to the trunk PPA, and every commit to our milestone-proposed bzr branch results in an upload to (you guessed it) the milestone-proposed PPA. Additionally, we have a common openstack-release PPA for each of our major releases, where we combine all the projects into one PPA, for simpler distribution.

This poses a number of challenges.

We support every Ubuntu release since Lucid, but most of them lack new enough versions of various stuff (and in some cases, the packages are missing altogether). This means we backport a bunch of things to the various trunk PPA’s, and at the right moments we need to copy all these dependencies either from the trunk PPA to the milestone-proposed PPA (when we branch off for a new milestone) or from the milestone-proposed PPA to the common release PPA (at final release time).

This used to involve a lot of mucking around with Launchpad’s web UI which is not only boring and tedious (checking half a bajillion boxes is even less fun than it sounds), but also error prone, since it’s all manual.

I decided to write a number of tools to help make this simpler. So far, these tools are:

  • copy-ppa-pkg.py

    Simply copies a package from one PPA to another.

  • detect_ppa_mismatches.py

    This one takes a number of PPA’s as arguments, and finds packages that exist in more than one of them, but at different versions. During the development cycle, this is not much of a problem since most people only run the trunk version of a single project, but when we shove them all together in one great, big PPA, it could mean that one of the projects suddenly is being run against another version of one of its dependencies than during the dev cycle.

  • sync-ppas.py

    This one takes all the packages from one PPA and copies them to another and removes stuff from the destination PPA that’s been removed from the source PPA. It’s handy if have a PPA with all your stuff in it, it’s all been QA’ed together and is in good shape, and you want to sync it all over into a “stable” PPA in one fell swoop.

  • list-ppa.py

    Lists the contents of a PPA. Simple as that.

I’ve branched lp:ubuntu-archive-tools and added these tools to lp:~openstack-release/ubuntu-archive-tools/openstack. I can’t really decide if I think they belong inlp:ubuntu-archive-tools, but if someone else wants them I can look into getting them merged back.

New GPG key – Please help :)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

(Thanks to Colin Watson for the template for this post)

I've finally gotten around to setting up a new, strong (4096 bit) RSA-
based GPG-key, and will be transitioning away from my old 1024 bit DSA
key. The old key will continue to be valid for some time, but I prefer
all future correspondence to use the new one. I would also like to
ensure that this new key is well-integrated into the web of trust. This
message is signed by both keys to certify the transition.

The old DSA key was:

pub   1024D/E8BDA4E3 2002-02-22
      Key fingerprint = 196A 89ED 78F3 9047 2A36  F327 A278 DF5E E8BD A4E3

The new RSA key is:

pub   4096R/9EAAF9C5 2011-06-15
      Key fingerprint = E6BC C692 3553 A464 8514  28D1 EE67 E7D3 9EAA F9C5

To fetch my new key from a public key server, you can run:

  gpg --keyserver subkeys.pgp.net --recv-keys 9EAAF9C5

If you already know my old key, you can now verify that the new key is
signed by the old one:

  gpg --check-sigs 9EAAF9C5

If you don't already know my old key, or if you're extra-paranoid, you
can check the fingerprint against the one given above:

  gpg --fingerprint 9EAAF9C5

If you have previously signed my old DSA key, and if you're satisfied
that you've got the correct new RSA key, then I'd appreciate it if you
would sign my new key as well:

  caff 9EAAF9C5

The caff program is in the signing-party package in Debian and its
derivatives, including Ubuntu. Please be careful to generate signatures
that don't rely on the weakening SHA-1 hash algorithm, which requires
some careful configuration even if you've already configured gpg
correctly. See http://www.gag.com/bdale/blog/posts/Strong_Keys.html for
the gory details.

Thanks,
Soren Hansen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJN+KNRAAoJEO5n59OeqvnFibwP/jLC+VXFBxMbxqxcXTolr19H
5octVasjlO7Ub9oqH/7/Js168g5gnzSefraWTd0kELc3fXVVsvZuNUtfBhrSYMX5
EQnRr+P1HGi5apFECc3hd7dNQIfbypkQ4UAK3T2nYgkYLATnt04CX0LUz/wnvHJD
fnNRHcM0A8pTn9oJB6LgXpJUspz3pqTFyEoQTkY0/QPcfLbeTLqYG+slSp8+I35H
I+PXl4XrbSsbcJTjpRRllodb1d5sFYZr827ZqPksEeiozGfwpXLZ/DtaIrtE3z3T
AVPCeG/9VCFtcvgqPQnhcbsS6RrGVkE5fUFxgZzERlAxAkkPi+WhwinASmkvOtmE
0m6fkhEeMCYvqvrDoeR8mZvgODIZjP7aIvNKDpWBA9mxC7k171LHdnsluB3xN0sH
++8/w5ESy7GpFxveLk6jR5ytfTxVLUgAASoqJbsxpMqSz/5KNompdFy/Hu13PVel
afqQNfMLjV0QXrKvtmmPSbUs6bWhxwE04jsYAUQcFNBFyHMmYQdA5peikC8ad+JL
WJocQmRUeE6EVRKKSaBXJIihcRHigeTf+6qqaSdbTpeZ1iPSMyETmOW8ZzBaQ7F0
VO65BOOzFsD7Cuaxba427CFPvYo5F4Bi3Dtuwz1PtZlNKExFRuNZ4vhs6dRFenJT
kkeIQrFpJ6wF/DVrutMeiEYEAREKAAYFAk34o1EACgkQonjfXui9pOOVyACfeLci
yfBLmY3L9Abcmg6ggCVQLBAAoKDQfzhmoK5mk26dQToReFpJ80bq
=0yN5
-----END PGP SIGNATURE-----