Building a new package the UDD way (was Re: First impressions (long))

Barry Warsaw barry at canonical.com
Thu Jan 14 22:43:20 GMT 2010


On Dec 11, 2009, at 05:12 PM, Barry Warsaw wrote:

>I think I've actually patched my first Ubuntu package, with much thanks to
>Colin and James W for their help.  Having done this from essentially no
>knowledge of how to do it, and no experience with the tools, James suggested I
>email this list with some feedback and suggestions.  Remember, I'm a n00b so
>be gentle because I have No Idea What I'm Talking About. :)

Well, now with a few more weeks under my belt, I decided to tackle packaging a
brand new Python package which is not yet in Debian or Ubuntu.  I still don't
know what I'm talking about, but I took notes, so here now is my feedback on
what I did.  I think there is no wiki page yet on the workflow for brand new
packaging the udd-way, but after getting some of your feedback I will add that
page.

(Side note: I've also now done a merge with sid to update the version of
Python's distribute package in Lucid.  That was a bit of a head-scratcher
until James and Micah pointed me to the wiki page on 'bzr merge-package' which
seemed to work perfectly, modulo the approval of my branch.)

The package in question is http://launchpad.net/munepy, a Python enumeration
package that I've refactored out of the Mailman 3 code base.  This package
only works with Python >= 2.6.  As the upstream maintainer of munepy, I'm
pretty confident of its current quality.

I decided to use bzr-pipeline to manage the changes.  In addition to the
bzr-builddeb tools, I found that python-stdeb was helpful, though not
perfectly so.  Actually, because of problems with the version of python-stdeb
in Lucid, I had to grab the Debian source package, then build and install it
locally.  We should resync this to sid I think.

Also, my goal was to get a PPA in Lucid munepy (and Karmic as a bonus but on
this I failed).  I next have to figure out how to propose the package for
inclusion in universe and possibly also in Debian, but those (I think) are
less important for this mailing list.

I started out pretty simply:

% bzr init-repo munepy
% cd munepy
% bzr branch lp:munepy munepy-2.0.1
% cd munepy
% bzr reconfigure
% bzr add-pipe debian

At this point, because I had essentially the source layout for munepy, and not
its tarball, I decided to use sdist_dsc to create the basic debian layout:

% python setup.py --command-packages=stdeb.command sdist_dsc

This command puts the new debian packaging content in a subdirectory called
'deb_dist'.  However, I want 'debian' to be in the current directory, so:

% mv deb_dist/munepy_2.0.1/debian .
% rm -rf deb_dist
% bzr add debian
% bzr commit -m'Add debian directory'

A couple of things: it would be nice if stdeb was able to write the 'debian'
directory to the current working directory.  Also, if I'm not mistaken, the
package resulting from stdeb will use python-central.  Should it use
python-support instead?  I'm still pretty unclear as to the differences, pros,
and cons.

But okay!  Now I have a debian directory with some basic stuff, but those
files do need some tweaking.  One thing that's missing is the debian/copyright
file.  munepy is LGPL v3, but I could not find a straightforward way to add
the proper debian/copyright file, short of doing a traditional unpacking of
the original tarball somewhere, pushd'ing to munepy-2.0.1 and doing:

% dh_make -c lgpl
% popd
% cp .../debian/copyright debian
% bzr commit -m'add copyright file'

I also had to hack debian/control to add/update the XS-Python-Version,
Homepage, and Description headers.  I sort of feel like with a little work,
stdeb could probably get this information out of the setup.py or the package
metadata files once the relevant PEPs are accepted.

At this point, I'd forgotten my previous hacking and so tried to use
dpkg-buildpackage to build my package, but this did not end well.  It didn't
respect my GPG keyid preferences and ultimately did not write a
munepy_2.0.1.orig.tar.gz or munepy_2.0.1-1.diff.gz.  I think remembered
debuild, which was happier about my GPG key, but still not completely
satisfying (my notes don't remind me why).

Ah yes, 'bzr builddeb'!  The interesting thing is that builddeb requires a
debian/watch file so that it can grab the tarball.  Well cool, I've uploaded
the tarball to the Cheeseshop, so I just pointed debian/watch to that url and:

% bzr add debian/watch
% bzr commit -m'added debian/watch'
% bzr bd -S

Now, here's an interesting question: where do I push my branch to?  I can't
obviously push it to lp:~barry/ubuntu/lucid/munepy/something and
lp:~barry/+junk/munepy-lucid doesn't seem right either.  Hmm...

% dput -f ppa:barry/python munepy_2.0.1-1_source.changes

Now, modulo a detour to get python-distribute 0.6.10 built in my PPA, this
actually built a suitable binary package.  Yay, that's a good place to stop...
for now.

So, while it took me several days to figure out, I did manage to build a
brand new package for Lucid.  I'm sure there are easier ways to do what I did,
and any feedback or advice you have would be great, and will help when I'm
updating the wiki.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20100114/c624484a/attachment-0001.pgp 


More information about the ubuntu-distributed-devel mailing list