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