[12:12] <rohitkg> can anyone explain me,how to configure  the rules file
[12:59] <james_w> hello everyone
[12:59] <james_w> who is here for the packaging training session?
[12:59] <bac> good morning james_w
[13:00]  * Rail is
[13:00] <mr_spot_> i am
[13:01] <james_w> we'll give it a couple of minutes for others to roll in
[13:01] <james_w> but everyone should check that they have debhelper installed
[13:02] <james_w> we are going to be looking at manpages and examples from the package
[13:02] <james_w> also, you should check that you have debhelper >= 7 :-)
[13:03] <james_w> if you are still on hardy then you will need to grab it from backports
[13:07] <james_w> right, let's get started
[13:07] <james_w> hello everyone
[13:07] <james_w> my names is James Westby and I will be your host today
[13:07] <james_w> please feel free to shout out questions at any time
[13:07] <maxpaguru> hello!
[13:07] <james_w> we'll try and stay on topic to start with, and hopefully we'll have some time at the end for general questions
[13:08] <james_w> but there's always lots of helpful people in #ubuntu-motu
[13:08] <james_w> so feel free to jump in there with general questions
[13:08] <james_w> so, debhelper, what is it?
[13:09] <james_w> if you open /usr/share/doc/debhelper/examples/rules.arch you can see an example debian/rules using debhelper
[13:09] <james_w> it is a Makefile that is used to build the package
[13:09] <james_w> all of the dh_* commands are provided by debhelper to do common tasks
[13:10] <james_w> e.g., to clean the build tree it does:
[13:10] <james_w> clean:
[13:10] <james_w>         dh_testdir
[13:10] <james_w>         dh_testroot
[13:10] <james_w>         rm -f build-stamp
[13:10] <james_w>         # Add here commands to clean up after the build process.
[13:10] <james_w>         #$(MAKE) clean
[13:10] <james_w>         #$(MAKE) distclean
[13:10] <james_w>         dh_clean
[13:10] <james_w> so it calls dh_testdir, which checks this is an unpacked Debian source package
[13:10] <james_w> dh_testroot which checks the command is being run as root
[13:11] <james_w> then runs any clean target for the thing being packaged
[13:11] <james_w> and finally calls dh_clean that does some standard cleaning stuff
[13:11] <james_w> there are lots of dh_* commands that do lots of useful things
[13:12] <james_w> all are designed to do nothing if they don't apply though, the idea being that running one shouldn't do any damage if it doesn't apply to your package
[13:12] <james_w> .
[13:12] <james_w> .
[13:12] <james_w> lots of packages have rules files that look fairly similar to the above
[13:12] <james_w> with just small changes for the package
[13:13] <james_w> this means that they can be fairly repetitive
[13:13] <james_w> also, because there are lots of commands listed it's hard to see what the unusual things are, which makes review and learning harder
[13:14] <james_w> therefore debhelper v7 was invented, to help with some of these issues
[13:14] <james_w> .
[13:14] <james_w> ..
[13:14] <james_w> the basic idea behind debhelper v7 is that you say "give me a default package", and then make tweaks where you need to
[13:15] <james_w> this leads to the example rules file being like /usr/share/doc/debhelper/examples/rules.tiny
[13:15] <james_w> I'll paste it here as it is so small
[13:15] <james_w> #!/usr/bin/make -f
[13:15] <james_w> %:
[13:15] <james_w>         dh $@
[13:15] <james_w> .
[13:15] <james_w> .
[13:16] <james_w> quite a bit simpler isn't it?
[13:16]  * weboide agrees
[13:16] <binarymutant> very simple
[13:17] <maxpaguru> simple
[13:17] <james_w> but...
[13:17] <james_w> it's also not very clear what is happening
[13:17] <james_w> when you see this you should think "simple, default, boring package"
[13:17] <james_w> does nothing special
[13:18] <james_w> the "%:" means whatever target
[13:18] <james_w> and the "dh $@" means just have "dh" do its default thing for that target
[13:19] <james_w> with "dh" being a new command in debhelper v7
[13:19] <james_w> .
[13:19] <james_w> .
[13:20] <james_w> what dh does is run through a list of commands for the specific target and execute each in turn
[13:20] <james_w> so for the clean example above it will first run "dh_testdir", then "dh_testroot" etc.
[13:21] <james_w> where it will try everything that makes sense in that target
[13:21] <james_w> making use of the fact that debhelper commands do nothing if they don't apply to the package
[13:21] <james_w> .
[13:21] <james_w> .
[13:21] <james_w> but, we have a bit of a problem
[13:22] <james_w> what does it do in the clean target for running the clean target of the thing being packaged?
[13:22] <james_w> that could in theory be anything
[13:22] <james_w> .
[13:22] <james_w> .
[13:22] <james_w> what it does is run a command called "dh_auto_clean"
[13:23] <james_w> quoting from its manpage:
[13:23] <james_w>        dh_auto_clean is a debhelper program that tries to automatically clean up after a package build. If there’s a Makefile and it contains a
[13:23] <james_w>        "distclean", "realclean", or "clean" target, then this is  done by running make (or MAKE, if the environment variable is set). If there is a
[13:23] <james_w>        setup.py or Build.PL, it is run to clean the package.
[13:23] <james_w> .
[13:23] <james_w> .
[13:23] <james_w> so it knows what to do for the most common systems
[13:24] <james_w> if there's a common system that isn't covered then you can propose a patch to that command to add it
[13:24] <james_w> there is similarly and dh_auto_build and dh_auto_install
[13:24] <james_w> plus dh_auto_configure and dh_auto_test
[13:24] <james_w> they all work in a similar manner
[13:24] <james_w> .
[13:25] <james_w> .
[13:25] <james_w> what do you do if your package isn't common though?
[13:25] <james_w> in that case you need to run a custom command instead of the dh_auto_ command
[13:25] <james_w> how do you tell debhelper to do that?
[13:25] <james_w> .
[13:25] <james_w> .
[13:26] <james_w> here's where you use a bit of magic :-)
[13:27] <james_w> if you define a new target in debian/rules with a special name then you can run what you like instead
[13:27] <james_w> if you add
[13:27] <james_w> override_dh_auto_clean:
[13:27] <james_w> then debhelper will run that target instead of dh_auto_clean
[13:28] <james_w> so, to run a "./clean" script instead of "$(MAKE) clean" then you can put
[13:28] <james_w> .
[13:28] <james_w> override_dh_auto_clean:
[13:28] <james_w>         ./clean
[13:28] <james_w> .
[13:28] <james_w> in debian/rules
[13:30] <james_w> so, when you open the debian/rules file you can see "default package, except that it does something special for clean"
[13:31] <james_w> this works for all dh_* commands as well, so if you need to do something special when installing manpages you could write
[13:31] <james_w> override_dh_installman:
[13:31] <james_w>         dh_installman
[13:32] <james_w>          ln -s debian/tmp/usr/share/man/foo.1 debian/tmp/usr/share/man/do_foo.1
[13:32] <james_w> .
[13:32] <james_w> or similar
[13:32] <james_w> (and with correct indentation :-)
[13:33] <james_w> any questions so far?
[13:34] <bac> james_w: so there is a default target which we can override for all of the dh_* tools?
[13:35] <james_w> yep, to override dh_foo, add a target "override_dh_foo:"
[13:36] <james_w> and if you have really obscure needs you can still add a "clean:" target and run all the commands you need there
[13:41] <james_w> if you want to look at some real packages then you can run
[13:41] <james_w> grep-dctrl "debhelper (>= 7" -F Build-Depends < /var/lib/apt/lists/*_Sources
[13:41] <james_w> for a likely list
[13:42] <james_w> anything else anyone would like to know about the new debhelper?
[13:43] <weboide> james_w: How can we upgrade packages to dh 7 ?
[13:43] <james_w> good question
[13:43] <maxb> What about needing to override phases differently for binary-arch and binary-indep targets?
[13:43] <james_w> the first thing to do is increase the build-dependency on debhelper
[13:44] <james_w> then you need to edit your rules file, find anything that is not just running and dh_* command
[13:44] <james_w> you can convert them to override_ rules
[13:45] <james_w> then delete the rest and add the "dh" calls
[13:45] <james_w> make sense?
[13:45] <weboide> it does, thanks
[13:46] <james_w> maxb: could you give an example of what you mean?
[13:46] <maxb> uh, sure, whilst I hunt for it: How about mentioning --with quilt ? :-)
[13:48] <james_w> maxb: what does that do?
[13:48] <weboide> james_w: I think he wants to know how to integrate quilt/dpatch into a dh7 rules file. (or Im wrong)
[13:49] <maxb> Ah.... the short version is that it enables various additional handling for a quilt-based package built into the dh7 lifecycle - but I don't know more than that, and was hoping you could tell me! :-)
[13:50] <james_w> :-)
[13:51] <maco> there's also dh_quilt_patch and dh_unquilt_patch
[13:52] <james_w> ok, got it :-)
[13:52] <james_w> "dh --with quilt" means use the quilt "addon"
[13:52] <james_w> so if you do this and build-depend on a recent enough version of quilt, then debhelper will load the quilt "addon"
[13:53] <Laney> %:
[13:53] <Laney>   dh --with quilt $@
[13:53] <Laney> easy!
[13:53] <james_w> you can find this addon in /usr/share/perl5/Debian/Debhelper/Sequence/quilt.pm
[13:53] <james_w> (if you are on Jaunty or later I think)
[13:53] <weboide> neat, thanks :)
[13:53] <maco> (quilt 0.46-7 or newer)
[13:53] <Laney> I think that's only in karmic
[13:53] <james_w> which pretty much says run "dh_quilt_unpatch" before clean, and "dh_quilt_patch" before configure
[13:54] <james_w> so it will automatically do the quilt things at the right time
[13:54] <maco> Laney: dh7 is only in karmic too, though isn't it?
[13:54] <Laney> nah, that's in Jaunty (maybe not the override stuff?)
[13:54] <james_w> I'm not sure if there are dpatch of simple-patchsys addons as well
[13:54] <weboide> maco: I have debhelper >= 7 in jaunty, but don't have the dh_quilt stuff
[13:54] <james_w> intrepid has 7
[13:54] <james_w> but as Laney says, the override stuff is slightly newer than the first release of 7
[13:55] <Laney> maco: rmadison debhelper
[13:55] <maxb> override is present as of 7.0.50, requiring karmic
[13:56] <james_w> you can read more in "man dh"
[13:56] <james_w> and http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/
[13:57] <james_w> (which shows the original way of doing overrides, which was not nearly as nice)
[13:57] <james_w> http://kitenet.net/~joey/blog/entry/debhelper_dh_overrides/
[13:58] <james_w> so, get using it! :-)
[13:59]  * weboide likes dh7!
[13:59] <james_w> we're out of time for today
[13:59] <james_w> if you have any questions then head on over to #ubuntu-motu
[13:59] <maxb> To rephrase my previous question - how do you run conditional logic that must be run only when building the arch-indep packages - i.e. not on the non-i386 buildds - example, a Python module that splits its arch-specific and arch-indep files
[13:59] <james_w> ah, yeah, sorry maxb
[14:00] <james_w> I'm not sure to be honest :-)
[14:00] <maxb> Not a problem, and I'm happy to take this to after-session discussion in #ubuntu-motu :-)
[14:01] <james_w> yeah, let's head there
[14:01] <james_w> thanks everyone
[14:02] <stvo> thx
[14:02] <maxpaguru> Thanks. bye :-)
[14:03] <mr_spot_> thanks james :D
[14:03] <weboide> thank you for this session james_w
[14:04] <james_w> np
[19:19]  * marienjoanny marienjoanny 
[19:38] <rohitkg> can anyone suggest how to modify the rules file,while creating a debian package
[19:39] <nhandler> rohitkg: Try #ubuntu-motu
[19:40] <rohitkg> ok
[20:35] <LiraNuna> [04:59] <james_w> who is here for the packaging training session?
[20:35] <LiraNuna> damn, why are all the fun stuff on 5AM :(
[20:36]  * LiraNuna reads log
[20:36] <nhandler> LiraNuna: Logs are available on the wiki. The times also alternate each week