 OK, hello. I once wanted to become a teacher, so I'm using the blackboard now. No, it's because it's a talk about git, and normally you will have to make many drawings to explain things. And I was rushed too lazy to make the drawing on the computer, and I know graphics, but I don't know how to do this. It's about packaging software for Debian in my case, but I hope that it's also useful for other distributions, and especially for cooperation between distributions. It's about git and tool tools on top of git, but the ideas should be usable also for material, bazaar, or other distributed version control systems. OK, I've done Debian packages. Now for something around a year, and try to become a Debian developer once, working for a small web company in Eastern Switzerland. And at this company, we are using Debian packages for deployment. So if we want to deploy a web application, put it in a Debian package, up get installed, and it's up there, and every web developer in-house can also make up get installed on his developer machine and has it running. I'm interested in, who are you? What's your experience? Who has ever used git or is actively using git? Fine. Other distributed version control systems? So everybody is familiar with distributed version control. That's fine. Who's done Debian packages? About half of you. Or for other distributions, RPMs. Also very fine, so I don't. And top git, anybody has used top git? OK, I'll talk about it. So you know, about packaging only, what you do is, you have the source table of the upstream software. You download it, unpack it, and put the Debian folder inside. And there's also magic, which builds the package and has all the meta information for Debian. And eventually, you have to patch the upstream code also. And that's what you are doing for packaging. So we have three things now. We have upstream table. We have the unpacked upstream. And we have Debian slash. It would be best to track all these three things. And it's also good to have all these three things in the version control system. I'd like to have the table in my version control system so that everybody else working on this package doesn't need to go to the upstream home page, find the table. Even if I have a new scan, the automated system for Debian, which downloads the table, there's always a chance that the site is down right now. Or I've also encountered upstreams who distribute or release another source table with the same version number. And you have no way to know that you have got another upstream table now than the other developer. So it's a good idea to have it available. Repository, you have a backup of it. And if you are offline, you can still work on. You make a git clone of the packaging repository when you're online and can still work with it when you're offline. You have the table available. The unpacked are upstream. There are packaging groups in Debian, for example, Java, which use subversion. And most of the time, they have only the Debian directory in the subversion. And when I want to work on a package, I have make targets, get auric, or something like that. And this goes to the home page downloads upstream. And for Java packages, normally you have to repackage because they have binary things inside. That's the repackaging. And makes this every time somebody else wants to work on the package. And of course, this could go wrong. It would be fine to have a canonical upstream in my repository so that I know that somebody else working on this package has bytes to byte identical to the upstream directory. So the upstream tarball, how can I part it in my repository? I could, of course, commit the tarball as it as one file, but that would be a waste of space. And it doesn't really help me much, because if I want to inspect it, I have to go to this commit, get find the file. There is a nicer tool for it than this. I write the tools down here. It's pristine tar, who did it? Joy has, yeah, deviant developer. So the magic of pristine tar is that you unpack the tarball, commit everything what's in the tarball to one branch, and then tell pristine tar, OK, look at this branch. There you have all the files. And now I want you to save all the other meta informations that are also in the tarball, but could not be represented in this branch. Part of this meta information somewhere, and when I ask you, you will get me back the original tarball, byte as byte as it was. But I do not commit the tarball. I do commit the files inside the tarball and some additional informations. I think permissions, timestamps, some informations that could not be represented well in the Git repository. And pristine tarball makes a separate branch in the Git repository, also called pristine tar. And it makes for each tarball, I commit there is one file with all the meta informations that pristine tar will need to recreate my tarball. I have now three branches. I call this branch where I put the unpacked upspin source. Upspin. There is this pristine bra, pristine tar branch, branch. The meta informations normally I don't access it directly, but only with pristine tar. And by convention, the devianization branch with the devian directory is called the master branch. OK, and that's a drawing I wanted to make. I start my new repository. And first I start with the upstream branch. Commits, oh, here's the upstream branch. Make a tag with a version number called upstream slash 0.1 is the upstream version of the software. And here, there are all the files from the tarball. And from this, I make a branch and call this my master branch where I put my devian directory and do all the devianization. Now when the next upstream version comes, I do another commit here with a new upstream tarball and do a merge in my master branch, in my devianization branch. And in the most ideal case, I only need to update the change log here in the devian directory and could make another upload. And the nice thing is also, now I can use all the tool chain of Git to inspect the differences between the two upstream tarballs. I have the differences also available on my master branch. And here, I also have the devianization commits. There is another tool which can use this commits on devian to create change log entries so that when committing, I already write what will end up in the change log. So for this thing, there's also a tool that helps me with it. This is git build package. And git build package is as well the name of the tool and the name of the tool set. The tool git build package uses this repository now to build the devian source package, which I will upload. So git build package codes pristine tar, give me the auric tar gzet tarball, which I need to upload to devian. Then it creates the defy between the upstream branch and the master branch, which by convention should only contain the devian directory. And it runs, of course, the devian tool chain with all the devian tools which build packages and work on the devian directory. So with the help of git build package and this standard layout of a repository, I could now collaborate, for example, with my sponsor. And instead of uploading source packages somewhere on my server or on mentostevian.org, I can just point him to my git repository and look there. Everything is inside. There is the tarball. You just want git build package hyphen s to build the source package, and you are done. And this way, he not only has the source package, but also the history. And he can also make commits. So when he wants to correct something on my package, just make a commit, send it back to me as in distributed version control. And so the other tool, another tool from the git build package suite, all right. So that's the tool which I fire up when a new or the first upstream version comes. Git import already unpacks the upstream tarball, commits the content to the upstream branch, makes another tag at the upstream branch with the version number's name, and commits the tarball with pristine tar, and makes this merge to the dbm branch. I can continue to work. There is a nice feature which helps a lot for Java packages, for example. With Java, you have every time a lib directory containing the Java files of all the dependencies. That's a custom in the Java world, and it's hard to teach upstream not to do it, or to distribute a pure source tarball, only containing source files, and not containing binary or pre-compiled stuff. So every time I need to repackage my upstream, so what I do is I make a normal git import oric without any repackaging, and have the original tarball here. And immediately afterwards I make another import, but this time I use the filter option of git import oric, and tells it filter out all Java files, but filter out the docs directory because it's pre-compiled, filter out compiled generated source code, and I make, and I tell, here at the first commit, I tell git import oric, don't do the merge to master this time, just make the commit. I make another commit 0.1 plus gfsg1, indicating that it's a repackaged tarball, and this is then merged to master. So I have not only the repackaged filter's tarball for reference, I also have the upstream tarball. And if I like, I also have a diff between these two so that I can just look up, what did I filter out? Yeah, for example, this filtered tarball, it's also a work to go through a big project and find all the pre-compiled files. If there's C stuff inside, there are cache, automate stuff files. And so I end up to repackage dfsg2 and 3 and 4, have all these, and this work could also be used by other distributions by Fedor and just take the tarball from the git repository. So next tool in the git build package tool chain, I already mentioned, is git's debian changelog helper, which this just takes, this commits here, and generates a changelog file, a debian slash changelog file of it. You may have seen packages wherein the changelog very nicely is indicated. Author in square brackets, some commits. Next author, square brackets. And this is normally done with git dch. OK, that's until now. That's nice packaging, nothing so complicated. Now we have packages where we need to patch upstream. And that's where Topgit comes into. Topgit is created by a Czech guy who also runs repo.crcz, Petra for these, a git contributor. And what Topgit does, it saves in every branch. No, one step more. Topgit manages patches in the form of branches. Every patch is represented in a git branch. And these git branches are in some kind special, because they have two additional files. The first file in these branches is topdecks. Topdecks is just a plain text file with the names of all branches this branch depends on. So normally, if I base my patch directly on upstream, this would just be. But if I have a patch which depends on another patch, there would be in the topdecks file the name of the branch representing the dependency patch. Or I could say there are three patches that need to be applied first before this can be applied. And there are three lines with branch names. And so Topgit can apply an algorithm to look up. Well, my patch branch is based on upstream. And it looks in the history. Upstream, when I made the branch from upstream, upstream was at commit ABC. Now upstream is at commit DCH. So something happened at upstream, which is not merged back in the patch branch. My patch isn't current anymore, isn't actual anymore. It needs to be updated. So I can see with Topgit summary, it gives me a list of all the patches and tells me which patch has dependency branches whose changes are not yet merged in the patch. And this comes in very handy when I have a set of 10, 20, 30 patches against upstream. A new upstream version comes. And I need to update all these 30 patches. And so I don't miss any patch. And it tells me, and I can use the Git commands to do all the merging work. And I think Git is very good at that to help me with merging. Another nice thing of Topgit is it eases the collaboration with upstream because there's another file, the second one, top message where I can write, like in an email, the name of the subject of a patch and a description. And with one command Topgit mail and patch name, I can just send this patch to an email address, presumably the address of the upstream mailing list. And Topgit will create an email from the subject and top message from the description and takes the patches as patch files and send it to the mailing list. So now to one step, how do I use the patches now in my deviant package? We have a new source format in deviant version 3, which allows me to use kills as a patch manager. And Topgit allows me to export all the patches in the same format as killed users. So there is TG Topgit export. I say which branches do I want to export because sometimes there are patches which are my repository but which I do not want to have in my package right now or which are outdated, not yet ready yet. I indicate which patches I want, give it a directory, and Topgit will write in this directory one patch file per patch branch and the series file that kills needs to apply all the patches. And this is compatible to the new deviant source format. So I can just use it as it. OK. All this stuff here is now my personal workflow to do packages. But there are many others with slight modification. There are people who base their patches on the master branch, for example, or make a third branch to merge all the patches in one branch and merge this branch into the master branch and for this reason and for other reasons, there is a web page, vcs-package.org, which was started by Martin Croft, also a deviant developer, and his idea is that distributions should collaborate more and use, at best, one distributed version control system and share patches from one distribution to another distribution and make it easier this way to do all the work with packaging. And on this page and the mailing list of this page, there are discussions on how this could be achieved because this stuff is still fairly new and there is no canonical workflow now which is recommended as best practice. Therefore, my aim now with this talk is to get you a little bit curious about the topic of sharing version control with distributions and of using a distributed version control, especially Git, to do packaging. I've seen most of you already use distributed version control, so the same is already reached. The next step would then be to just check out TopGit, see what it can, try the workflow, see if it works out even with up streams, even if I have to maintain two different versions and to maintain patches against two different versions because one version is in old stable, the other one is in stable, the next is in testing. So that we could come up in the next year with a workflow which is tested, tried, works, simply to understand. Thank you. Questions? Yeah? Have you realized that version control system is feasible to use other version control systems like Bazaar or like Leporeal? Yeah, of course. This is also the aim of VCS package that the workflow should work with all the distributed version control systems because mostly all the distributed version control systems now share the same feature set. They all have branches. They all can merge easily. They all have text. So if the workflow works on Git, it should also work on Material or Bazaar. It's only that I know only Git and I know only of TopGit. But I don't know if there are similar tools for Material or Bazaar to manage patches in the form of branches. But that would be ideal if I could use also the tools that do merging between different systems so that I, as a Debian package, I use Git, but the Ubuntu guy uses Bazaar. But we could still share our commits. That would be ideal. The package dependency, please, sir, which ones are distribution specific and available to outfit? With naming conventions. So you name the branches that are distribution specific, for example, Debian slash patch name. Or if you have a feature that you have added and you want to be submitted upstream, the branches feature slash somewhat. If there is a bug fix that you want to share with upstream, bug slash. And that's only convention that some names indicate that's for Debian, some names that's for packaging. There is also still a need to come up with a set of common namespaces, which are understood by both. And how much of this convention that you showed us here today are already working, for example, between Debian and Ubuntu? How much of these things I've described are already in practice between different distributions? I don't know of any collaboration between distribution using such a system. I know that I'm using this workflow and that it works. But I don't know if there is any collaboration of it. It may be, but. I would have just taken that of the Debian and Ubuntu. That's something special. But I don't know exactly how it works. Ubuntu takes the source packages of Debian and either takes it as they are or patches them. They import everything in Bazaar. Ubuntu is managed with Bazaar. And they also submit patches back, but not with the help of version control, with the help of backtracker, page files, mailing list. My distribution is based on Ubuntu, we've worked up and then we can't use or we don't like using Bazaar and watch it and I don't want construction. We haven't implemented git build package on our side. We absolutely love it. But in essence, what we've done is we've forked your Debian branch into our own branch. So now we've got two different ones, upstream Debian and R branch. What's your distribution? Sorry? What's your distribution? Jolli-club. Jolli-club? Jolli-club? Okay. Thank you. Basically, the different packages that we've modified with 200-some-odd plus, we've included the git build package and made some modifications to git DTH, et cetera, and working fairly well. But one issue that we've had is with the whole Debian packages infrastructure that Ubuntu tends to use. Is there any way of importing Debian packages? So they actually here as git connects, which will make it easier for me to manage, I guess, and then subsequently convert them back. Obviously, we can convert them back with the top-kit, but is there any way of bringing them in? Of course, somebody could write such a tool and could run it over the Debian packages, but there isn't yet. You probably agree that git build package makes the legacy Debian package infrastructure redundant. Yeah. There's also a discussion, for example, to use git repositories directly instead of Debian source packages. There is even, I think there is, an implementation in DPKG source so that I can use git repositories directly, but this is still experimental, and as I recall when I discussed this, they said that the implementation of DPKG source is already obsolete because the discussion is already about some other format. But it's in the discussion, yeah. Would be fine. Okay.