Ubuntu Wiki

Update

A tutorial has now been created from this log. Check it out here .

Ubuntu Open Week - Python Packaging - Emilio Pozuelo Monfort - Thu, May 1, 2008

=== jcastro changed the topic of #ubuntu-classroom to: Ubuntu Open Week | Information and Logs: https://wiki.ubuntu.com/UbuntuOpenWeek | How to ask questions: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules | Ask questions in #ubuntu-classroom-chat, prefaced with "QUESTION:" |See https://wiki.ubuntu.com/UbuntuOpenWeek/JoiningIn to filter out channel noise | "Python Packaging" - Emilio Pozuelo Monfort

[21:58] <jcastro> next up is Python packaging

[21:59] <pochu> thanks jcastro

[21:59] <jcastro> This is a new subject this time around, due to popular demand, so keep the ideas coming!

[21:59] <pochu> So who is here for the session? :)

[21:59] <pochu> jcastro: could you please -m the channel?

[22:00] <sebner> pochu: me :)

=== asac_ is now known as asac

[22:00] <albert23> +1

[22:00] <rulus> _o/

[22:00]  * wolfger is here to learn python packaging

[22:00] <morten> +1

[22:00] <toobuntu> +1

[22:00] <marto> +1

[22:00] <pochu> This is my first session, so please forgive me if I go too fast or whatever, and just tell me

[22:00] <progfou> _o/

[22:00] <pochu> In this session we will learn how to package a Python application

[22:00] <pochu> so let's get started

[22:00] <barcc_> +1

[22:01] <pochu> first let's do the preliminary work

[22:01] <pochu> we will need some packages, let's install it

[22:01] <pochu> $ sudo aptitude install wget dh-make devscripts

[22:01] <avu> +1

[22:01] <Az32> +1

[22:01] <pochu> and let's prepare our working area

[22:01] <pochu> $ mkdir ~/python-packaging && cd ~/python-packaging

[22:01] <phoenix24> +1

[22:01] <pochu> please tell me once you are done

[22:02] <toobuntu> n

[22:02] <toobuntu> (oops)

[22:02] <pochu> hmm, there seems to be some people joining, let's wait a couple of minutes

[22:02] <Az32> done

[22:02] <wolfger> done

[22:02] <rulus> done :)

[22:02] <albert23> done

[22:03] <toobuntu> ok

[22:03] <pochu> nice :)

[22:03] <pochu> we're going to package terminator, which is a terminal emulator that can split several terminals in 
the same window

[22:03] <pochu> https://launchpad.net/terminator

[22:03] <barcc_> done

[22:03] <pochu> first, let's download the source package

[22:03] <pochu> $ wget http://launchpad.net/terminator/trunk/0.8.1/+download/terminator_0.8.1.tar.gz

[22:03] <pochu> and let's rename it properly

[22:03] <pochu> $ mv terminator_0.8.1.tar.gz terminator_0.8.1.orig.tar.gz

[22:03] <pochu> this is because Debian packages have this structure <name>_<version>.orig.tar.gz

[22:04] <toobuntu> ls

[22:04] <pochu> let's unpack the tarball to work on it

[22:04] <pochu> $ tar -xf terminator_0.8.1.orig.tar.gz

[22:04] <Az32> ok

[22:04] <grantgm> would it be possible to wait for a second. My install is still ongoing ... damn slow internet

[22:04] <Az32> ;)

[22:04] <sebner> pochu: just for you private use. check out "unp" ;)

[22:04] <pochu> grantgm: sure :)

[22:05] <pochu> while we wait, if you have any questions, feel free to ask at any moment

[22:05] <pochu> and feel free to interrupt if you get stuck

[22:05] <Az32> Are there any plans on bundling a full-featured "visual" Python IDE with Ubuntu?

[22:06] <nosrednaekim> can this channel be modded +m and have people chat in -chat?

[22:06] <avu> pochu, will what we learn here be generally aplicable to all python packages distributed using 
distutils?

[22:06] <pochu> nosrednaekim: I prefer this way

[22:06] <nosrednaekim> it makes it nicer for the logs...

[22:06] <pochu> Az32: there's spe in the repositories, try it ;)

