9:59:59.000,9:59:59.000 Thank you very much. 9:59:59.000,9:59:59.000 Thanks everybody for coming,… 9:59:59.000,9:59:59.000 If you are packaging software and you want[br]me to work on with you, 9:59:59.000,9:59:59.000 this is how you can do that. 9:59:59.000,9:59:59.000 It is a very self-??? talk: 9:59:59.000,9:59:59.000 I just want to explain some of the things[br]that I like, 9:59:59.000,9:59:59.000 some practice that I prefer about Debian[br]packaging, 9:59:59.000,9:59:59.000 and I don't pretend this is any sort of[br]official, 9:59:59.000,9:59:59.000 permanent or final thing. 9:59:59.000,9:59:59.000 I just wanted to share some ideas that I[br]have about the way that I work with 9:59:59.000,9:59:59.000 packages, in the hope that maybe, hmm,[br]for two hopes: 9:59:59.000,9:59:59.000 One is that I hope that I can show you[br]something that you have not heard of, 9:59:59.000,9:59:59.000 or maybe you were doing differently, 9:59:59.000,9:59:59.000 or maybe you think it is the right think[br]to do and it is just nice to see somebody 9:59:59.000,9:59:59.000 somebody else doing it. 9:59:59.000,9:59:59.000 My second hope is that you can tell me[br]what I am doing wrong, 9:59:59.000,9:59:59.000 and you can help me learn and improve[br]on my own packaging techniques. 9:59:59.000,9:59:59.000 If you see something that I am proposing[br]up here, 9:59:59.000,9:59:59.000 and you think there is a problem with it,[br]I would like to hear about it too. 9:59:59.000,9:59:59.000 I just want to see more of the culture[br]within Debian, 9:59:59.000,9:59:59.000 of people who are doing packaging,[br]explaining what they are doing, 9:59:59.000,9:59:59.000 and so I thought I would just step up and[br]explain: 9:59:59.000,9:59:59.000 "Here is some of the practice that I do", 9:59:59.000,9:59:59.000 In the hope that other people will do the[br]same and explain what they are doing, 9:59:59.000,9:59:59.000 and maybe they can learn from me and[br]I can learn from them. 9:59:59.000,9:59:59.000 Without much further ????, I am just going[br]to dive into it. 9:59:59.000,9:59:59.000 If you have questions, I am perfectly[br]happy to be interrupted, 9:59:59.000,9:59:59.000 we have some folks with walking mics[br]in the crowd: 9:59:59.000,9:59:59.000 you can just raise your hand. 9:59:59.000,9:59:59.000 I you have got a question or an[br]interruption or whatever, 9:59:59.000,9:59:59.000 that is fine. 9:59:59.000,9:59:59.000 I ??? I got the whole 15 minutes,[br]I think there are 20 minutes, 9:59:59.000,9:59:59.000 I ??? the whole time, so there will be[br]also time for questions at the end 9:59:59.000,9:59:59.000 if you prefer. 9:59:59.000,9:59:59.000 But I do not mind being interrupted. 9:59:59.000,9:59:59.000 So, this is all on this web page here, 9:59:59.000,9:59:59.000 you could probably skip this talk and go[br]read the web page, 9:59:59.000,9:59:59.000 but then you would not have the nice[br]??? actions, 9:59:59.000,9:59:59.000 and it is easier to tell me that I am[br]wrong in person, 9:59:59.000,9:59:59.000 so I would like to have that happen. 9:59:59.000,9:59:59.000 I put this up on the Debian wiki, 9:59:59.000,9:59:59.000 because I want anyone to be able to find[br]it. 9:59:59.000,9:59:59.000 If you thing you have got some good ideas,[br]you should put it on the Debian Wiki too: 9:59:59.000,9:59:59.000 other people can take advantage of the[br]ideas that you have got. 9:59:59.000,9:59:59.000 First baseline is: I really like revision[br]control. 9:59:59.000,9:59:59.000 And I know that it makes me a certain[br]flavor on nerd, 9:59:59.000,9:59:59.000 but when we are working with things that[br]are as complicated as software packages, 9:59:59.000,9:59:59.000 hmmm, I think a lot of people don't get[br]that in Debian we are not just working on 9:59:59.000,9:59:59.000 one software package: 9:59:59.000,9:59:59.000 you are actually probably, if you are doing[br]a responsibly work, 9:59:59.000,9:59:59.000 on at least two software packages, and[br]maybe 5. 9:59:59.000,9:59:59.000 So you have got the version that is[br]unstable and you have got 9:59:59.000,9:59:59.000 the version that you try to maintain for[br]stable as well. 9:59:59.000,9:59:59.000 And we are committing to doing maintenance[br]work. 9:59:59.000,9:59:59.000 A lot of our work in the project is ???[br]in nature: 9:59:59.000,9:59:59.000 we want to clean up the mess and we want[br]us to stay out of the way and 9:59:59.000,9:59:59.000 to make sure things work, functionally,[br] 9:59:59.000,9:59:59.000 for people who are relying on the[br]operating system to not get in their way. 9:59:59.000,9:59:59.000 So revision control I think is really[br]helpful because it means you can 9:59:59.000,9:59:59.000 keep track of what changes you have done[br]on different branches of the project 9:59:59.000,9:59:59.000 while you are maintaining both of them. 9:59:59.000,9:59:59.000 Basically, ??? require working with[br]the revision system I am comfortable with, 9:59:59.000,9:59:59.000 I prefer Git, I am not going to have a[br]religious word about it. 9:59:59.000,9:59:59.000 If upstream uses Git, I am even happier,[br]and I try to make my packaging depend on 9:59:59.000,9:59:59.000 upstream's revision control. 9:59:59.000,9:59:59.000 I like to use 'git-buildpackage', and I[br]like to use it with debhelper. 9:59:59.000,9:59:59.000 If you have not tried out[br]'git-buildpackage', 9:59:59.000,9:59:59.000 we are going to have a[br]'git-buildpackage' skill share session 9:59:59.000,9:59:59.000 later on today actually, and I welcome[br]you to come and share your tricks with it, 9:59:59.000,9:59:59.000 or learn some tricks from other people. 9:59:59.000,9:59:59.000 It is a particular way that you can keep[br]your Debian packaging in a Git repository, 9:59:59.000,9:59:59.000 and it helps you to keep track of all of[br]the changes that ave happened within 9:59:59.000,9:59:59.000 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 they