 Go ahead All right, so this talk will be about packaging in a much different style than most would expect so First of all who among you have read the new maintainers guide or the packaging guide or any of that stuff How many of you enjoyed it? All right, well that's because they are very dry and To make this talk better and useful. I will ignore everything that is written in there. I Advise you do the same because they are very useful once you know what you are doing, but when you're Trying your first steps. They are an awful boring piece of something So we will do something very different today Another question. How many of you read the policy? From beginning to end Okay, congratulations one person. How many how many of you tried to read the policy? How many of you got bored after the first five minutes? Yes, because the policy is not meant to be read from beginning to end You look at it trying to find things when linty on yells at you so that's what we will do today and I Have one small announcement to make I have bad news. I promised ponies, but it turns out that Pony say is not free software At least the data is not So this talk we will package something entirely different, but since I promised ponies Here's one I drew today Doesn't look like a pony, but yeah Okay, so let's look at what we will be packaging today, it's a little program I wrote fits for Debian's 20th birthday The cake is a lie Apparently it isn't but well, it's an ass yard So it doesn't look like a cake, but if you squint a little you might notice that it is one and The resolution is terrible. So we have the text all over the place, but that's okay We don't mind it looks better when the resolution is bigger. Trust me on that. Anyway, we will take this piece of software It's really easy and we'll package it. It's your standard auto tools based thing written and see Has one source file and that's about it. How do you go about packaging it? Well, the easiest way is to call the big deal this command and See what it tells you well, it's missing a changelog and the Debian directory. So let's make one There's this handy tool called DC age, which is short for depth change. It is meant to Help you write changelogs and we'll use it to create one We fill it out. You've probably seen a few changelogs. It's not rocket science Oh Okay Sorry Fill it out We do not have an ITP back to close. So that's about it. Let's see what it says now. Oh Long text lots of things. What didn't it find? Oh? We need a control file. What is a control file? Well, the control file tells deep AKG What sources you have and what binary packages you want to build so we'll hack up a Really easy one first of all every control file has to have two Sections the first section that describes the source It looks a bit like Okay, sorry, I always forget my editor is a bit dumb The first section describes the source Which in this case is this We also have a couple of other fields. We need here like the maintainer and What else we need a section? let's see games will be fine and the priority which will be extra and That should be enough for starters and I need to learn to spell The next section is about the binary We will build one one binary package Accept its core package is with the same name we give it the description and The long description starts right after in the next line You have to start it with a space Because this whole control file looks like an email And starting with a space tells the parts so that it is a country a continuation of what was about Okay, and that's about it. So we have a very simple control file Let's see what the tool tells us Hmm. All right. We need an architecture field Every package in Debian must Have an art architecture associated with it It can be either An arch all package, which means the same binary will run on all architectures in our case, this is Wrong because this is a C program which is compiled and it depends on the architecture So we write any here You could list the architectures here if your package is Something that only works on a certain subset of architectures You can make it Linux specific by writing Linux any or FreeBSD specific like Writing K3BSD any but this is portable thing. So we'll write any going further. Oh Now it needs a rules file. We're progressing the rules file is used to do the hard work It tells the pick a GD rules About how to build a package in the most simple case like ours will do with this only This is magic black magic But the wonderful thing about black magic is you don't need to understand it if you need to Change the way the magic works You only have to understand little pieces of it and thankfully that helper which The age is a part of has wonderful documentation Man pages and so on and so forth So I would suggest that if you start packaging something start with this and If something goes wrong go from there We'll see how things will go wrong And by the way Debian rules is a make file. That's why we have this first slide here We also need to make it executable of course And let's see what happens. Oh, yeah Since it's a make file. I have to make it to make file There we go Well, it did things but it also told us a lot of errors and Other things So we need to tell this tool to ignore the jits directory and a couple of other things the best way to do that Is to set the source format to The one it suggests us right here at the bottom We can do that by creating the new directory called Debian source and creating a new file in it called format and Having the text 3.0 killed in it What this format does you do you don't need to know at least not right now. It's pretty complicated and It's a similar kind of magic that that helper is It just has less documentation We also want to tell that helper that we want to use the latest and greatest version of it It was complaining about that too at the beginning, but I'm not going to score that high up Which we can do by echoing 9 into a file called Debian compact and Let's see what happens now Well, this is a much much much improved thing It compiled and now it is doing things and it is also asking for my No, I'm not going to sign it right now So it did stuff. It also built a Debian package for us, which is great But the thing is there are a lot of things missing from this For example, we can run Lintian on the changes file and it will tell us all kinds of things a Lot of bad bad things about the package Okay Let's see. We're missing the mate in our name, which I'm not going to fix right now I'm not going to fix the changelog either because I know better It's missing a copyright file, which I'm not going to add either because writing a copy Copyright file could take an entire session of its own I Can add the standards version field, which is as easy as this the standards version field Signals which version of policy this package was made to conform to What is worse is that we're missing dependencies If we look into the package the debate package We will see that there is no depends line if we try to install this It may work and on my computer it will because I already have all dependencies installed But since it's a compiled thing it will at least at least need Lipsy and probably a few other things as well So we do another kind of magic and The depends line to the binary section now Here's this line of magic which looks like shell variables except they are not The way it works is When depth helper runs it will Find all the packages that your binaries depend on at least if they are in C and Fill this variable out with the results It's something like LDD improved Here we see the output of LDD as you can see this this thing depends on quite a lot of things I Ranging from free type to Liby X 11 to Other things Yes, one moment wouldn't you have to go through configure AC to figure all this stuff figure out all we can We can and we will just not right now We need to figure out the Dependencies of the binary if you go through Configure AC you can figure out the build the dependencies Which will be useful too, and I'll get to that in about five minutes to figure out the runtime dependencies you can Use this as a lips depends line and It will be figured out automatically most of the time To figure out the build dependencies You have to do that manually and As I said we'll get to that in a moment I'm not going to be at the package again because that takes a long time I Will show you another thing very useful to called s build Which works by setting up a clean environment to build your packaging so The last time I ran DPKG build package it also built a source package, I believe or if not Yeah, it did okay, so As builds works after setting up which is easy and well Documented in its manual page and other kinds of documentation It sets up a clean environment with only build essential installed You can give this to Debian source control file. It will grab all the build dependencies install it in the CH root and try to build the package it's very great to figure out what your build dependencies are and Whether your package will build on the auto builders or whether it will not This takes quite a long time because it will have to install all the things well except it won't because We don't have any build dependencies right now. Oh We do because Never mind Just stop this I forgot that I build the source Earlier Maybe this time one moment I'll fix this in a moment. Let's see So we should have no build dependencies now And what's the problem now? Okay, while I fix my environment We'll skip the next step If I'd compile this thing without build dependencies, it would fail in a clean environment So what we'll do next is go through configure AC and figure out what this thing needs Well, let's see It needs PKG config Because that's what provides this macro It will need I'm not sure how to pronounce this Leap kaka Something it's like a leap but with colors and it also needs in leap to So let's add the add those to the build depends and it also needs that helper because we're using that And since we're using compact level 9 we need that helper version 9 or later We need this This should do We build the source package again, and I forgot to tell it to not sign it There we go Let's see how it works right Now it figured out That it needs Quite a bit of packages It can also download it from the they build dependencies from the internet. I have them downloaded already That's why it didn't do that Then it installs all of them will try to Compire the package and make a binary out of it and if it all succeeds it copies the result into the same directory we run the tool from and If it doesn't work then it will Leave the log file of the whole build in the same directory we run it from Sadly it takes a little while on my laptop because it's Kind of old and slow, but we're already at the setting up stage meanwhile Do you have any questions so far? plenty The setup we see running now that's setting end up in a sandbox or something. Yes, okay As build is a tool with which you can set up CH route a clean one and It will do all the magic in there It's also useful if you are running say stable or testing but want to build for unstable Because everything that goes into Debian must be built unstable Yes, yeah, hey You have any recommendations regarding the build environment for example using P builder over cow builder Personal preference. It's just personal preference. I used as builds ever since it was packaged So that's what I'm That's what I'm familiar with But other people are using P builder or cow builder and I think there are maybe one or two more similar tools They all work. They all have different properties you can choose whichever you like and It builds and now it's Removing all the packages it's installed before and We have a successful build but linty and failed Well, that's kind of expected because there's a lot of things missing from this thing and Oh, right Stupid nevermind So we have WM package right here, which we built and Let's try installing it. Oh There are things in it and if I run it It works It looks a bit silly, but it works and I just remember that I had this terminal open because I wanted to run it here because it has smaller fonts and it looks much nicer this way and Yeah, that was what I had Prepared, okay, so if we run linty and on this thing it Tells us a few more errors and warnings Like this binary doesn't have a man page It's in section games But contains no games because games need to go into you USR games not into USR bin We can actually fix that easily and that will show how to Yeah, so We have a package which should be installed into USR games instead of USR bin Since we build the only one binary We can tell the configure The binaries should go into USR games not USR bin With depth helper using this short form we can do that by overriding the Configure step that works by adding a new target to the WN rules make file We simply call the original tool and Pass it prefix user games Argument This will do all the magic DH how to configure does which includes adding the Hardening flags adding All kinds of other Options, but we will also tell it that we want to change the prefix another thing about the dch tool is It can not only create change log file. It can also add new versions into it by using the Minus I option now we build the package again and I stopped the build Oh shoot Anyway, if it wasn't scrolling this fast you could see that the argument we Added was actually passed. Anyway, if we look at the not going to get it in my commander There's this other commands called dpkg dash deb with which you can inspect extract and Reassemble the beyond packages right now we use the minus C Which means? content option The list what's inside it well This worked a little Except we didn't want to pass pre-fix because it puts everything under a user games then Including the documentation. We only wanted to do place the binaries there so It's not prefix, but Been there I think Okay, we go through all this again and This time instead of looking at the final package We'll have a look at at the dbn directory as you see there are a couple of new files there like Debian slash files or The cakey cake is a lie dot depth helper log Which is a log of the depth helper commands? That's ran or the substores file and there is a die like directory called cake is a lie In this directory is All the things Installed which our package will include if we go through that we'll see that under you assert games is our program There's the documentation and there are the pictures as well, and there's a dbn directory In all capital letters That directory is special That contains all the thing all the method data that also go goes into the final dbn package this is all created by depth helper and If you want to quickly look at what goes into your package You can look look under the dbn directory and find the Directory with the same name as your binary package and see what's there what is in there will go in your package and If we run the Indian on this again, well it complains about a lot less things And our program is finally at the correct location So what I would advise is If you start to package something from scratch scratch start with the very simple rules find it pretty much leaves everything to that helper and After each iteration run lintian try to correct the problems and If you need to change something which that helper can't figure out or Something it figures out, but wrongly just add an override you don't have to know All the magic that is behind that helper just a few tiny pieces which you need for your package and Yeah, that's pretty much my recommendation I found it works fairly well Most of my packages are built this way Any questions, yeah Here in the front. Where does make come into play? Well, I'm not quite sure why make was chosen originally for the dbn rules Some 10 10 years ago you only had to had a file It didn't have to be a make file although it was recommended But policy was changed to To require it being a make file, I'm not quite sure why it's most likely habit or History curve reasons Does it answer your question or Maybe my question was wrong What's the difference between the package build package and make Oh, yeah. Well, the main difference is Is the big package you build package does a few other things? Like generating a changes file for you. It can also build a source package and It can do a couple of other things, but the main difference is Generating the changes file The changes file lists Well, we can just have a look at it the changes file is what you actually upload to the to the dbn servers along with the rest It lists all the files that belong to this version of the package Including the source if there is any and this is something that make can't do this is all done by DPKG Built package or well actually a tool that it calls for you So we can do something like that beyond rules binary if I were in the right directory that is Which will do nothing right now because it's already built But I can clean and I can run binary and it will do all the things that it did before DPKG build package does call this command as well The difference is that now I got a depth file and that's it. I don't have a source Source star ball. I don't have the Debian Tarbo, I don't have the Debian source control file I don't have the changes file and I don't have any of them signed either The package you build package does that for you any other questions Other here. I never packaged anything, but I have a some code that has the Debian rules For Ubuntu. Is there any difference? Not much. Could it be a start to learn to package? Yes, and if it's a Python package Well, that's a little bit different You will most likely Need to adjust the dependencies by hand. I'm not exact. I'm quite sure you can't figure out Python dependencies automatically But otherwise it's very similar I believe But if you have a Debian rules files from Ubuntu, that's a good start Okay, thanks. Well If there are no more questions, then I Think this was it. I Can be reached at our turn on at Debian.org or on IRC If you have any packaging related questions, feel free to turn to me and I Will be happy to answer if I can If not, I'll try to find the appropriate documentation