[22:06] <Az32> Thanks!

[22:06] <Az32> What about bundling by default?

[22:06] <pochu> Az32: and if you have questions, stani is the upstream author

[22:07] <grantgm> sorry to keep everyone waiting. Its done now.

[22:07] <pochu> I don't think it makes sense to put an IDE in the default installation... very few people will use it

[22:07] <progfou> I second nosrednaekim... please moderate this channel

[22:07] <pochu> avu: I hope so. we will only package one, but I will try to explain everything so you can package 
anything later

[22:07] <avu> pochu, ok, thanks

[22:08] <Az32> pochu: At least I would use it... ;)

[22:08] <pochu> jcastro: hmm, could you moderate this again, so that it's easier to make logs later?

[22:09] <pochu> ok, please ask your questions in #ubuntu-classroom-chat

[22:09] <pochu> so let's continue

[22:09] <pochu> $ cd terminator-0.8.1/

[22:09] <pochu> OK, we have the upstream sources ready, let's start the packaging :)

[22:10] <pochu> we are going to use dh_make, which will create a template from which we will work on

[22:10] <pochu> $ dh_make -c gpl -s -b

[22:10] <pochu> which means: '-c gpl' tells it that the package is licensed under the GPL license

[22:10] <pochu> -s tells it that we just want one binary package. one source package can be splitted in many binary 
package. This is very useful when a package has huge documentation (so you build a -doc package too), or many images 
(so you build a -common package), or it's a library. We just need one, which will contain everything

[22:10] <pochu> -b tells it to use CDBS, 'Common Debian Build System', which will make our packaging simple, so we can 
concentrate on the Python specific things.

[22:12] <pochu> let's get into the packaging folder, debian/

[22:12] <pochu> $ cd debian/

[22:12] <pochu> $ ls

[22:12] <pochu> Ok, there we have the template files. There's many files we don't need (all the *.ex ones), so let's 
get rid of them

[22:12] <pochu> $ rm *ex *EX

[22:12] <pochu> everyone keeping up? +1 in #ubuntu-classroom-chat please :)

[22:14] <pochu> alright, let's continue

[22:14] <pochu> Ok, now let's start filling the template. first we will edit the control file, so open it in your 
preferred editor.

[22:16] <pochu> oly> QUESTION: what are .ex files i have not come accoss them before are they todo with packaging ?

[22:16] <pochu> oly: dh_make will put example files for a lot of things. we may need some. They are for init scripts, 
manpages, Debian menu files, watch files...

[22:17] <pochu> we could have used menu.ex and watch.ex, but we want to keep this as Python-oriented as possible

[22:17] <pochu> Ok, now let's start filling the template. first we will edit the control file, so open it in your 
preferred editor.

[22:18] <pochu> As you can see, the file is separated in two sections. The first one is always the source package 
info, and the others (in our case it's just one) are the binary packages.

[22:18] <pochu> For the source package, we need to change the Section (misc is a good one, the list is here: 
http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections), the Priority should be optional (it's extra 
for -dev, -dbg packages, and maybe a few others), and the Standards-Version should be 3.7.3 which is the newest one.

[22:19] <pochu> If you package a Python module, section should be 'python', but not for applications

[22:20] <pochu> Regarding the binary package, we need to put a short and long description

[22:20] <pochu> Use your imagination to make one ;)

[22:21] <pochu> And this is important for Python packages, the Architecture should be 'all', as our code is 
architecture-independent, so we don't need to compile it for every architecture (i386, amd64, powerpc, sparc...). This 
is true always for Python code, but it's different when we are packaging Python bindings written in C for example.

[22:21] <stani> FrankNiessink: QUESTION: so the first line is the short description and the next lines are the long 
description?

[22:21] <pochu> FrankNiessink: right

[22:21] <stani> progfou: QUESTION: shouldn't we keep the Standards-Version: field as generated by dh_make since 
everything else also generated is compliant to this specific version?

[22:22] <pochu> FrankNiessink: for the long description, every line should start with an space, and if you want to put 
a white line, it should be an space and a dot, " ."

[22:23] <pochu> progfou: that's a good point. However, there weren't big changes between 3.7.2 and 3.7.3 that would 
make our package incompatibly with 3.7.3, so we are fine

