 Thank you very much. Okay. So thanks everybody for coming. This is how you can, if you're a packaging software and you want me to work on it with you, this is how you can do that. It's a very self-centered talk. I just wanted to explain some of the things that I like about some practices that I prefer about Debian packaging. And I don't pretend that this is any sort of official, permanent or final thing. It's just, I wanted to just share some ideas that I have about the way that I work with packages in the hopes that maybe, well, sort of two hopes. One is that I hope that I can show you something that you haven't heard of or maybe you thought you were doing differently, or maybe you think it's the right thing to do and you're just nice to see somebody else doing it. My second hope is that you can tell me what I'm doing wrong and you can help me learn and improve on my own packaging techniques. So if you see something that I'm proposing up here and you think there's a problem with it, I'd like to hear about it too. So I just want to, I'd like to see more of a culture within Debian of people who are doing packaging, explaining what they're doing. And so I thought I would just step up and explain, here are some of the practices that I do in the hopes that other people will do the same and explain what they're doing and maybe they can learn from me and I can learn from them. So without much further ado, I'm just gonna dive into it. If you have questions, I'm perfectly happy to be interrupted. We have some folks with walking mics in the crowd. You can just raise your hand. So if you've got a question or an interruption or whatever, that's fine. I doubt I'll go the whole 15 minutes. I think there's 20 minutes. I doubt I'll go the whole time. So there will be also time for questions at the end if you prefer. But I don't mind being interrupted. So this is all on this webpage here. You could probably skip this talk and go read the webpage but then you wouldn't get to have the nice in-person interaction and it's easier to tell me that I'm wrong in person. So I'd like to have that happen. So I put this up on the Debian Wiki because I want anyone to be able to find it. If you think you've got some good ideas, you should put it up on the Debian Wiki too. Other people can take advantage of the ideas that you've got. So okay, so first baseline is I really like revision control. And I know this makes me a certain flavor of nerd but when we're working with things that are as complicated as software packages and we're working, I mean in Debian, I think a lot of people don't get that in Debian you're not just working on one software package. You're actually probably, if you're doing it responsibly, working on at least two software packages and maybe five. So you've got the version that's in unstable and you've got the version that you're trying to maintain for stable as well. And we're committing to doing maintenance work. A lot of our work within the project is janitorial in nature. We want to clean up the mess and we want to sort of stay out of the way and make sure things work functionally for people who are relying on the operating system to not get in their way. So revision control I think is really helpful because it means you can keep track of what changes you've done on different branches of the project while you're maintaining both of them. So basically I require working with a revision control system I'm comfortable with, I prefer Git, I'm not gonna have a religious war about it. If upstream uses Git, I'm even happier. And I try to make my packaging depend on upstream's revision control. So I like to use Git build package and I like to use it with Deb Helper. So if you haven't tried out Git build package, we're gonna have a Git build package skill share session later on today actually and I welcome you to come and share your tricks with it or learn some tricks from other people. It's a particular way that you can keep your Debian packaging in a Git repo and it helps you to keep track of all of the changes that have happened within your packaging and within upstream to make sure that you're not accidentally making other changes. So it's very easy to go back and review what you've done. I find that really useful. I definitely also like to keep upstream's source code in the same revision control system. I like to keep the tar balls in the revision control system because it means that if someone is interested, they can use this tool called Deb Checkout and you can use Deb Checkout with the name of a package. You say just, you know, I'm really interested in package foo. Let me see the source code for that. Deb Checkout foo and you get the source code and you get the source code from a revision control system that you can now track and you can propose changes on. And you can also extract the tar ball from that revision control system. Deb Checkout actually works even if you don't have upstream stuff in there but I like to keep it all in one revision control system. It's just easier to find everything when you want. I also, so some of these things that I prefer have to do with what the upstream software developer has done. So I'm less inclined to try to package an upstream software project if they just throw tar balls over the wall into an FTP site every now and then. It makes it more difficult for me to know what they're doing and why they're doing it. So I like it when, I've already said that when upstream uses git, I also like it when upstream signs their releases and says, hey, here's a specific release because that's a signal that I can use to say upstream, at least somebody else who understands the project can, has said we think this is something that other people can use or this is a particular version that we would like other people to test. There are a lot of other situations where maybe it's not so important and having that be cryptographically signed is really useful. I care about cryptographic signatures on software because I wanna know that what I'm running is related to the code that somebody else thought should be run and if you don't verify your software cryptographically, anyone who can intercept the network connection between you and that software can modify the software before it gets to you. And a cryptographic signature just says, look, this is a version that I am okay with. I'm putting it out there and it comes from me and so I can have it traced back to that point. So let me just talk briefly about how you do cryptographic verification of upstream. So one is you might know upstream. You might know them personally. You know their key already. That's fine. That's not the usual case. We work on the internet. So in the situation where your upstream is signing their tar balls and you haven't met them, you don't have to sign their key. You don't have to say, I announced this is their key but it's probably the same one that's signing every release. So you should keep track of that. Debian has a nice way to keep track of that by you just, you can tell Debian how to find the new version of the upstream tar ball. So this is in the Debian watch file. If you type man, you scan, letter U, S-C-A-N, you can learn more about Debian watch and Debian watch now has a feature that lets you say not only this way you find the tar ball but upstream publishes signatures and the signatures look like this, like they've got a dot sig at the end. So there's a particular arcane way to specify that but if you specify it, then you scan can find not only the upstream tar ball they can find the upstream signature and if you drop upstream's signing key, which of course I didn't put on the wiki page, someone should edit that and fix it. You can put the upstream signing key in Debian slash upstream slash signing dash key dot ASC. So you can indicate and then if you do that you scan when you say you scan you can tell, so maybe some people here don't know how to use you scan. You scan is a very simple tool. You run it from a software package that has a Debian directory or even one level up if you keep all of your software packages in one folder you can go one level up and say you scan and it'll look in all of the folders directly that are children of it and look for new versions by trying to find the new upstream version in Debian slash watch. And if you've configured Debian watch properly it can find the new upstream signatures and if you've got the upstream slash signing key dot ASC then it'll actually verify the signatures for you as part of fetching the new upstream tar ball. So you can get all of those things just by setting up your packaging that way. Sorry, there's a hand up down there. Can we get the mic down to the hand? Thanks. Or to the person who has the hand. It's not just the hand. Publish a table and a hash dot SHHA one and sign the hash dot SHHA dot ASC. Yep. Can use can cope with this and check the signature on the hash and that the hash belongs to the table. I don't believe that you scan can do that currently. So anybody out there who wants to make things better for the world should go hack on you scan. That's a pretty straightforward thing that we should fix because I agree that's a common pattern. I have no answer to this question but I have another question. How do you convince upstreams who don't release tar balls or who don't set tags in Git? Which is the minimum. Who don't make tags in Git? Yeah, if they have no tags you cannot check out in tar ball. Is there any good way to convince upstream to do this? Right, so Git has this nice feature which is that you can create a tag which is associated with a particular revision and then you'd like to have a tag everywhere that a tar ball has been released from. I'm tempted to pull up a Git viewer and show people some tags. The question that you ask is a social one though not just a technical one. I actually find my upstreams are pretty responsive. Usually I frame my request as, hey, it looks like you made this tar ball from this particular commit ID. If you could tag your releases it would be really helpful to me and here's the command that I would use to tag the release and I say, Git tag and of course I can never remember so first I look it up but it's either tag name, commit ID or commit ID tag name but I would look it up and I would write the email so that all they have to do is they read it, understand my argument and execute one command and then that gets them in, I mean it doesn't get them in the habit but it starts them towards it. Thanks. Yes and if you say tag dash S then your tag will be signed with a cryptographically signed which I think is a really good thing to do too. So cryptographic verification of upstream. As I said I want to keep upstreams code in the revision control system. I also like to keep it, in my ideal case upstream is using Git. I'm using Git for packaging. I actually like to keep upstreams Git history fully in my repository so that I don't just have the tar balls but I actually have all of their commits and that turns out to be really useful for two specific cases. In one case there's a common scenario where upstream will fix a bug but they haven't made a release yet and that bug is really, really obviously problematic for the folks who are using Debian so I want to fix it. So what I can do is because I have their full revision history I can use Git to cherry pick the upstream commit and then I cherry pick that upstream commit and I can apply that commit separately and release a Debian version that has the fix even before upstream has made a release with the fix. So one nice thing about having upstream revision is that I can actually basically pull fixes from upstream before they've decided to release it. The other advantage is the other way around. Often when I'm doing packaging I'll discover a problem and maybe I can fix the problem and in fact maybe I'm already shipping a Debian package that fixes the problem. Well, if my Debian fixes can be directly applied to upstream then I can use whatever their preferred upstream patch submission guidelines are whether it's a GitHub pull request or a patch to a mailing list or a hey can you pull this from my Git repo over here, email, the fact that I'm using the same Git history that they're using makes it much easier for me to push my changes back to them. So it sort of smooths the interaction if you can consolidate and use the same revision control system as they are. Towards that aim I use the system now called Patch Queue which is part of Git build package. So Git build package is GBP, Patch Queue is PQ. So to execute, to deal with a Patch Queue you say GBP space PQ and then you have some commands and what that does is it takes, so how many of you are Debian packages, how many of you package software for Debian? A very large percentage, but not everyone. Hopefully some folks are considering starting packaging who haven't done it yet. So of those of you who package software how many of you package software with modifications? How many of you ship a modified version of the upstream sources beyond the Debian directory just Debian patches? Right, so the common way to do that for the Debian 3.0 quilt packaging scheme is that in your Debian directory you have a patches subdirectory that has a set of individual patches that apply certain changes and they're applied in order based on the file called Debian patches series. So maintaining that is kind of a drag when upstream makes big changes and then all of a sudden you've got this set of patches and they don't quite apply. It's a drag even if you don't have it in the Debian patches directory. But what Debian patch queue does is it maps that directory of patches into a little branch on your Git revision history. And so when you get a new upstream version you can say patch queue rebase and it treats it just as Git, it takes the patch queue and you've already imported it the new version and it reapplies your patches and sometimes that means some minor adjustments gets really good at figuring out what the right minor adjustments are to make and so all of a sudden the patch queue is rebased and you refresh it in your revision control system. Thank you and there you go. So I like to use Git build package patch queue. Tagging, it was already brought up. Thank you for that. I like to tag everything that I release. I like to push that as soon as I can so that other people who are following my work can know where my releases come from. The reason that I like other people following my work is they can fix my bugs easier. So I make mistakes, everybody makes mistakes and it's really important to me that if someone catches one of my mistakes I can accept their feedback, their criticism, their improvements as easily as possible. I want a low barrier to entry for people to help me fix my problems. It's selfishness. So I try to patch it and publish these things so people can find it. I'm gonna rattle through some of these pretty fast because we're almost out of time. I like to put my repos someplace where other people can get to them. At the moment, I like to put them in collab mate. It has some problems, but it's better than not publishing your stuff and it's nice because it's sort of a public use. So I put stuff in collab mate. I like to standardize how my branches are named. So if I'm working on something that's got a stable version that's for Jesse, I'll name the branch Jesse because I'll probably be making changes, like I said when editing multiple branches of software. I try to push as frequently as I've made something that looks sensible. I do not feel obliged to push my commits to a public repository when I'm still experimenting. I actually really like to experiment and I also like to keep track of my experiments while I'm doing them. So I try to push when there's like a sensible set of changes and I try to get myself to a point where I can understand what I've done, even if it's wrong. If I can get myself to a conceptual point that where it's done, I will push my changes so other people can see what I'm working on and then work from there. It's okay to push something that's wrong as long as you push something that people can understand. When you make a git commit, if you're working with git, one of the things that helps me to think about for commit messages, people often think that commit message should say what change you made. I think that the git patch shows what change you've made and I think your commit message should say why you made the change. And that's what people really wanna read. And yeah, if you need to explain technically why the thing that you did maps to the conceptual thing that you wanted to do, then that's fine, include that in your commit message too, but it's really important to say why you made the change, not just like initialize variable to null. It's like, okay, well we can see that from the patch. What you're really saying is there was a crash if someone did X and we were avoiding that crash by setting this to null. So I like to send patches via mail so I try to configure git email which makes it really easy to just push patches back upstream. If I'm starting taking over a project that somebody else has passed on and they didn't use git, I will try to do historical imports. I'm happy to talk with people about how to do that. If you have questions, come find me. I like to keep my files nice and simple. There's a tool called wrap and sort, W-R-A-P dash A-N-D dash S-O-R-T that just sort of canonicalizes your files to make them look in a simple and sensible way. And it's nice because it means that everything is, sorry about that, that it does things like alphabetize your list of build-dependence and breaks them out one per line. And the nice thing about that is not, since you're using revision control, when you make a change to your build-dependence, the changes become very easy to see. Oh, they added one new package here. There's a single plus, one new dependency. They removed a build dependency so you can see that kind of thing. I like to use depth five to format Debian copyright to be machine readable. It's nice for people who are doing scans of the archive and trying to reason about what the patterns are in licensing and free software. And if I'm doing something really crazy that's gonna make a big change, I like to use a feature branch in revision control. So we've got one minute left. I wanna open it up for other questions. It's kind of rambling. You said you are using wrap and sort, which is nice. I learned that a config meta editor, CME, does the same job and in some parts, does a better job. It also enhances standard version if it doesn't fit or it makes a VCS fields, probably as I should be. So CME fix dpkg minus control, fix your control file. Okay, CME? CME. And what is it, in what package? The package is CME, in unstable CME. And Jesse, it's the config model. We're developing an unstable, that's okay. Okay, thank you. Other questions or suggestions or complaints? If you change the original source code and do some commits, how do you convert that into a series of quilt packages, patches? I use patch queue for that as well. So what I do is I say, I wanna move over to my patch queue view of the tree and then I make my changes and I make my commits and then I say gbppq export. So that's patch queue export and it takes the patch queue that I'm on and dumps it back into the Debian patches directory. So if you haven't used gbp patch queue, I recommend looking into it. It takes a little while to get used to and I still screw it up sometimes, but it makes it easy to fix your mistakes too. Last question. Do you think it's possible to make this patch queue branch pullable by upstream? It is, I don't actually think it's possible to make it directly pullable by upstream. I don't think upstream can cherry pick patches from it, but I don't see how to make it pullable. If someone else does, I'd be happy to learn. Yeah. Okay, this was before last and last. So my question is, do you have a recording of you using the tools that you've mentioned? A video recording will be great just to show a complete workflow? I don't have anything like that and I don't really know how to do that. If somebody wants to help me do that, I'm happy to do it. Okay, thanks. Let me, I'm gonna give one last plug. I know we're out of time here, sorry. This tool is called GitK. So this is an example, sorry, we should leave, but this is a way that I visualize my revision control system. We could do a whole other session about GitK. If you don't try to visualize your Git control system, you're missing out. So I recommend trying to find a way to visualize stuff, find one that works for you. Thanks for coming. Thank you.