0:00:00.000,0:00:02.490 Thank you very much. 0:00:03.150,0:00:05.060 Thanks everybody for coming,… 0:00:08.666,0:00:12.186 If you are packaging software and you want[br]me to work on with you, 0:00:12.186,0:00:13.526 this is how you can do that. 0:00:13.526,0:00:15.156 It is a very self-??? talk: 0:00:15.156,0:00:18.516 I just want to explain some of the things[br]that I like, 0:00:18.516,0:00:21.366 some practice that I prefer about Debian[br]packaging, 0:00:21.366,0:00:25.236 and I don't pretend this is any sort of… 0:00:25.236,0:00:27.296 official, permanent or final thing. 0:00:27.296,0:00:30.456 I just wanted to share some ideas that I[br]have about the way that I work with 0:00:30.456,0:00:34.976 packages, in the hope that maybe, hmm,[br]for two hopes: 0:00:34.976,0:00:38.057 One is that I hope that I can show you[br]something that you have not heard of, 0:00:38.057,0:00:40.677 or maybe you were doing differently, 0:00:40.677,0:00:42.417 or maybe you think it is[br]the right think to do 0:00:42.417,0:00:43.877 and it is just nice to see[br]somebody else doing it. 0:00:43.877,0:00:47.047 My second hope is that you can tell me[br]what I am doing wrong, 0:00:47.047,0:00:51.047 and you can help me learn and improve[br]on my own packaging techniques. 0:00:51.047,0:00:52.907 If you see something that[br]I am proposing up here, 0:00:52.907,0:00:55.507 and you think there is a problem with it,[br]I would like to hear about it too. 0:00:55.507,0:00:58.227 I just want to see more of the culture[br]within Debian, 0:00:58.237,0:01:00.627 of people who are doing packaging,[br]explaining what they are doing, 0:01:00.627,0:01:02.787 and so I thought I would[br]just step up and explain: 0:01:02.787,0:01:04.497 "Here is some of the practice that I do", 0:01:04.497,0:01:08.717 In the hope that other people will do the[br]same and explain what they are doing, 0:01:08.717,0:01:12.207 and maybe they can learn from[br]me and I can learn from them. 0:01:12.207,0:01:16.917 Without much further ????, I am[br]just going to dive into it. 0:01:16.917,0:01:20.897 If you have questions, I am perfectly[br]happy to be interrupted, 0:01:20.897,0:01:24.187 we have some folks with walking mics[br]in the crowd: 0:01:24.187,0:01:26.687 you can just raise your hand. 0:01:26.687,0:01:29.247 If you have got a question or an[br]interruption or whatever, 0:01:29.247,0:01:30.347 that is fine. 0:01:30.347,0:01:33.037 I doubt I will go the whole 15 minutes,[br]I think there are 20 minutes, 0:01:33.037,0:01:35.177 I doubt I will go the whole time,[br]so there will be also 0:01:35.177,0:01:36.897 time for questions at[br]the end if you prefer. 0:01:36.897,0:01:38.697 But I do not mind being interrupted. 0:01:38.697,0:01:42.787 So, this is all on this web page here, 0:01:42.787,0:01:44.787 you could probably skip this talk and go[br]read the web page, 0:01:44.787,0:01:46.857 but then you would not have the nice[br]??? actions, 0:01:46.857,0:01:48.857 and it is easier to tell me that I am[br]wrong in person, 0:01:48.857,0:01:51.397 so I would like to have that happen. 0:01:51.397,0:01:53.447 I put this up on the Debian wiki, 0:01:53.447,0:01:56.237 because I want anyone[br]to be able to find it. 0:01:56.237,0:02:00.237 If you think you have got some good ideas,[br]you should put it on the Debian Wiki too: 0:02:00.237,0:02:05.007 other people can take advantage of the[br]ideas that you have got. 0:02:07.577,0:02:11.087 First baseline is:[br]I really like revision control. 0:02:11.097,0:02:14.267 And I know that it makes me[br]a certain flavor on nerd, 0:02:14.267,0:02:19.007 but when we are working with things that[br]are as complicated as software packages, 0:02:19.010,0:02:19.890 hmmm… 0:02:23.370,0:02:25.670 I think a lot of people don't get[br]that in Debian you are not 0:02:25.670,0:02:27.610 just working on one[br]software package: 0:02:27.610,0:02:30.120 you are actually probably, if you[br]are doing a responsibly work, 0:02:30.120,0:02:33.110 on at least two software packages,[br]and maybe 5. 0:02:33.110,0:02:35.150 So you have got the version that is[br]unstable, 0:02:35.150,0:02:39.260 and you have got the version that you[br]try to maintain for stable as well. 0:02:39.260,0:02:45.170 And we are committing to[br]doing maintenance work. 0:02:45.170,0:02:52.500 A lot of our work in the project is ???[br]in nature: 0:02:52.500,0:02:55.490 we want to clean up the mess and[br]we want us to stay out of the way 0:02:55.490,0:02:58.260 and make sure things work,[br]functionally, 0:02:58.260,0:03:01.340 for people who are relying on the[br]operating system to not get in their way. 0:03:01.340,0:03:04.110 So revision control I think is really[br]helpful because it means you can 0:03:04.110,0:03:07.670 keep track of what changes you have done[br]on different branches of the project 0:03:07.670,0:03:09.800 while you are maintaining both of them. 0:03:09.800,0:03:14.440 Basically, ??? require working with[br]the revision system I am comfortable with, 0:03:14.440,0:03:17.740 I prefer Git, I am not going to have a[br]religious word about it. 0:03:17.740,0:03:21.290 If upstream uses Git, I am[br]even happier, and I try to make 0:03:21.290,0:03:25.680 my packaging depend on[br]upstream's revision control. 0:03:29.342,0:03:34.812 I like to use 'git-buildpackage', and I[br]like to use it with debhelper. 0:03:34.812,0:03:36.793 If you have not tried out[br]'git-buildpackage', 0:03:36.793,0:03:39.883 we are going to have a[br]'git-buildpackage' skill share session 0:03:39.883,0:03:43.883 later on today actually, and I welcome[br]you to come and share your tricks with it, 0:03:43.883,0:03:46.293 or learn some tricks from other people. 0:03:46.293,0:03:50.483 It is a particular way that you can keep[br]your Debian packaging in a Git repository, 0:03:50.483,0:03:55.843 and it helps you to keep track of all of[br]the changes that have happened within 0:03:55.843,0:03:59.843 your packaging and within upstream to[br]make sure you are not accidentally 9:59:59.000,9:59:59.000 making other changes. 9:59:59.000,9:59:59.000 So it is very easy to go back and review[br]what you have done. 9:59:59.000,9:59:59.000 I find that really useful. 9:59:59.000,9:59:59.000 I definitely also like to keep upstream's[br]source code in the same revision control 9:59:59.000,9:59:59.000 system. 9:59:59.000,9:59:59.000 I like to keep the tarballs in the[br]revision control system because it means 9:59:59.000,9:59:59.000 that if someone is interested, they can[br]uses a tool called 'debcheckout'. 9:59:59.000,9:59:59.000 You can use 'debcheckout' with a name of[br]a package: 9:59:59.000,9:59:59.000 you say just "I am really interested in[br]package 'foo', 9:59:59.000,9:59:59.000 let me see the source code for that": 9:59:59.000,9:59:59.000 debcheckout foo 9:59:59.000,9:59:59.000 You get the source code, and you get the[br]source code from a revision control 9:59:59.000,9:59:59.000 system that you can now track and you[br]can just propose changes on. 9:59:59.000,9:59:59.000 You can also extract the tarball from that[br]revision control system. 9:59:59.000,9:59:59.000 'debcheckout' actually works even if you[br]do not have upstream stuff in there, 9:59:59.000,9:59:59.000 but I like to keep it all in one revision[br]control system, 9:59:59.000,9:59:59.000 it is just easier to find everything when[br]you want. 9:59:59.000,9:59:59.000 Some of these things that I prefer have[br]to do with what the upstream software 9:59:59.000,9:59:59.000 developer has done, so I am less inclined[br]to try the package an upstream software 9:59:59.000,9:59:59.000 project if they just throw tarballs here[br]over the wall to an FTP side 9:59:59.000,9:59:59.000 every now and then. 9:59:59.000,9:59:59.000 It makes it more difficult for me to know[br]what they are doing, 9:59:59.000,9:59:59.000 and why they are doing it. 9:59:59.000,9:59:59.000 So i like it, I have already said, when[br]upstream uses Git, 9:59:59.000,9:59:59.000 I also like when upstream signs their[br]releases, 9:59:59.000,9:59:59.000 and say "hey, this is specific release", 9:59:59.000,9:59:59.000 Because that is a signal that I can use,[br]or somebody else that understands the 9:59:59.000,9:59:59.000 project: as said "we think that this[br]something that other people can use", 9:59:59.000,9:59:59.000 or "this is a particular version we would[br]like other people to test". 9:59:59.000,9:59:59.000 There are a lot of other situations where[br]maybe it is not so important. 9:59:59.000,9:59:59.000 And having that be cryptographically[br]signed is really useful. 9:59:59.000,9:59:59.000 I care about cryptographic signature on[br]software because I want to know that 9:59:59.000,9:59:59.000 what I am running is related to the code[br]that somebody else out should be run. 9:59:59.000,9:59:59.000 And if you don't verify your software[br]cryptographically, anyone could 9:59:59.000,9:59:59.000 intercept the network connection[br]between you and that software, 9:59:59.000,9:59:59.000 and modify the software before it gets[br]to you. 9:59:59.000,9:59:59.000 And the cryptographic signature just says: 9:59:59.000,9:59:59.000 "look, this is a version that I am OK[br]with. I am putting it out there and 9:59:59.000,9:59:59.000 it comes from me". 9:59:59.000,9:59:59.000 And so I can have a trace back to that[br]point. 9:59:59.000,9:59:59.000 ??? just talk about briefly about how you[br]do cryptographic verification of upstream. 9:59:59.000,9:59:59.000 You might know upstream: you might know[br]them personally, you know their key 9:59:59.000,9:59:59.000 already, that is fine. 9:59:59.000,9:59:59.000 That is not the usual case: we work on[br]the Internet. 9:59:59.000,9:59:59.000 In the situation where your upstream is[br]signing their tarballs 9:59:59.000,9:59:59.000 and you have not met them, you do not[br]have to sign their key, 9:59:59.000,9:59:59.000 you do not have to say "I announce this[br]is their key". 9:59:59.000,9:59:59.000 This is probably the same one that is[br]signing every release, 9:59:59.000,9:59:59.000 so you should keep track of that. 9:59:59.000,9:59:59.000 Debian has a nice way to keep track of[br]that: 9:59:59.000,9:59:59.000 you can tell Debian how to find the new[br]version of the upstream tarball. 9:59:59.000,9:59:59.000 This is in the Debian 'watch' file. 9:59:59.000,9:59:59.000 If you type 'man uscan', you can learn[br]more about Debian 'watch', 9:59:59.000,9:59:59.000 and Debian 'watch' has now a feature that[br]lets you say 9:59:59.000,9:59:59.000 "that is not only this way you find the[br]tarball, 9:59:59.000,9:59:59.000 but upstream publishes signatures[br]and the signatures look like this". 9:59:59.000,9:59:59.000 You know, they got a '.sig' at the end. 9:59:59.000,9:59:59.000 So there is a particular arcane way to[br]specify that, but if you specify that, 9:59:59.000,9:59:59.000 then 'uscan' can find not only the[br]upstream tarball but can find the 9:59:59.000,9:59:59.000 upstream signature and, if you drop[br]upstream's signing key - 9:59:59.000,9:59:59.000 which of course I did not put on the wiki[br]page, someone should add it that and 9:59:59.000,9:59:59.000 fix it - you can put the upstream signing[br]key in 'debian/upstream/signing-key.asc'. 9:59:59.000,9:59:59.000 And then if you do that, when you say[br]'uscan', you can tell… 9:59:59.000,9:59:59.000 Maybe some people here do notk[br]now how to use 'uscan'. 9:59:59.000,9:59:59.000 'uscan' is a very simple tool,[br]you run it from a software package that 9:59:59.000,9:59:59.000 has a 'debian' directory, or even one[br]level up if you keep all of your software 9:59:59.000,9:59:59.000 packages in one folder. You can go one[br]level up and say 'uscan', and it will look 9:59:59.000,9:59:59.000 in all of the folder that are children[br]of it, and look for new version by 9:59:59.000,9:59:59.000 trying to find for new upstreams versions[br]in 'debian/watch'. 9:59:59.000,9:59:59.000 And if you have configured 'debian/watch'[br]properly, it can find the new upstream 9:59:59.000,9:59:59.000 signatures, and if you have got the[br]'upstream/signing-key.asc', then 9:59:59.000,9:59:59.000 it will actually verify the signature for[br]you as part of fetching the new 9:59:59.000,9:59:59.000 upstream tarball. 9:59:59.000,9:59:59.000 So you can get all of those things just[br]by setting ???? that way. 9:59:59.000,9:59:59.000 There is a hand up down there, could we[br]get the mic down to the hand ?[br] 9:59:59.000,9:59:59.000 Or to the person who has that hand, it is[br]not just a hand. [public laugh] 9:59:59.000,9:59:59.000 [someone] Publish a tarball and a hash, '.sha1',[br]and sign that hash, '.sha1.asc'. 9:59:59.000,9:59:59.000 Can 'uscan' cope with this and check the[br]signature on the hash and that the hash 9:59:59.000,9:59:59.000 belongs to that tarball ? 9:59:59.000,9:59:59.000 [Daniel] I do not believe that 'uscan' can[br]do that currently. So anybody out there 9:59:59.000,9:59:59.000 who wants to make things better for the[br]world should go hack on 'uscan': 9:59:59.000,9:59:59.000 that is a pretty straightforward thing[br]that we should fix because I agree 9:59:59.000,9:59:59.000 that is common pattern. 9:59:59.000,9:59:59.000 [someone] I have no answer to this[br]question by I have another question: 9:59:59.000,9:59:59.000 how do you convince upstreams who do[br]not release tarballs or who do 9:59:59.000,9:59:59.000 not set tags in Git ? 9:59:59.000,9:59:59.000 [Daniel] Who do not make tags in Git ? 9:59:59.000,9:59:59.000 [someone] Yes, if there is no tags you[br]can not check out a tarball. 9:59:59.000,9:59:59.000 Is there any good way to convince[br]upstream to do this ? 9:59:59.000,9:59:59.000 [Daniel] Git has this nice feature, which[br]is that you can create a tag, 9:59:59.000,9:59:59.000 which is associate with a particular[br]revision, 9:59:59.000,9:59:59.000 and you would like to have a tag[br]everywhere that a tarball has been 9:59:59.000,9:59:59.000 released from. I am tempted to pull up[br]a Git view and show people some tags. 9:59:59.000,9:59:59.000 The question that you ask is a social[br]one, not just a technical one, 9:59:59.000,9:59:59.000 and I actually find that my upstreams[br]are pretty responsive. 9:59:59.000,9:59:59.000 Usually I frame my request as "hey, it[br]looks like you made this tarball from 9:59:59.000,9:59:59.000 this particular commit 'id'. If you could[br]tag you releases, it would be really 9:59:59.000,9:59:59.000 helpful to me, and here is the command[br]that I would use to tag the release". 9:59:59.000,9:59:59.000 And I say "git tag…" and of course I[br]can never remember so first I look it up, 9:59:59.000,9:59:59.000 but it is either 'tag name' 'commit id' or[br]'commit id' 'tag name'. 9:59:59.000,9:59:59.000 But I would look it up and I would write[br]the e-mail so that all they have to do is 9:59:59.000,9:59:59.000 they read it, understand my argument,[br]and execute one command. 9:59:59.000,9:59:59.000 And then it starts them ?????? 9:59:59.000,9:59:59.000 And if you say 'tag -s' then your tag will[br]be cryptographically signed, which 9:59:59.000,9:59:59.000 I think is a really good thing to do too. 9:59:59.000,9:59:59.000 So, cryptographic verification of[br]upstream. 9:59:59.000,9:59:59.000 As I said, I want to keep upstream's code[br]in the revision control system. 9:59:59.000,9:59:59.000 I also like to keep… 9:59:59.000,9:59:59.000 In my ideal case upstream is using Git:[br]I am using Git for packaging. 9:59:59.000,9:59:59.000 I actually like to keep upsteam's Git[br]history fully in my repository, 9:59:59.000,9:59:59.000 so that I do not just have the tarballs,[br]but I actually have all of their commits. 9:59:59.000,9:59:59.000 And that turns out to be really useful[br]for two specific cases: 9:59:59.000,9:59:59.000 In one case, there is a common scenario[br]where upstream will fix a bug, 9:59:59.000,9:59:59.000 but they have not made a release yet. 9:59:59.000,9:59:59.000 And that bug is really, really obviously[br]problematic for the folks who are 9:59:59.000,9:59:59.000 using Debian, so want to fix it. 9:59:59.000,9:59:59.000 All I can do, because I have their full[br]revision history, I can use Git to "cherry 9:59:59.000,9:59:59.000 pick" the upstream commit. 9:59:59.000,9:59:59.000 And then I "cherry pick" that upstream[br]commit and I can have it applied 9:59:59.000,9:59:59.000 separately and release an Debian version[br]that has the fix, even before upstream 9:59:59.000,9:59:59.000 has made a release with the fix. 9:59:59.000,9:59:59.000 So one nice thing about having upstream[br]revision is that I can pull fixes from 9:59:59.000,9:59:59.000 upstream before they decided[br]to release it. 9:59:59.000,9:59:59.000 The other advantage is the other[br]way around. 9:59:59.000,9:59:59.000 Often when I am doing packaging,[br]I discover a problem, 9:59:59.000,9:59:59.000 and maybe I can fix the problem. 9:59:59.000,9:59:59.000 And if that maybe I am already shipping[br]a Debian package that fixes the problem. 9:59:59.000,9:59:59.000 If my Debian fixes can be directly applied[br]to upstream, then I can use whatever 9:59:59.000,9:59:59.000 their preferred upstream patch[br]submission guidelines are, 9:59:59.000,9:59:59.000 whether it is a Github pull request, or[br]a patch to a mailing list, 9:59:59.000,9:59:59.000 or a "hey can you pull this from my Git[br]repository over here", e-mail… 9:59:59.000,9:59:59.000 The fact that I am using the same Git[br]history that they are using makes it 9:59:59.000,9:59:59.000 much easier for me to push my changes[br]back to them. 9:59:59.000,9:59:59.000 So, it sort of smooth the interaction if[br]you can consolidate and use the same 9:59:59.000,9:59:59.000 revision control system as their. 9:59:59.000,9:59:59.000 Towards that aim, I use a system now[br]called 'patch q', 9:59:59.000,9:59:59.000 which is part of 'git buildpackage'. 9:59:59.000,9:59:59.000 So 'git buildpackage' is 'gbp', 'patch q'[br]is 'pq', 9:59:59.000,9:59:59.000 so to deal with 'patch q' you say[br]'gbp pq' 9:59:59.000,9:59:59.000 and then you have some commands. 9:59:59.000,9:59:59.000 And what that does, is it takes… 9:59:59.000,9:59:59.000 How many of you are Debian packagers ? 9:59:59.000,9:59:59.000 How many of you package[br]software for Debian ? 9:59:59.000,9:59:59.000 A very large percentage, but not everyone. 9:59:59.000,9:59:59.000 I hope some folks are considering starting[br]packaging if you have not done it yet. 9:59:59.000,9:59:59.000 Of those of you who package software,[br]how many of you package software 9:59:59.000,9:59:59.000 with modifications, how many of you ship[br]a modified version of upstream sources ? 9:59:59.000,9:59:59.000 Beyond the 'debian' directory, just Debian[br]patches ? 9:59:59.000,9:59:59.000 So the common way to do that, for the[br]Debian 3.0 ??? packaging skill, is that in 9:59:59.000,9:59:59.000 your 'debian' directory you have a[br]'patches' sub-directory that has a set of 9:59:59.000,9:59:59.000 individual patches that apply certain[br]changes, and they are applied in order 9:59:59.000,9:59:59.000 based on the file called[br]'debian/patches/series'. 9:59:59.000,9:59:59.000 So maintaining that is kind of a drag[br]when upstream makes big changes: 9:59:59.000,9:59:59.000 then all of sudden you have got this set[br]of patches and they do not quite apply… 9:59:59.000,9:59:59.000 I is a drag even you do not have it in[br]the 'debian/patches/' directory. 9:59:59.000,9:59:59.000 But what Debian 'patch q' does is it maps[br]that directory of patches into a little 9:59:59.000,9:59:59.000 branch on your Git revision history. 9:59:59.000,9:59:59.000 So when you get a new upstream version,[br]you can say 'patch q rebase', 9:59:59.000,9:59:59.000 and it treats it just as Git: it takes the[br]'patch q'… 9:59:59.000,9:59:59.000 You have already imported the new version,[br]and it re-applies your patches, 9:59:59.000,9:59:59.000 and sometimes that means some minor[br]adjustments. 9:59:59.000,9:59:59.000 Git is really good at figuring out what[br]the right minor adjustments are to make, 9:59:59.000,9:59:59.000 and so all of the sudden the 'patch q' is[br]re-based, you refresh it in your revision 9:59:59.000,9:59:59.000 control system, and there you go. 9:59:59.000,9:59:59.000 So I like to use 'git-buildpackage' 'patch q',[br]tagging, as already brought up, 9:59:59.000,9:59:59.000 thank you for that, I like to to tag[br]everything that I release, 9:59:59.000,9:59:59.000 I like to push that as soon as I can,[br]so that other people who are following 9:59:59.000,9:59:59.000 my work can now where my releases[br]come from. 9:59:59.000,9:59:59.000 The reason that I like other people[br]following my work is 9:59:59.000,9:59:59.000 they can fix my bugs easier. 9:59:59.000,9:59:59.000 I make mistakes, everybody makes mistakes,[br]and it is really important to me that 9:59:59.000,9:59:59.000 if someone catches one of my mistakes,[br]I can accept their feedback, 9:59:59.000,9:59:59.000 their criticism, their improvements,[br]as easily as possible. 9:59:59.000,9:59:59.000 I want a low barrier to entry for people[br]to help me fix my problems, 9:59:59.000,9:59:59.000 it is selfishness. So I try to patch it[br]and publish this things for people 9:59:59.000,9:59:59.000 can find it. 9:59:59.000,9:59:59.000 I am ??? on these pretty fast because[br]were are almost at the time.[br] 9:59:59.000,9:59:59.000 I like to put in some place where other[br]people get to the them, 9:59:59.000,9:59:59.000 at the moment I like to put them in[br]'collab-maint', 9:59:59.000,9:59:59.000 it has some problems but it is better[br]than not publishing your stuff, 9:59:59.000,9:59:59.000 and it is nice because it is sort of[br]a public use. 9:59:59.000,9:59:59.000 I like to standardize how of my branches[br]are named, so if I am working on 9:59:59.000,9:59:59.000 something that has got a stable version,[br]that is for Jessie, I will name the branch 9:59:59.000,9:59:59.000 'jessie', because I ??? 9:59:59.000,9:59:59.000 ???? multiple branches ??? 9:59:59.000,9:59:59.000 I try to push as frequently as I have made[br]something that looks sensible. 9:59:59.000,9:59:59.000 I do not feel obliged to push my commits[br]to a public repository when I am still 9:59:59.000,9:59:59.000 experimenting, I actually really like to[br]experiment, and I also like to keep track 9:59:59.000,9:59:59.000 of my experiments while I am doing them. 9:59:59.000,9:59:59.000 So I try to push when there is a sensible[br]set of changes, and I am trying to get 9:59:59.000,9:59:59.000 myself to a point where I can understand[br]what I have done, even if it wrong. 9:59:59.000,9:59:59.000 If I can get myself to a conceptual point[br]where it is done, I will push my changes 9:59:59.000,9:59:59.000 so other people can see what I am[br]working on, and then work from there. 9:59:59.000,9:59:59.000 That is OK to push something that is[br]wrong, 9:59:59.000,9:59:59.000 as long as you push something that[br]people can understand. 9:59:59.000,9:59:59.000 When you make a 'git commit' (if you are[br]working with Git), 9:59:59.000,9:59:59.000 One of the things that helps me to think[br]about commit messages… 9:59:59.000,9:59:59.000 People often think that commit messages[br]should say "what change you made". 9:59:59.000,9:59:59.000 I think that the 'git patch' shows what[br]change what change you have made, 9:59:59.000,9:59:59.000 and I thin your commit messages should[br]say "why you made the change". 9:59:59.000,9:59:59.000 That is what people really want to read. 9:59:59.000,9:59:59.000 If you need to explain technically why[br]the thing that you did 9:59:59.000,9:59:59.000 maps to the conceptual thing that you[br]wanted to do, that is fine: 9:59:59.000,9:59:59.000 do that in your commit message too.[br]But it is really important to say why 9:59:59.000,9:59:59.000 you made the change. It is not just like[br]"initialize variable to 'no'": 9:59:59.000,9:59:59.000 OK, we can see that from the patch,[br]but you what you are really saying 9:59:59.000,9:59:59.000 is "there was a crash if someone did 'x', 9:59:59.000,9:59:59.000 and we are avoiding that crash by[br]setting this to 'no'. 9:59:59.000,9:59:59.000 So I like to send patches via email, 9:59:59.000,9:59:59.000 so I try to configure Git email, which[br]make it really easy to just 9:59:59.000,9:59:59.000 push patches back upstream. 9:59:59.000,9:59:59.000 If I am starting taking over a project[br]that somebody else has past on, 9:59:59.000,9:59:59.000 and they did not use Git, I will try to[br]restore all of the imports. 9:59:59.000,9:59:59.000 I would be happy to talk with people[br]about how to do that, 9:59:59.000,9:59:59.000 if you have questions come find me. 9:59:59.000,9:59:59.000 I like to keep my files ???? simple:[br]there is a tool 'wrap-and-sort', 9:59:59.000,9:59:59.000 that just canonicalizes your files to[br]make them look in a simple and 9:59:59.000,9:59:59.000 sensible way. And it is nice because it[br]means that everything is… 9:59:59.000,9:59:59.000 It does things like alphabetize your[br]list of build depends, 9:59:59.000,9:59:59.000 and brake them out one per line.[br]The nice thing about that, 9:59:59.000,9:59:59.000 since you are using revision control,[br]when you make a change 9:59:59.000,9:59:59.000 to your build depends, the changes[br]become very easy to see: 9:59:59.000,9:59:59.000 "oh, they added one new package here,[br]there is a single '+'". 9:59:59.000,9:59:59.000 When ???? so you can see that kind of[br]thing. 9:59:59.000,9:59:59.000 I like to use ? deb five ? to format[br]Debian copyright to be machine readable, 9:59:59.000,9:59:59.000 it is nice for people who are doing scans[br]of the archive and try reason about 9:59:59.000,9:59:59.000 what the patterns are, and licensing of[br]free software. 9:59:59.000,9:59:59.000 And if I am doing something really crazy,[br]that is going to make a big change, 9:59:59.000,9:59:59.000 I like to use a feature branch in[br]revision control. 9:59:59.000,9:59:59.000 So we have got one minute left,[br]I want to open it up for other questions. 9:59:59.000,9:59:59.000 ???? 9:59:59.000,9:59:59.000 [attendee] You said you are using[br]'wrap-and-sort' which is nice, 9:59:59.000,9:59:59.000 I had learned that ???? editors[br]- 'cme' - do the same job, 9:59:59.000,9:59:59.000 and somehow does a better job:[br]it also ??? standard version 9:59:59.000,9:59:59.000 if it does not fit, or it makes VCS[br]fields properly has it should be. 9:59:59.000,9:59:59.000 'cme fix dpkg-control' fixes your[br]control file. 9:59:59.000,9:59:59.000 [Daniel] 'cme' ? And it is in[br]what package ? 9:59:59.000,9:59:59.000 [attendee] The package 'cme', in[br]unstable ????. In Jessie it is ???? 9:59:59.000,9:59:59.000 [Daniel] You are developing in unstable,[br]that is OK. 9:59:59.000,9:59:59.000 'cme'[br]OK, thank you. 9:59:59.000,9:59:59.000 Other questions or suggestions,[br]or complains ? 9:59:59.000,9:59:59.000 [attendee] If you change the original[br]source code, and do some commits, 9:59:59.000,9:59:59.000 how do you convert that into a series[br]of ??? patches ? 9:59:59.000,9:59:59.000 [Daniel] I use 'patch q' for that as well,[br]so what I do is I say 9:59:59.000,9:59:59.000 "I want to move over to my 'patch q'[br]view of the tree", 9:59:59.000,9:59:59.000 and then I make may changes, I make[br]my commits, 9:59:59.000,9:59:59.000 and then I say[br]'gbp pq export', 9:59:59.000,9:59:59.000 and it takes the 'patch q' that I am on[br]and dumps it back 9:59:59.000,9:59:59.000 into the Debian patches directory. 9:59:59.000,9:59:59.000 If you have not use 'gbp pq', I[br]recommend looking into it. 9:59:59.000,9:59:59.000 It takes a little while to get used to,[br]and I still screwed it up sometimes, 9:59:59.000,9:59:59.000 but it makes easy to fix your[br]mistakes too. 9:59:59.000,9:59:59.000 [organizer] Last question ? 9:59:59.000,9:59:59.000 [attendee] Do you think it is possible to[br]make this 'patch q' branch 9:59:59.000,9:59:59.000 "pullable" by upstream ? 9:59:59.000,9:59:59.000 [Daniel] I do not actually think it is[br]possible to make it directly 9:59:59.000,9:59:59.000 "pullable" by upstream: I think upstream[br]can cherry pick patches from it, 9:59:59.000,9:59:59.000 but I do not see how to[br]make it "pullable". 9:59:59.000,9:59:59.000 If someone else does, I would be[br]happy to learn. 9:59:59.000,9:59:59.000 [organizer] This was "before last",[br]so last. 9:59:59.000,9:59:59.000 [attendee] Do you have a recording of[br]you using the tools that you mentioned, 9:59:59.000,9:59:59.000 a video recording would be great,[br]just to show your workflow ? 9:59:59.000,9:59:59.000 [Daniel] I do not really know how[br]to do that: if somebody wants to 9:59:59.000,9:59:59.000 help me do that I would be[br]happy to do it. 9:59:59.000,9:59:59.000 I am going to give one last plug, 9:59:59.000,9:59:59.000 I know we are out of time here,[br]sorry. 9:59:59.000,9:59:59.000 This tool is called 'gitk'. 9:59:59.000,9:59:59.000 This is an example - sorry we[br]should leave - but this the way 9:59:59.000,9:59:59.000 that I visualize my revision[br]control system. 9:59:59.000,9:59:59.000 We could do a whole other session[br]about 'gitk'. 9:59:59.000,9:59:59.000 If you do not try to visualize your[br]revision control system, 9:59:59.000,9:59:59.000 you are missing out: try to find a way[br]to visualize stuff, 9:59:59.000,9:59:59.000 find one that works for you. 9:59:59.000,9:59:59.000 Thanks for coming. 9:59:59.000,9:59:59.000 [organizer] Thank you.