[22:23] <stani> nosrednaekim: QUESTIONare the right and left arrows kept when writing the description?

[22:23] <pochu> but when we update Standards-Version, we should *always* check that we are still compliant to the new 
Policy

[22:24] <pochu> nosrednaekim: no, they aren't

[22:24] <pochu> for example, it could look like this:

[22:24] <pochu> Description: Simple and nice music player for the GNOME desktop Decibel is a GTK+ audio player which 
aims at being very straightforward to use by mean of a very clean and user friendly interface.

[22:25]  * stani wants pochu to say next when ready answering

[22:25] <pochu> stani: next :)

[22:25] <stani> rulus: QUESTION: When creating multiple binary packages from one source package (f. ex. Python module 
+ GTK program), what should the section of the source package be?

[22:26] <pochu> rulus: hmm, I'm not really sure TBH, but I think it should be that one which describes better the 
package

[22:27] <pochu> e.g. if it's mostly an application which ships a public module which *might* be useful to someone 
else, then put one for the application

[22:27] <pochu> but if it's a module with a small interface or something, put 'python'

[22:27] <pochu> probably looking at the upstream package name will help you

[22:28] <pochu> next

[22:28] <stani> sebner: QUESTION: Python applications are all but if we package something made with C or something 
similar the only way is to *test*? how?

[22:28] <pochu> sebner: do you mean e.g. Python bindings written in C?

[22:29] <stani> pochu: yes, or just a pure C programm. Sry if it doesn't fit here correctly

[22:30] <pochu> ok, you should test it as you would test any other package

[22:30] <pochu> if it's a module or bindings, use them (probably the upstream source contains some examples or 
regression tests)

[22:30] <pochu> if it's an application, use it as much as possible

[22:31] <pochu> don't simply open it and look at the menus, but look at the functionality and check that everything 
works as expected

[22:31] <pochu> next

[22:31] <stani> morten: QUESTION: What are the primary differences between pycentral and python-support, and which 
should we use, and when?

[22:32] <pochu> morten: both do the same work, and both work very similar as far as I know, so use the one you like 
more ;)

[22:32] <pochu> or try both and pick up one

[22:32] <pochu> I'll let you guys decide which one to use in the future, although for this session we will use 
python-central

[22:32] <pochu> next

[22:32] <stani> QUESTION: sometimes, does it worth to build native (arch dependant) python program ? can you tell when 
and why  ?

[22:33] <pochu> native packages should be only used when the package is specific to Debian/Ubuntu

[22:33] <pochu> e.g. lintian is a good example, or dpkg

[22:34] <pochu> so unless you are developing (and not packaging in this case) something like that, use a non-native 
package

[22:34] <pochu> next

[22:34] <stani> Kopfgeldjaeger: QUESTION: Do you need a setup.py file to package python applications or is there 
another way to do it?

[22:34] <pochu> Kopfgeldjaeger: not really, although it's easy to create a setup.py script, but you could package 
Python applications which use autotools or anything else

[22:35] <pochu> I maintain a couple of Python apps which use autotools one and  just a Makefile the other

[22:35] <pochu> next

[22:35] <stani> I propose to continue with your tutorial

[22:35] <pochu> alright :)

[22:36] <pochu> Now let's get to the Python specific bits. This is the important part of this session, as everything 
covered before would be general packaging tasks.

[22:36] <pochu> So let's look at the Build-Depends and Depends. The Build-Depends are the packages we need to build 
our package, and the Depends are the packages we need to run it.

[22:36] <pochu> Let's look first at the Depends. We need to add here all the modules our application uses:

[22:37] <pochu> $ grep -B 3 -A 3 import ../terminator

[22:37] <pochu> There we have our list of imported modules. Some of them are standard to Python, but others aren't. 
let's list them all. Also, most of them are required, but if you look at 'import gnome', if it's not installed it will 
just import the webbrowser module, which is a standard Python module.

[22:38] <pochu> with 'standard to Python' I mean that they are shipped with Python itself, so depending on Python will 
be enough to cover them

[22:38] <pochu> but there are modules which aren't shipped with Python, so we will need to depend on them so that our 
package can actually work

