 Okay, so I myself, I'm the next speaker, so to reiterate my name and Martin Eric Rossin, I'm originally from Juliette in Quebec, I've been living in Finland for seven years, which is how I came to be a member of Linux activatory as well. So my speech is a bit in continuation with what Alex said earlier about how to help Debian from the user site, and he had just started mentioning the new maintainer process. And what the new maintainer process usually implies is that you start packaging things for Debian. In theory, there's other approaches such as helping on documentation and other issues, but in practice, the test part at least tends to be about packaging something. And so that's what basically I'm going to be talking about now is how do you package things for Debian, and why would you do such a thing? I'm going to address this aspect from not just the individual part, but as well on aspects of bigger groups, corporates. I'm going to briefly touch on the technicalities involved, among other things about all the policies and the tools provided by Debian to do this. So the first questions that we might ask ourselves is who usually would be developing for Debian? And the three typical cases are an independent free software developer. That's basically the most common case. Someone somewhere decides that he needs something done, codes a piece of software, puts it on his website or on some common software repository like Freshmeat or Sourceforge, and that's how it starts. Then the second fairly common case is a big open source software project. We're taking things like X386, XOR, Samba, all sorts of big projects that have in many case corporate backing as well, and that already have a fairly intricate development system in place on their side. And now the next step for them is to submit their package or make it more readily packageable by Debian. And the third one, which is seldom talked about, which I will nonetheless address today because I think it plays an important part in increasing Debian's visibility, is independent software vendors, which basically means people of, I'm going to say a very nasty word. I hope my application manager doesn't hear me, non-free software that are binary only. One fairly well-known example of that is the Opera web browser, which is available for certain architectures and readily available as Debian packages. Of course, it's closed source, so it cannot enter the Debian repository, but the main point is if a company wants to make their products available to you, a Debian user, what point is there for them to just produce a Red Hat archive, an RPM file, and then say, well, that's our Linux package. It's not helping you to use their products if you want to, does it? So they would need to produce Debian packages and optimize one example of those. I myself have been involved at the company that produced network security tools such as VPNs and firewalls that use the Debian tools to package their software and make it basically readily installable on top of a minimal set of Debian packages. So I'll discuss basically what those three group of people would do. Now as I've already mentioned, the main two types of software you'd be packaging is commercial or free software. I'd also like to point a halfway situation that is becoming a lot more common lately, which is dual license software. One fairly visible example of that is OpenOffice, which depending on what you're doing with it, if you're using it for personal purpose or as a free software developer, or whether you're deploying it as a corporate level or adding to it proprietary features, then you can use one or two of two different license, one which is definitely corporate-oriented and another one which is free software-oriented. And why would free software developers, open source projects, or ISVs, want to produce Debian packages? Well, the individual might want to learn more about Debian, might want to learn more about programming as well. It's a mere question of curiosity. I've mentioned this morning one of our Linux activists, remember, who is a fairly young teenage girl, who basically enjoys trying things. She's got the typical hacker mentality. So for her, Linux is the ideal environment to explore things. And it's a very good learning experience for her. So packaging thing could be also a learning experience and get her further in depth into using Debian and appreciating it. Now for ISVs, it's mostly a marketing point. For many companies, and I've been able to notice this a number of times, to be able to claim that, yeah, we noticed this other non-Red Hat distribution that's fairly strong, which is Debian. And to us, it's a visibility point. It's going to help us hopefully make sales. And you'd be amazed to find how many companies use that as a motivation for doing it. Now another aspect could be actual free software enthusiasts and programmers or students of computer science. Now in their case, and this is something that's been mentioned a couple of times already earlier today, those people are trying to improve their skills, get noticed. I think it was Gunnar Wolf that said earlier that you almost have to approach this in a selfish way. You want people to notice your skills, you want people to notice how good you are. You also want to develop a certain visibility that could perhaps lead you to an actual real paid job working on free software. So getting involved into Debian is one good way of developing those skills, developing the visibility needed to get those jobs or to progress in the free software universe. Now Debian, I'm afraid to say, has had in many circumstances a rather gloomy reputation. In some cases, we've heard rumors of Debian developers being downright insulting towards users. From the corporate world, every time the excuse that comes out as to why they are not going to be releasing packages for Debian is the release that Debian takes too long, it's a pain in the ass. We really don't want to be doing this. Please give us one good reason. And then from a young budding programmers perspective, well it might sometimes appear that Debian has an extremely complicated set of procedures of standards and of regulations to follow to actually produce something that is acceptable to Debian and is acceptable to Debian users. And are those issues really justified? Obviously, if they keep popping up on mailing lists on various websites, there might be some elements of truth. My experience has been that there's actually quite positive people and that participating in Debian can be easy. You can easily reach your goal for the participating in packaging software for Debian through basically three main set of enablers. First is mentoring. As aggressive as some Debian developers might sound, there are others who are actually thriving in an environment where newcomers seek their help, seek their guidance. Debian in fact has a mailing list called Debian Mentor whose sole purpose is to help people learn the ropes of the procedures, learn how to use the tools and learn how to properly package Debian software for Debian and basically be able to meet the kind of high standards that Debian is known for. And the main tool to be able to learn what those high standards are and to be able to meet them is the policy manual. It basically is the Bible of Debian. It is the absolute minimum essential sets of standards and procedures that Debian is known for. And I'll come back to these points a bit there as well. And the last one, of course, is that Debian is well known for its excellent tools. Of course, APET is very well known for its ease in upgrading and installing packages on Debian systems. There's also development tools that are quite good on Debian and that simplified task a lot once you start learning them. And so as I mentioned, the policy manual, it really is the cornerstone of everything that is Debian. I could also mention the social contract. Alexander did an excellent job of mentioning that and others have done it earlier as well. But from a packaging perspective, the policy manual and to some extent also the developer's reference manual tells what you need to know in terms of guidelines, in terms of procedures and in terms of standards. Now, assuming you would have software package that perhaps you found on the website or that you developed yourself and you're thinking, okay, I'm going to give it a shot. Let's try this Debian packaging thing and where do I start? You're talking about policy manual and my hairs are rising on my head. I have a sudden urge to go to the toilet and I panic at the mere idea of sending any mail to any mailing list on Debian. So where do I start? What do I need to add to my piece of software to make it useful for Debian? Well, as far as policy has it, it boils down at the bare minimum to these four files that sit inside a folder called Debian inside your source tree. And with this, you can get cooking, some fairly decent package. There's more, of course, that's the basic minimum. And just to show you a bit how you can, how this file looks like and how you can start using them, I have two package examples that I'm going to use. The first one is a brand new one. It's not uploaded yet. I packaged this a couple of days back. Game for those who don't know it is an instant messaging application for the GNOME desktop. And the problem with game for those who are using it for all of their messaging, instant messaging and chatting purposes, as they might have noticed, is that it does most of the recent protocols fairly well. But for the granddaddy of it all, which is still the main means of communications in the free software world, for IRC, it's somewhat a bit crude. And one thing that has been bugging me over the last while is that every time I log into the FreeNode network, which is where most free software developers hang out, it always asks me to identify myself, give a password and all this. In game, of course, there's been very crude, and in my opinion, not too efficient recipe to achieve that, which is to pretend that the service that is designed to authenticate you is one of your buddies. And every time your buddy shows up on IRC, you send them a message with your password. The problem with that is that I have lost the configuration file from game from time to time. Every once in a while, there's a new version of game that managed to eat its own configuration file. And basically, completely destroys my carefully crafted personal reply to my buddy, the Nick server. So that script, basically, IRC Helper is one script that I recently found. Actually, it's a small C program, very simple, and it's a plug-in that goes into the game infrastructure. I compiled it locally at home first just to try it and see if it actually did what it pretended to do. And, wow, surprise, I've never had to type my password again in a few weeks. Okay, found my solution. So except that I'm running Debian, I have, let's see, about half a dozen different machines in different hardware architectures. And I tend to have identical setups. So the first thing I did is, well, okay, I have to package it. Now, one aspect that has been mentioned a number of times today is that Debian is about free software. A few people have clarified this already, so I won't reiterate what the intention of free is. Suffice it to say that we need to be able to prove, without a doubt, to Debian that what we're about to package indeed fits the Debian agenda. It is indeed a piece of free software. Now the way to do this is basically to check out exactly under what sort of license the piece of software is released. And if it's one of the already approved free software license, then, in principle, you're all set. But you must declare that inside your package. And what basically you do, it seems I skipped a slide, I'm sorry, that's the next one I was just explaining, sorry about that. So and the reason why we have this slide here is you notice those three file names. Now the way Debian works to build packages, contrary to other packaging systems, is always from the perspective of the source package. It doesn't matter what kind of actual applications and libraries and development files your package will produce. As far as Debian goes, we're treating it as one source package that does something and produces different functionalities. So the first thing we have to do, and that's what I did when I packaged it, is rename that original game, IRC helper, version 0.11, by adding the .orig, which means that this is the original file. Now the important thing is that, and if our Debian developers correct me if I'm wrong, I'm still going to an M here, indulge me for a minute, if I'm not mistaken it's actually stated in the policy that we have to work with pristine source, am I correct? Not mandatory, okay, encouraged to. So the main idea here is that I have my original package which I picked up on search for, from the authors section, and then we're going to be producing differences to that package that imply possible modifications we've done to it, as well as the files we need to package it for Debian. And at the end of it all we'll end up with those three files. So our original tar ball, which we picked up and renamed to .orig.targzip, and then the differences to that. And then we have also the description file, which basically is a file used by packaging tools to tell it how to unpack and recombine all those two first files. So I mentioned already that, so we're starting with these files, that's as small as this plug-in is. There's all the usual info about what the copyright is, different installation and compilation notes and so forth. And to this, so we're adding the copyright file I just mentioned, and this is a fairly typical one, in this case I was lucky enough that the package is released under the GNU general public license, which is a fairly common one in Debian. And so the main information we need to find on this page, if you look from the top down, is who packaged it and when first. This is very useful and very important because if there is ever any problems relating to the license of this package, you can always get back to whoever packaged it and make sure that they verify any outstanding issue. That's also a good way to find out when the package was introduced. Then where did I pick up the package while you have the URL now? The copyright is also important, we need to know who wrote this, we need to, we at least need to acknowledge that people write free software and it's good for them. As Gunnar said, we do it for ourselves, we want fame and okay, there's our two lines of fame for these two people. Now the important part as far as guaranteeing that we have free software is the next part, which is the shorter version of the GNU GPL and the usual, since the GPL is such a common license, it already resides on the Debian system by default, it's one of four main licenses that is always there in full, readily available. So the common practice is we don't need to copy it, we just refer to it at the bottom, which is what the last two lines say there. So a second file we need between each release and each package we produce is a change log. Now there's also a very precise format for this, which is the package name followed by the version in parenthesis. And then where are we uploading this package? Well, I cannot remember who exactly discussed, actually it probably was Andreas part to discuss the different repositories we have in Debian. Now the common one to upload brand new package is to unstable, and in this case, since it indeed is a brand new package, that's where I'm sending it. And urgency is in this case low, I'm not fixing any bug, I'm not trying to help other packages fix their bug either. And then a description of what exactly this release, which is the first one does, well, in this case, I'm just saying it's the initial release. Now notice this bit after closes some number. That's a bug number in the Debian bug tracking system. And I can tell you what that particular bug is because I found it myself. It was an intent to package this piece of software a few days ago. So by the time I upload this package, the Debian Archive's uploading script will parse that change log and notice that I'm closing a bug. And automatically that intent to package will be closed. Then the next piece, important piece of information is who made that last change to package, in this case it's me, and when. This line as I recall has a precise format as well, which is basically space to dash space, name, email address to space. And then the date there is in a special format, which is referring to RFC 822. That date format is something you've already seen if you've ever looked at the raw email message, for instance, or an email sent from an English on a local. It's a standard internet delivery, message delivery date format. And there are tools to produce that special date type as well, which I'll mention a bit later. Now, the next file, which is also very important, but mostly from our perspective, is the source control file. Now what this file does basically is it tells you what is the name of the source package, what type of package it is, in other words, what section we're uploading it to, the priority as well. So I'm just going to briefly discuss section and priority because those two, as I recall, noticing a few times in different mailing lists and portals are somewhat mistaken sometimes. So section basically informs you as to what type of application we're dealing with. In this case, since game is an application that's compiled for GNOME and game itself is a GNOME application, logic would have it, the plugins design for it would most likely go in the GNOME section. If I had packaged, let's say, a text editor, it could probably have gone into editors. A web server or some internet application might have gone to either a net or web, depending on which ones we're talking about. Basically, it's a general descriptive term that fits the application and your packaging into a specific type. Now, priority, Debian divides package according to what sort of necessity they might have and what sort of, well, I wouldn't quite say use, but the level to which you would expect them to be there as well. There's not that many of them, actually. The absolute top level is required. That's the level that absolutely necessary package that you need to actually boot the system, which you basically cannot make do without get assigned to. Then there's important package. They're not absolutely essential to launch the system, but then again a lot of things might go wrong without them and they're kind of expected. Then beyond that is standards. Now standards basically is the basic kind of command line applications you would expect to find on a standard Linux or Unix system. One phrase I've seen, I can't remember if it was in the policy or in the developer's reference manual that I think said it pretty well, is you would put standard to something that any Linux or Unix user would go, how come that application is missing? I don't get it. It's something that's expected. It's not required, absolutely necessary to boot. It's not very important either to perform certain basic tasks, but it's kind of expected. Then beyond that is what I used here optional, which is that huge grab back, basically graphic user environments and applications that are neither essential or expected at the command line level tend to go in that category. Now the next one, Extra, is a bit unique. It's also a slightly more rare one. Basically what Extra does is it means the sort of applications that either conflicts with the first three levels required import for the fort. Optional as well? My mistake. Basically that conflict with any of the previous levels I just mentioned or that would seriously alter applications from any of those levels, operation or might cause potential damage or designed for such a specialized level of application that you really have to know what you're doing if you're installing them. I'm going to have an example of that after this one. The next item that we have is the maintainer. Now this line is actually parsed to generate other files as well, which I'll mention a bit later. Now the next line is important as well. It basically tells the packaging tools what do we need to actually get this package to build as far as package building tools, as far as development libraries we need to compile the package. That sort of thing. Now in this case, and these are the two tools I'm going to be discussing a bit further on, I have included CDBS, which means CommonDB Build System, as well as DebHelper. Now those are two packaging tools, which I'm going to be discussing a bit later. And then since I'm building a plugin for game, I also included GameDev. Now next after that is a standards version. Now I mentioned the policy. Every time there's a change to policy, a new version is released, and your package is supposed to inform in the warrant that you're actually complying with a specific release of that. How do you verify if you're complying with it? Well, the package that is actually called the DebInPolicy includes a checklist that lists all change for each release of the policy. If you want to verify that your package matches all those points, you just go through the checklist. Now next phase in this is the actual binary package we're about to generate. I'm repeating again part of the same. In this case, since I'm only generating one binary package, I'm calling it the same. I'm giving it the same name, which is game, IRCLPer. Section and priority. If you're only generating one target, as I'm doing here, it's kind of optional. I've just taken on the habit of always putting it. Particularly if you lift it out, it would be copied in. So the package name as well, you're saying? No, not the package name. Section and priority. Yeah, that's what I meant. But I always include it just to be certain because I always end up adding other targets later on. So it's just a habit I'm taking. But Brandon is indeed incorrect. They're optional and can be deduced from the first part basically. Architecture, that's an important line as well. What sort of package are we building? Is it just a script or a package that can be installed on anything that runs Debian regardless of what kind of microprocessor we're using? Or does this have to actually be compiled? In this case, it does have to be compiled. So the generic architecture we need to use for this is called any. Next line is when we generate the package, we actually need to tell the Debian system, does this plug-in depend on anything else? Now you'll notice in this case, I've used some substitution strings. I'm going to explain these a bit later on. Basically, those are going to be used by a packaging helper tool, which is called DebHelper. At this point, I think I could do a small incursion on the history of Debian packaging very briefly. The policy and the developers reference manual detail various kinds of procedures and rules, which are supposed to follow when you're packaging software for Debian. I'll take just one example among many. Among other things, it explains that if you have any example files or documentation file that exceeds, again, correct me if I'm wrong, was it 4K that they have to be compressed? There are specific settings you're supposed to use to compress them as well with the Gzip tool. There's different rules like this. Early on, when Debian started, people produced a detailed set of lines like this to, in a way, manually perform all the operations required to produce a Debian package according to policy. Now, a bit later, Joey Hess, who is among other things the one writing the Debian Weekly News, is also involved in a lot of parts of Debian. Is it? Okay. Sorry. I'll take that back. So, Joey, fair enough. Very good trick. Thank you. So, that's a fairly good assessment, I would say. So, Joey basically ended up noticing that, geez, every time we produce a package for Debian, we're always repeating the exact same lines. Okay, what was the exact setting for Gzip to properly compress a specified documentation file that exceeds a certain size? What was the exact setting we were supposed to use to generate shared library dependencies and so forth? So, basically, what Debian Helper does is it's a small collection of scripts that do all of those actions for each specific case. If I'm packaging documentation, there's a small script in the Debian Helper package, which is called DH, installed for instance. So, and that little helper, yeah, that little helper basically knows what the policy mandates and does it for me. Now, at the second stage, which is a fairly newer thing, we had CDBS and now, if we look at this from the bird's-eye view of this, Debian Helper basically performs all those small tasks for each individual bits. It's an interval step required to make a package. Now, CDBS goes the next step and even automates which of those helpers you're going to be calling and basically really simplifies packaging. So, Debian Helper is basically the one that's going to be telling the binary package what the dependencies are going to be. Now, next is the description. I think that part is fairly self-evident. The only detail I will have is that you'll notice that between paragraphs, there's dots. You cannot put space. The only way to specify different paragraphs is to separate them with a dot, which is what I did. Now, we get to the core of the building part, which is the rules file. And in this case, as you've noticed, I have used CDBS. And basically the only thing I need to do to get everything to be all those two includes, I'm using a make file as we've noticed earlier in the content of the package. And to actually build the package and wrap it up, we need to use the Debian Helper, so I'm including that as well. Now, the only small dent here is that since this is a game plugin, there is a separate helper for that which comes with GameDev, which I've added. But basically, this is all I need to, from the tree first file, end up with the Debian package based on that tar ball I downloaded. Now, I said that those were the four minimum files. There are more options. This is just a bare minimum. In this case, you'll notice that I have one file called control in in my Debian directory for this. Another one called install and another one called watch. I'm briefly going to overview this. You'll notice it's almost the same file as I had with the control file. Now, the only difference, if you look at the build-depends line, fifth line from the top, there is a really weird bit with CDBS between two Atmarks. That basically means that the exact version of CDBS I use will be dynamically replaced by CDBS itself, so I don't have to worry or remember what I last used. It's a very useful trick for binary package that need to be compiled because, especially in the case of desktop applications, there's always some little tidbits that were added with later version of CDBS or DebHelper, and by inserting that CDBS between two Atmarks, both DebHelper and CDBS versions are adjusted according to whatever you used at the time you packaged it. The install file, well, I have a slightly unusual file which is a library for games, so I'm telling DebHelper where to install it. It's a simple one line, the name of the file and where to send it. The watch file, that's used for Debian's package health tracking system. What this basically does is it informs the Debian project as well as the maintainer. Has there been any more recent version of that package released by the upstream author, and it allows you to easily update your package with just a few commands based on this file. Now, a much simpler example, and this is the type of example that anyone who wants to quickly try their hand at building a Debian package can do, is a meta package. Now what it basically does, the only thing it does is it depends on other package which you tend to associate together, and in this case it's a native Debian package so there's no different files. We just have one native tar ball which does everything we need, and it contains exactly four files which were the basic ones. Now, copyright files, well, we've already reviewed it. It follows pretty much the same format as we had earlier. The changelog as well. Debian control, well, in this case since I'm building what is basically a static package that just pulls out I'm directly declaring which CDBS and Debian helper version I'm using. Now that would be, as you can read from the description at the bottom, a hypothetical package pulling all the applications that have been recommended by the network administrator for this conference to be able to connect a laptop. And basically four files and I have a package that pulls all this. Now the nice thing about this sort of package is let's say you have different workstations at home or at work and you notice you always tend to install the exact same applications. Well, the easiest way to always install them all and never forget to on is to list them in such a meta package and install that. I've made myself such package every time I install a new one I get the exact, the normal environment I want with the exact same list of applications always used just by pulling one package like this. It's a neat, simple exercise to try to build your first Debian package. And the rule files in this case is even simpler. I'm not building any binaries so the only thing we have is to wrap it with Debian helper. So, just a quick rundown of the tools we're using. So I mentioned CDBS and Debian helper below this in the kind of hierarchy ways, DPKG development files. That includes one command called I mentioned the date format we had in the changelog and in the copyright file for the date where you packaged it. That's the small command that gives it to you. You just need to redirect it and paste it to the file. Linda and Linton, those two packages are there to help you verify that you are indeed packaging something that will match the policy that you haven't committed any stupid boo-boo that will result in your package not being included in the next Debian release. And you will, as well, avoid the flames from people from a certain mailing list called Debian legal, which I think is a nice thing to avoid in general. I'm sure others will agree. Well, no, but basically, I mean, they will be checking for all sorts of boo-boos. These scripts, I won't be discussing this one. Suffice it to say that if you manage to upload scripts to Debian or to some other repository, you definitely want to be using the applications provided by this. People there, I won't be discussing it now because I'm running out of time, but basically it's a really nice environment to build packages and to ensure that what you're going to be sending to Debian is exactly what the Debian building host is going to produce, as well. Release strategies. Now, I mentioned earlier corporate people, so there's basically three ways you can release those packages. If you're a company like MySQL, or actually MySQL is a bad example, Opera, you're obviously going to be releasing your own packages because they cannot go into Debian. If you're going to intend to release them through Debian, then you pretty much basically have to pass through the usual process, which is to first get a mentor to help you ensure that you've done a good job and eventually someone to sponsor and upload and try to send it to Debian. After a while, if you start packaging enough software, you'll start to notice that it becomes a real annoyance to ask someone to upload your package for you and that the usual person you ask to, as well, starts becoming annoying. Yes. Just an announcement that those who are registered Debian visitors who want to have their evening meal, now is the last chance you get to go. I am allowing you to just leave out if you need to eat now. Yeah. Understood. Understood. I have three slides left. So basically, as I was saying, if you're starting to request people to upload things, you might notice that they get annoyed, that you get annoyed and it takes a lot of time so you will most likely want to become a new maintainer and follow the procedure that Alexander outlined earlier and eventually become a Debian developer and upload your own packages. Now, a third alternative which is not often discussed is that if for whatever reason your package interested your friends, for instance, or some people that wanted them, but you're not a company in Debian for whatever reasons could not accept your package, you can still release them in your own home, their repository on your own website and it's actually a surprisingly easy thing to do. Now, that was it. It was as much of the very, very basic, I could explain of how to make the smallest type of Debian packages. Hopefully that starting point is probably useful to those of you who are software developers or corporates who were considering Debian and wondering how to approach this. This is just a starting point. I've mentioned the policy manual, the developers reference manual as well. There's plenty of material to read on the Debian website. Yeah, then there's the new maintainer's corner. That's what you meant, right? The new maintainer's corner among other things on the website which is a very good checklist of all things you need to familiarize yourself with. It is basic. What I just mentioned here is just scratched the surface basically, but I hope it's successfully demonstrated that packaging software for Debian is actually easier than it looks like. It can be a pleasant job and you can get the right tools to do it and the right people to support you in achieving it. I thank you for your attention.