 I'd like to present you DH Distiller, quite recent depth helper plug-in, which adds support to another build system. So but first a few questions. I guess everyone in here knows depth helper. Who packages Perl module rules in here? Oh I see two people coming in who do, at least, they were just in time. So who packages Perl tools, well, okay, some more. Who packages his own Perl tools as a depth, well, okay. So who knows Distiller, okay always the same group I think here, and who uses Distiller for his own Perl modules, okay. So we'll need a little bit introduction into Distiller. Distiller is basically a helper for Perl module authors, which don't want to repeat themselves. CPAN needs quite some files which contain metadata like the dependencies, some exact commands to build the distribution, et cetera, and those usually are dependent from your actual Perl code. What Distiller does is with many plugins, look at your Perl code and it generates this file, these files, upon build. So you only need usually one single configuration file which has all the non-deterministic metadata like maybe sometimes the version, which isn't hard-coded in a module, sometimes you can say oh take the version from that module there it is in, et cetera, it has a quite, Distiller's command is diesel and it works similar to Git in the sense that it has subcommands. So there are commands to build the distribution, to uncover it, to install it, to run the test suite, to actually make a release and upload it to CPAN. So that's all very nice and helpful, so you don't have to commit any generated files into your Git repository, they are just put into the final table, but it makes Debian packaging a little bit difficult if you have such a Git repository. The typical workflow, if you have such Git repositories, you build the table for CPAN, re-import it into the upload branch for Debian with all the generated stuff included and then you match that branch again into the Debian branch, there may be a Prist and TAR branch be involved too, so you have already four branches, then you update the packaging, build the depth and upload it too. That's quite a lot of things you need to do, usually mainly, a few of them you can shortcut with using Git build package, Git import, ORIG, etc., but still what I want is building the depth directly from my checked out Git branch, from the master branch which only has Distini and my Perl code. I want to skip the TAR ball generation and especially the re-import of importing generated stuff into Git repository, it's not my thing. So that's where DH distiller comes in. DH distiller is a plug-in to depth helper which knows about Distini and does all the right steps to build a Debian package from such Git repository for all, doesn't need to be Git but can be any other VCS. So there are two obstacles when using the helper with such a repository, there's no build PL or make file PL, so it won't recognize it as Perl module and well for bootstrapping DH make Perl won't find a meter or other. The first step currently is a manual one, you want a diesel build, go into the build directory, there DH make Perl finds everything it needs and you copy back to the Debian directory. But the other step is what DH distiller currently is about, it will generate build PL, make file PL in a sub-directory and then we'll tell DH auto-configure, DH auto-build to do the actual build inside that sub-directory with the generated metadata. And same for clean, instead of DH, well it also wants DH auto-clean but the main clean target is doing the diesel clean one, which cleans up the build directory, nothing more is actually needed in the most cases. So it's quite small, the Perl plug-in but does what is needed. So how does it look like if I use DH distiller in my Debian package? It's as simple as adding dash dash with distiller. So then Debian knows, okay, I have to load that module which fills around a little bit with my sequences and it will find the dis-ini and just does the right thing. So from the workflow, it may be a little bit unusual then. Actually you check out the BCS called diesel build, yeah, CPAN tarpaul and then you build the source package out of that and then the binary package. With DH distiller, you can see the CPAN tarpaul and the Debian binary package as two different targets. So you have the same source code, exactly same source code and you once build the CPAN tarpaul which is some kind of binary package, source package at the same time and you build the Debian binary package just out of the BCS which equals the Debian source package. We have already one example Perl module packaged in Debian. As of, well not yesterday, likely more today in the morning at three o'clock, Lib one parts Perl and Debian unstable uses DH distiller. For the past year, there was always a Lib one parts Perl copy of the normal package built with DH distiller in experimental. So we have now that in Debian unstable and at that time I could also merge the master branch of the, which I use for the CPAN upload and the former DH distiller branch I used for the experimental packaging. There's just only one branch now and you can build CPAN module, the CPAN distribution as well as the Debian package out of it. So there's still some ideas how to improve it. We have one thing I can show you that in the, not sure if you can read that, we'll use the extra, well, we'll use new extra. I can enlarge the, well, large, does that work out? I can, yes. Thanks for the notice. I think it's in here somewhere. No. There. That's better. Can you read it back there? So I'm now lying. It's not maintained under package Perl team because of the, well, unusual workflow. So you see even the remains of the last build I did. This is what I uploaded to CPAN last night. There's the list, any file can have a look. So basically that's the stuff which it doesn't know about or puts into even my PM files automatically. There are some rules what I want to have generated, what I want, which tests I wanted to have, one, it should not commit any coverage stuff. So that's already a quite big dist, any, but still interesting thing is the Debian rules file, which I wanted to show you. Because there's a little bit more things in than just this line. That one is, well, specific to the actual module. I really have in their files which end in a tilde because they are part of test suite. The thing I'm not yet happy with is this year. I need to generate a Debian or a target set out of my Git repository, which is quite easy because Git provides a sub command for that. But this command is quite long. I think it's more than half of the whole Debian rules file. And it even uses this shell script which provides me the right package name, base, including the version number. So if I run that script, it just outputs lib one parts underscore zero dot zero nine. So because that's what I want to have in the tar ball as a directory name. That's something I want to put in DHG Silla and tell it, well, the developer now knows about Git ORIG source, for example. Although I prefer the ORIG target, named after Christopher Berg's famous ORIG target command, which just does the right thing. Back to the slides. And another nice thing would be to have a diesel sub command which just calls DH make pearl in the right directory, copy spec Debian, the Debian directory just does the right thing without having too much, well, very deterministic work manually, yeah. And actually that's already it, what I wanted to present. You can have the slides on no one org slash talks slash package pearl. Well, again, it's not the team, but it's about packaging pearl stuff. DHG Silla was written by Elmar Hape who was sitting over here. And it was also his idea and myself, yeah. It's hosted on GitHub and you can also find it in Debian Jesse already. So it's all things I showed you, you can use in Debian stable as of now. Well, yeah, the platform is maintained inside Debian. The Silla has its web page on diesel org as the sub command and well, DH make pearl is even on CPAN too. So you can read the documentation for example over there if you want some details, yeah. So actually thanks for listening. I'm happy that so many came for this, well, very specific topic and maybe someone starts using DHG Silla too. I'm quite happy with it. That's why I'm presenting it here. Thanks. If there are questions, feel free, you look like thinking. Okay, the table, is it committed somewhere, is that pristine top range, is it just lying around? Not yet, but I think that's a very good idea to do. So I think I'll put that into the same sub command because it's the obvious thing to do too. Yeah, to make sure you have the same table the next time. Maybe have you can look at .gbp.conf if the maintainer prefers to have pristine top enabled or so reusing infrastructure from other tools there or putting that in distini maybe as an option. So yeah, well, there's still, as mentioned here, a few ideas to do that. I'm also currently using the .xz compression and file format for now, because that's the current default in Debian 2, so I still would name the target or target gz because I'm so used to it, but well. Okay, thanks for the presentation. And I think everything that eases the workflow for the Debian packaging stuff, it all helps all of us. So thank you.