[22:39] <pochu> So we have gobject, which is in python-gobject, gtk and pango which are in python-gtk2, gconf which is 
in python-gconf, and vte which is in python-vte.

[22:40] <pochu> to find this you may need to do some research, although 'apt-cache search module | grep python' may 
help

[22:40] <pochu> For gnome, we will just recommend it (and not depend on it) as it's not required, because we have 
webbrowser as fallback.

[22:40] <pochu> So let's add 'python-gobject, python-gtk2, python-gconf, python-vte' to Depends. We can also remove 
${shlibs:Depends} which isn't useful for pure Python packages.

[22:41] <pochu> And let's add 'Suggests: python-gnome2' after the Depends field. I've chosen Suggests and not 
Recommends because now Recommends are installed by default, and GNOME users probably have it installed, and we don't want to install it for KDE users (the less, the better for them). But feel free to disagree and use Recommends if you want :)

[22:42] <pochu> please, tell me if you get stuck

[22:42] <pochu> Now we will have a look at the Python Policy, http://wiki.debian.org/DebianPython/NewPolicy, which 
explains what we need to do to our package.

[22:42] <pochu> please everybody open that link :)

[22:44] <stani> pochu: eveybody is following ;-)

[22:44] <pochu> cool

[22:45] <pochu> If you look at the 'Updating your packages' section, you will see it explains what to do for each case 
(python application, python module, package with extensions...). We are packaging an application, so let's look what 
it says about them.

[22:45] <pochu> The first point, although it doesn't say it, is for modules. Some time ago modules had a binary 
package for each Python version (e.g. python2.4-module, python2.3-module...). But fortunately that's not the case 
anymore, and we are packaging a Python application anyway so we don't care ;)

[22:46] <pochu> The second point affects us. We need to add a ${python:Depends} to the Depends field. That will add 
the correct Python dependency to our binary package.

[22:47] <pochu> The third point also affects us. We have to add a "XB-Python-Version: ${python:Versions}" field in the 
binary stanza (where Depends and Architecture are). It doesn't matter where you put it. You can put it between 
Architecture and Depends, for example. Note that if we had more than one binary package, we would need to put it for 
each one of them.

[22:48] <pochu> That's used by pycentral/pysupport, and it will get it's value from 'XS-Python-Version', but we will 
see that later

[22:48] <pochu> morten> QUESTION: Shouldnt we use debian/pyversions now?

[22:49] <pochu> morten: that's used by python-support only, not by python-central, and I think it's deprecated (or at 
least it's not required if you have XS-Python-Version)

[22:49] <pochu> morten: so we won't use it

[22:49] <sebner> pochu: stani seems to be away. you gave me voice. Should I copy the questions?

[22:50] <stani> I am still here

[22:50] <sebner> ah ok ^^

[22:50] <pochu> morten: in the wiki page, in the python-support section, it says: "Note: if there's no 
debian/pyversions, dh_pysupport will try to use the XS-Python-Version field to find out the list of supported 
versions. "

[22:50] <pochu> The fourth point doesn't affect us, as we don't ship extensions.

[22:51] <pochu> The fifth point wouldn't affect us if we weren't using CDBS, but as we want to make the packaging 
simple, we will need to pick either python-central or python-support (doesn't matter which one, both do their job). 
This is good because if we were shipping a module, either public or private (and many applications are modularized), 
we would need to use one of these tools, so now we will learn about them so when you need to use them you know how t

[22:51] <stani> morten: /usr/share/cdbs/1/class/python-distutils.mk:60: WARNING:  Use of XS-Python-Version and 
XB-Python-Version fields in debian/control is deprecated with pysupport method; use debian/pyversions if you need to 
specify specific versions.

[22:51] <stani> morten: (but you are using pycentral, so i guess its ok)

[22:51] <pochu> Let's go with python-central. If you want to use python-support in your package, you will find that 
the steps are almost the same, and they are well documented in the policy.

[22:52] <pochu> morten: that's just a warning, not an error ;) but anyway we are going to use pycentral in this 
session, and not pysupport

[22:53] <stani> progfou: QUESTION: is there specific things to do for a package only working with one version of 
Python (eg 2.5 and not before)? and the same question for a package not Python version dependant

[22:54] <pochu> BTW, the session will last some more time, FYI

[22:54] <jcastro> there's nothing scheduled after, so take all the time you need!

[22:54] <pochu> progfou: yes, we will see that when I explain how to use XS-Python-Version

[22:54] <pochu> jcastro: thanks :)

[22:55] <pochu> So from steps first and second from 'Using python-central', let's Build-Depend on "debhelper (>= 
5.0.38), python-central (>= 0.5.6)", substituting "debhelper (>= 5)" which is minor than 5.0.38.

[22:55] <pochu> The third step doesn't apply to us as we will use CDBS and that's for debhelper. But we will see that 
later.

[22:56] <pochu> As per the fourth step, we need to add XS-Python-Version to the source stanza of debian/control. The 
'current' keyword is deprecated (the Policy needs to be updated), so we can use either 'all' if our package supports 
all Python versions, or >= X.Y. the README or ChangeLog doesn't mention which Python versions are supported, but it 
works at least with Python 2.4 so let's put >= 2.4 on it, "XS-Python-Version: >= 2.4". Remeber to put that in the

[22:56] <pochu> progfou: ^-- does that answer your question?

[22:57] <stani> ebner: Question. Shouldn't we use pycentral >= 0.6 since there are fixes in it IIRC. (just did some 
bugfixing, transition)..

[22:58] <stani> progfou: pochu: yes it answers my Python version question, but... I'll wait for next step to see... :)

[22:59] <pochu> sebner: yes, >= 0.6.0 makes more sense as it changed the path were the modules are stored. However our 
package doesn't ship any modules so we are safe

[23:00] <pochu> But if you package public modules, you should build depend on python-central >= 0.6.0 (the policy 
needs to be updated)

[23:00] <pochu> but it works at least with Python 2.4 so let's put  >= 2.4 on it, "XS-Python-Version: >= 2.4". Remeber 
to put that in the source stanza, for example just below Standards-Version.

[23:01] <pochu> sorry, that got truncated

[23:01] <pochu> And the fifth point obviously doesn't affect us, as we don't ship any modules.

[23:01] <pochu> 9,10,11,12,13,14,15,16,17,18,19,20,22                                                                                                       
<

[23:01] <pochu> simmons.freenode.net/#ubuntu-classro:

[23:01] <pochu> ooops

[23:02] <pochu> So we have this in place now, let's go to the CDBS magic, in the "CDBS + distutils" section. For this 
to work, our package needs to use distutils (the setup.py script usually). It's a system to distribute Python 
applications and modules: http://docs.python.org/dist/dist.html, but we don't need to worry about that now as our 
package uses it.

[23:02] <stani> pochu: but it also doesn't matter if I *only* use >= 0.6 for all things?

[23:02] <pochu> no, that's fine. although that will make backporting harder

[23:03] <pochu> So the first point tells us to Build-Depend on cdbs (>= 0.4.49) in the control file, let's do it.

[23:03] <pochu> please, let me know if you are keeping up fine

[23:05] <sebner> pochu: please continue :)

[23:05] <pochu> The second point tells us to set the DEB_PYTHON_SYSTEM environment variable in the rules makefile. As 
we have chosen python-central, that would look like "DEB_PYTHON_SYSTEM=pycentral" before the includes.

[23:06] <pochu> And finally let's add the distutils magic, removing the makefile one (as the package doesn't have a 
Makefile but a distutils script). So let's change "include /usr/share/cdbs/1/class/makefile.mk" with "include 
/usr/share/cdbs/1/class/python-distutils.mk"

[23:06] <pochu> We should be done now :-)

[23:07] <pochu> Let's finish with the other files. As we don't need to document anything in README.Debian, let's 
remove it. We don't need the dirs file, as distutils and python-central will take care of making the necessary 
directories.

[23:07] <pochu> $ rm README.Debian dirs
[23:07] <pochu> And finally, let's edit debian/changelog. The 'dch' script from devscripts is really useful for this.

[23:08] <pochu> but for this we will need to have a couple of environment variables in place

[23:08] <pochu> so please, add something like this to your ~/.bashrc

[23:08] <pochu> export DEBFULLNAME="Emilio Pozuelo Monfort"

[23:08] <pochu> export DEBEMAIL="pochu@ubuntu.com"

[23:08] <stani> rulus: QUESTION: What about "DEB_COMPRESS_EXCLUDE := .py" in the rules file? Is it (still) necessary?

[23:10] <pochu> rulus: I don't think it is, at least I don't use that for any of my packages. But I'm not really sure

[23:10] <pochu> rulus: for this package it isn't needed though, as there's no .py file

[23:11] <pochu> ok, now run this so that the terminal knows about those variables we have set

[23:11] <pochu> $ source ~/.bashrc

[23:11] <pochu> and let's edit the changelog:

[23:11] <pochu> $ dch -e

[23:11] <pochu> And let's put a bugnumber there in Closes (we don't have one, so let's invent it).

[23:11] <pochu> Also, we should change unstable with intrepid and '0.8.1-1' with '0.8.1-0ubuntu1' if we are packaging 
this for Ubuntu (although if you package it for Debian, then it will hit both Debian and Ubuntu, and probably other 
Debian derivatives)

[23:12] <pochu> also if it's for Ubuntu, the bug should be a Launchpad bug and we should change 'Closes' with 'LP'

[23:12] <pochu> We have almost finished this! We only need to put the right info in debian/copyright, but let's skip 
that here. That's very important though. Without a perfect debian/copyright file listing all the necessary info, the 
package will be rejected.

[23:14] <pochu> to write good debian/copyright files, this two mails from a couple of Debian Developers are very 
useful: http://lists.debian.org/debian-devel-announce/2003/12/msg00007.html, 
http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

[23:14] <pochu> So let's now build the package and install it!

[23:14] <pochu> please, make sure you have the dpkg-dev package installed, I forgot about it in the beginning

[23:14] <pochu> $ sudo aptitude install dpkg-dev

[23:15] <pochu> $ cd ..

[23:16] <pochu> $ dpkg-buildpackage -us -uc

[23:16] <pochu> That will build the source and binary package. The '-us -uc' options are not to sign the source and 
changes files (we would need to sign them to upload them to Ubuntu/Debian/your PPA, but if you have rights to do that, 
you probably know how to sign them ;)

[23:16] <pochu> If you are interested in PPAs, there was a session about it this Tuesday, logs are available at 
https://wiki.ubuntu.com/MeetingLogs/openweekhardy/LaunchpadPPAs

[23:17] <pochu> If everything has gone fine, that command will end with this:

[23:17] <pochu>     dpkg-genchanges: including full source code in upload

[23:17] <pochu>     dpkg-buildpackage: full upload (original source is included)

[23:17] <pochu> Is that the case? :)

[23:17] <stani> FrankNiessink: QUESTION: I get: dpkg-checkbuilddeps: Unmet build dependencies: cdbs (>= 0.4.49)

[23:18]  * stani wants again a next blessing after an answer ;-)

[23:18] <pochu> FrankNiessink: ah, right

[23:19] <pochu> we need to install the Build-Dependencies! so let's run:

[23:19] <pochu> $ sudo aptitude install cdbs debhelper python-central

[23:20] <pochu> after that, build the package again:

[23:20] <pochu> $ dpkg-buildpackage -us -uc

[23:20] <pochu> (if it failed in the first run)

[23:21] <stani> sebner: python 2.4 not found

[23:22] <stani> gruber: QUESTION: I get: /bin/sh: python2.4: not found

[23:24] <stani> pochu: ping

[23:24] <pochu> sebner, gruber: ok, please change XS-Python-Version, '>= 2.4' to 'all'

[23:24] <pochu> and try again

[23:25] <sebner> pochu: invalid setting

[23:25] <stani> hhlp: QUESTIONS : can you put in pastebin an example of controlfile of this example to compare with 
mine (in the meantime)

[23:25] <sebner> pochu: ah no. same error

[23:25] <pochu> hhlp: sure, http://pastebin.com/f60fedee1

[23:26] <stani> (progfou: yep, to make it easier I've changed XS-Python-Version to 2.5 and it works 'til the end)

[23:26] <pochu> gruber, sebner: ok, so then we need to use 'current'

[23:26] <sebner> pochu: yeah. I saw your posted control file ^^

[23:26] <pochu> That was my fault, I thought 'current' was already deprecated in python-central but it's not yet...

[23:27] <pochu> So to everybody: if we use '>= X.Y', or 'all' it will build the package for every python version. 
However, this is an application and that's not useful (that good for modules though) so for an application, 'current' 
will build it only with the default python version

[23:28] <pochu> I guess 'current' will be deprecated in the future, but it's not right now so we can use it

[23:28] <stani> ok, continue

[23:28] <pochu> lup> could you paste the rules file too?

[23:28] <pochu> lup: http://pastebin.com/f4e6dc243

[23:29] <pochu> ok

[23:29] <pochu> Ok, let's install the package now. the 'debi' command (from the devscripts package too) will install 
it if we have just built it from the package directory, so we are fine:

[23:29] <pochu> $ sudo debi

[23:29] <pochu> The last line should be this one:

[23:29] <pochu>     Setting up terminator (0.8.1-1) ...

[23:30] <pochu> So we got it!!

[23:30] <pochu> Now you can start terminator with the following command:

[23:30] <pochu> $ terminator

[23:30] <pochu> And there is a terminator menu entry in the Accesories menu (that's in GNOME, I don't know where will 
it show in other desktops).

[23:30] <pochu> So we are done :-)

[23:30] <pochu> Questions?

[23:30] <stani> lup: Got a different error:  /usr/share/cdbs/1/class/python-distutils.mk:69: *** unsupported Python 
system: pycentral   (select either pysupport or pycentral).  Stop.

[23:32] <pochu> lup: what Ubuntu version are you running? (this could be due to old packages, I didn't tested the 
session in Dapper)

[23:32] <pochu> lup> It was white space after the pycentral, the quotes didn't help

[23:32] <pochu> alright :)

[23:33] <stani> sebner: Question. Is it in generel better to use cdbs for python things? It may contain black magic

[23:34]  * stani starts with other questions now

[23:34] <pochu> sebner: not really. Any system is fine. I chose CDBS as that way it would be easier for starters to 
follow the session and concentrate on the Python bits, but using debhelper is equally fine

[23:34] <pochu> next

[23:35] <stani> rulus: QUESTION: How do I combine 'multiple binary' with 'cdbs' in dh_make? It seems the one or the 
other.

[23:36] <pochu> rulus: I have to admit I have no idea, I have never used that, and indeed it doesn't seem to work

[23:37] <stani> sebner: Question: Why have we a menu entry? We didn't created a menu file or is this black magic by 
cdbs?

[23:37] <pochu> rulus: file a bug report about it ;)

[23:38] <pochu> sebner: good question. Indeed we removed the menu file, but the upstream package contains a .desktop 
file, and the setup.py script installs it properly in /usr/share/applications/

[23:38] <pochu> that's nice, isn't it?

[23:38] <pochu> next

[23:38] <stani> progfou: QUESTION: how should I deal with real Python version specific files like new encodings having 
to be put in /usr/lib/python2.5/encodings/ ? should I put them at the right place by hand (using "install -c ...") or 
is there some more automatic way not requiring to know the exact location?

[23:39] <pochu> progfou: pycentral/pysupport will take care of that

[23:40] <pochu> progfou: e.g. with pycentral it will install the files into /usr/share/pyshared/, and it will 
byte-compile them into every python version

[23:40] <pochu> progfou: so you don't need to do that by hand, luckily

[23:40] <pochu> next

[23:40] <stani> oly: QUESTION: how does packaging from scratch differ, i mean if i have no tar.gz file do i just tar 
up my existing project and work from there does the layout of the source files matter in anyway ??

[23:41] <pochu> oly: ok, we assume here you are upstream for that project. So yes, you need to make a tarball (a 
public release for example, mypackage-0.1), so you can then package it

[23:42] <pochu> the layout matters a bit, so if you will use distutils, the distutils documentation explains where to 
put everything

[23:42] <pochu> next

[23:43] <stani> lup: QUESTION: what do I need to remove to rebuild the package again?

[23:44] <pochu> lup: good question. We need to remove build/, so you can put that in debian/rules in the clean target

[23:44] <pochu> e.g.

[23:44] <pochu> terminator/clean::

[23:44] <pochu>         rm -rf build/

[23:44] <pochu> that would fix it

[23:45] <pochu> it's important that a package can build twice in a row now, but i didn't want to enter into that so we 
could concentrate in the python specifics

[23:45] <pochu> next

[23:45] <stani> grantgm: QUESTION: why does 'dpkg-buildpackage -us -uc' need to run as root?

[23:45] <stani> grantgm: so I still haven't been able to build successfully: make: *** [testroot] Error 1

[23:46] <pochu> grantgm: ah, I guess you aren't running Hardy ;-)

[23:46] <pochu> grantgm: or you may be, but you don't have installed fakeroot

[23:46] <pochu> grantgm: you don't need to, you can use fakeroot to do it

[23:47] <pochu> grantgm: in fact, you should never build a package as root in your production system

[23:47] <pochu> grantgm: so install the fakeroot package, and build it again (use dpkg-buildpackage -us -uc -rfakeroot 
if you don't have Hardy or later)

[23:47] <stani> grantgm: 7.10 on this machine

[23:47] <pochu> I see, that should work for you then

[23:47] <pochu> next

[23:48] <stani> tzeentch__: QUESTION: How does using different build tool change things, e.g. if a package used scons, 
setuptools or whatever, would cdbs and all other magic still work?

[23:48] <stani> grantgm: stani: same problem (with fakeroot on 7.10)

[23:48] <pochu> grantgm: did you try '-rfakeroot' ?

[23:49] <pochu> tzeentch__: not exactly. The distutils magic won't work anymore

[23:49] <pochu> tzeentch__: but the pycentral/pysupport magic should work as long as the build system does the Right 
Thing

[23:50] <pochu> I have never packaged anything using scons or setuptools, but I maintain a Python package which uses 
autotools. I use debhelper for it though, but I guess I could switch it to CDBS without problems

[23:50] <pochu> next

[23:51] <stani> I guess no more questions

[23:51] <stani> but maybe you can give a short word about PAPT

[23:52] <pochu> yes

[23:53] <pochu> so PAPT, or Python Applications Packaging Team, is a Debian team which has many Python applications. 
There's also many Ubuntu developers and contributors packaging their applications there, as then they will hit both 
Debian and Ubuntu

[23:53] <pochu> I maintain all my Python applications there, and I have never had any problem in getting them into 
Ubuntu

[23:53] <sebner> pochu: because they get autosynced ^^

[23:54] <pochu> yes :)

[23:55] <pochu> http://wiki.debian.org/Teams/PythonAppsPackagingTeam and 
https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam have more info

[23:56] <pochu> Alright, thank you all for coming to the session! I hope you have learnt something with it, and I'll 
be more than happy to help you if you get in troubles with Python packaging or need sponsorship :-)

[23:56] <pochu> Thanks stani for pasting the questions too

[23:57] <sebner> pochu: yeah. 2 hours ^^

[23:58] <pochu> also, there's #ubuntu-motu here on Freenode and #debian-python on OFTC where you can ask for help with 
packaging (the latter only for Python packaging obviously :)

[00:00] <stani> nealmcb: QUESTION:  What is a really good example of a simple, beautifully packaged and written and documented python package?

[00:01] <pochu> nealmcb: well, it's hard to choose one (maybe those of mine? ;) so I'll suggest you to look at those maintained by PAPT and DPMT (for modules): http://svn.debian.org/viewsvn/python-apps/, http://svn.debian.org/viewsvn/python-modules/

[00:01] <pochu> nealmcb: you can also checkout the svn repository if you want, svn://svn.debian.org/python-apps/, svn://svn.debian.org/python-modules/

[00:02] <stani> ok, thanks everyone for attending. I propose we close this session now.

[00:02] <sebner> stani: also thanks to you :)

[00:03] <jcastro> thanks guys

[00:03] <jcastro> that was awesome

[00:03] <jcastro> ok, next round of sessions is @ 1500UTC tomorrow!

[00:03] <pochu> Thank you all and good night!