<> {{{#!IRC [19:02] Hi! Welcome to the class! Can we have a count of hands, please? [19:02] * asomething raises hand [19:02] * Rail waves [19:02] * weboide says 'me!' [19:03] This class is going to be about packaging and reviewing packages on the REVU site. [19:03] We will look at some uploads at the REVU site, developed and maintained by MOTUs... you are probably all familiar with it... http://revu.ubuntuwire.org/ [19:04] Reviewing other peoples packages is a great way to learn. First of all, you can learn new tricks and see how others solve problems. But you can also learn from mistakes, and via looking at many packages will familiarize you with the Ubuntu Policy Manual http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ which of course is the packager's bible :-) [19:05] That is a modified version of the Debian Policy Manual found here: http://www.debian.org/doc/debian-policy/ [19:05] Another good place to get information is the MOTU packaging guide: https://wiki.ubuntu.com/PackagingGuide [19:05] Any questions at this point? [19:06] OK let's get started. Let's go to REVU and select some package to look at. REVU allows everyone to leave comments, but you need to lock in with your Launchpad ID using the OpenID system. [19:06] Does everyone have a Launchpad ID? (Just checking :-)) [19:06] * Rail has [19:07] * weboide also [19:07] Cool. I thought we would combine this tutorial with the useful and let uploaders benefit by getting their packages reviewed. Therefore, we will leave our comments once we have reviewed the package(s). [19:08] Any suggestions for packages to look at? Perferably some that haven't been reviewed before [19:09] How about "gammapage" [19:09] The first thing I generally do before spending time on a package, is to check if it's already been uploaded to Debian, or if there's been an ITP bug filed. That indicates that someone else might be working on the package, in which case there might be a conflict of interest and/or a duplicate effort == waste of someones time. [19:09] sure [19:09] So let's look for gammapage here: http://ftp-master.debian.org/new.html and http://www.de.debian.org/devel/wnpp/being_packaged and just do a search for the package name in the browser. [19:10] What's the verdict? [19:10] not in debian ;) [19:10] Right [19:11] The next thing I do is to du a cursory check if this software can be distributed at all. Otherwise, there's no need spending time on it. We absolutely need a file -- normally called COPYING -- that grants Ubuntu permission to distribute the software. So let's browse down REVU's html pages into the directory and see if this permission is present. [19:11] (Select the LATEST upload of gammapage) [19:12] This one looks ok! [19:12] Question: Do every src files need a license header also? What if they don't? [19:13] Answer: Ideally, yes. [19:14] It's something that the packager might negotiate with upstream about [19:14] The argument is, if someone lifts a file and uses it in another project, it will not contain information of where it came from, who wrote it and what the copyright is [19:14] OK, let's move on [19:14] My next step is generally to download the package. I find the link to the relevant .dsc file, right click -> copy the link. Then I move into a terminal, and type "dget -ux " + right-click -> paste. [19:15] I usually do this in /tmp :-) [19:16] A bit about what has been downloaded to your machine: A source package is mainly composed of the pristine tarball and a diff.gz file containing the work of the packager. While it is possible for the diff.gz file to patch everything in the source tree, the current paradigm is that nothing outside the debian/ directory must be touched. [19:17] So, now let's check to see that nothing else is in the .diff.gz file: [19:17] lsdiff -z .diff.gz [19:17] Is everyone with me at this point? [19:18] * Rail is [19:18] * weboide is too [19:18] * tuantub :D [19:18] What's the situation with gammapage_0.5.1-0ubuntu1.diff.gz ? [19:18] looks like there are some direct changes to the source in the diff.gz [19:18] It does indeed [19:21] diffstat says 1418 insertions into gammapage file. Big change. [19:21] Can you see what's going on? [19:21] Exactly. Looks like the file gammapage is not in the tarball [19:22] actually the file was renamed [19:22] yeah, filename is gammapage-0.5.1/GAMMApage [19:22] mv GAMMApage gammapage [19:22] Well copied [19:23] Do we like this way of doing things? [19:23] symlink would be better at least [19:23] nope, better patch in debian/ [19:23] loic-m: yes [19:23] it would be better to do it in debian/rules i'd think, no patch needed [19:24] And the question is if the app should be renamed at all [19:24] indeed, we'd get a different command than other distros [19:24] There's not anything in policy saying that we can't have caps in application names [19:25] what is when we use dpatch insteed ? [19:25] So this is something we need to tell the uploader. [19:25] tuantub: Hm, it's not worth adding a patch system to do something as simple as that. [19:26] If we _must_ rename it, better do it in debian/rules [19:26] But I would choose to let upstream decide how the name of the app should be spelled [19:27] Now we can focus attention on the files debian/ -- we won't allow anything else to be modified by the packager in a new package. [19:27] setup.py is a special case perhaps :-) [19:27] mok0: so far i know, we'd better use dpatch than touching the source :-/ [19:28] tuantub: that's true, but sometimes it's a pain to patch files used by the build [19:29] mok0: i think we can tell the rules to patch before building ? [19:29] tuantub: we can [19:29] the diff in setup.py is only about the renaming. if they drop the rename, they don't need it [19:30] asomething: right [19:30] So that problem goes away [19:30] * tuantub :) [19:30] moving the file after "python setup.py install..." is the solution [19:30] Rail: yes [19:31] Rail: But I think it is wrong to rename the app, actually. As loic-m said, the app might have the original name in other distros [19:31] I generally write my review in a local file and paste it into the browser later. I have one-too-many times experienced that the browser quits on me... and a lengthy review has been lost! [19:31] Do we have a volunteer to write down the review, and post it later? [19:32] ok, if you want to rename it, moving is better than patch [19:32] Rail: yes [19:32] Question: must we build the packages on the newest release of ubuntu ? [19:32] * asomething will post the review [19:32] asomething, thanks. [19:33] tuantub: Generally, yes [19:33] tuantub: but if you don't have a karmic builder, never mind for now [19:33] Next we do a cursory check of the files in debian/. We need at least five files to be present there: control, changelog, copyright, config and rules. Otherwise, the package won't build! [19:33] The the de-facto requirement is to have a debian/watch file also. I require it when advocating :-) ... the exception being when upstream's sources are only available from a VCS. [19:35] hmm, lintian file is 0 bytes, but I can see at least one warning regarding standards-version... [19:35] on debian.mentors most sponsors require an empty watch file commenting why one can't be used [19:35] /see/predict/ [19:35] Right. The current version is 3.8.1 [19:35] mok0: debian/config ? [19:36] Rail: I find running "lintian -iI --pedantic" more useful [19:36] tuantub: it's set to 5, which is ok IMO... if you don't require anything from the later versions of debhelper [19:36] mok0: did you mean compat ? [19:37] tuantub: yes, sorry [19:37] mok0: ;) [19:37] asomething: a'm talking about the lintian output on the revu site [19:38] Rail: package was uploaded when version vas still 3.8.0, no? [19:38] s/vas/was/ [19:38] ah, yes [19:38] Rail: REVU probably only runs it at the up load time [19:38] loic-m: yes, but it needs to be updated for karmic now [19:39] Running lintian with the -I switch gives some points to discus [19:39] s [19:40] Generally, for packages in REVU, I like them to be completely clean [19:40] mol0: OTOH, I'm not sure it's so great when contibutors who didn't get any review in 6 month (or more) get a sudden review with only "You should target karmic" (when the upload was good at the time) [19:40] Build-Depends-Indep should be used [19:41] loic-m: no :-) [19:41] (sorry, I've got gloves today ;) ) [19:41] loic-m: but it should be on the list of things to do [19:41] The lintian report sometimes gives a convenient outset for some comments in the review. But copy-pasting the lintian report is not a good idea. When reviewing, your role is that of a teacher and mentor. You need to communicate the problems in a clear way, and perhaps give hints at solutions. You must be helpful and friendly in your comments, but don't take over the packaging! The uploader must do the work. [19:41] loic-m: sure if that's the only comment [19:42] What about debian/rules? [19:42] mok0: what if an uploader doesn't answer neither review or emails for month but you'd like to get the package in Ubuntu? [19:43] loic-m: let's discuss that after class :-) [19:43] mok0: ok [19:43] i'd prefer to use cdbs to avoid copy/paste in debian/rules :) [19:43] well something is amiss, it's FTBFS in a pbuilder (sorry, if that's getting ahead). [19:44] Rail: well, that's the choice of the packager [19:45] debian/rules contains boilerplate comments at the top, they must go [19:45] Otherwise, it's nice and clean, good work [19:45] http://paste.ubuntu.com/177375/ [19:46] asomething: yes the building is not working [19:46] mok0: do you know where we can find more information about each dh_ call? (besides man page) [19:46] And it's because of debian/rules [19:46] And it's because of debian/control sorry [19:46] i'd add a blank line between install: and binary-indep: :) [19:47] stefanlsd: no, it's badly missing. I've looked at the source once in a while [19:47] stefanlsd: vi =dh_whatever ;) [19:47] Rail: me too, but it doesn't matter [19:48] +1 [19:48] This is a python package, so we should use python_central [19:48] ... or rather the uploader should fix it. [19:49] We can leave a URL in the comment: http://wiki.debian.org/DebianPython/NewPolicy [19:49] http://python-modules.alioth.debian.org/python-central_howto.txt [19:50] ... and we need a "XS-Python-Version:" field in debian/control [19:50] stefanlsd: thx [19:50] The package also needs a watch file [19:51] asomething: are you up to speed with the review? You might pastebin it and we can take a look [19:52] mok0: sorry, I was just going to go back into the log and write it when we were done [19:52] asomething: ah ok [19:53] After looking at the files in debian/ I usually do a build [19:53] It is absolutely recommended that you use a pbuilder , cowbuilder og sbuilder for that [19:55] (pbuilder-dist is the easiest, IMHO) [19:55] It is [19:56] Hm. I'm a bit puzzled at the dh_testroot error [19:57] Well, if you remove it from the clean: target, it builds [19:58] * tuantub_ :D [20:00] Now finally, any comments about the description field in debian/control? [20:01] the short description isn't very meaningful? ... and the long description ain't very long :-) true * Rafik has quit (Read error: 104 (Connection reset by peer)) The uploader has written a manpage, which I usually thank them for especially. But this one is very short as well A man page should say HOW the program is to be used, not only WHAT it does It should describe what it does while it's working. Will it change the gamma of the monitor live, and let you decide when you like it? Will it show some number and let you choose it? Will it fry my monitor? So while it's good that uploaders write a manpage, it should be a _good_ manpage also So, at this point, I think we have enough for a lengthy review... Alright. Here's what I have so far. Anything missing? http://paste.ubuntu.com/177390/ asomething: that is very good! * theru (n=kim@0x5552c2fe.adsl.cybercity.dk) has left #ubuntu-classroom asomething: also tell him to remove the boilerplate comment in debian/rules (at the top) mok0: will do! no Vcs-* in debian/control, must be :) asomething: and maybe also a more meaningful short-description right, leave this link: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis Well, perhaps it's time to end the lesson. Any questions? * k0001 (n=k0001@host1.190-30-3.telecom.net.ar) has joined #ubuntu-classroom mok0: thanks! mok0: thanks ;) Is it required to package the lastest version of the software for the package to get included into ubuntu? mok0: tahnk you very much thanks mok0 thanks for the lesson mok0 My pleasure! Thanks for coming along! Now for the question we postponed * mok0 searches scrollback gotta go now, thank you again mok0 , see you all! hm can't locate it * weboide has quit ("Yeeehaaaa!") Ah what if an uploader doesn't answer neither review or emails for month but you'd like to get the package in Ubuntu? If the uploader doesn't reply in a reasonable time, you are free to take over the package Anyone can make a new upload * eitreach has quit ("Ex-Chat") In fact, I'd like to encourage everyone to grab packages from REVU that are idling, because MOTUs and others have already spent time reviewing them * joaopinto (n=janito@85.138.171.34) has joined #ubuntu-classroom mok0: in that case, the one making the new upload can just either grab the old upload and improve it, or do it from scratch. Is there a copyright problem doing the first? loic-m: No loic-m: usually the packager has used a free software license for the packaging loic-m: I think it's fair to continue the work on the uploaded package * tuantub_ is now known as tuantub If the uploader is MIA the package is fair game mok0: ok, thanks. And if no license is made for the packaging, it's still ok (I guess the copyright problem might only occur for man pages, since they're shipped, no)? loic-m: if the previous uploader has written a manpage, you should maintain his/her name on the copyright, and add your own if you make additions and changes ok loic-m: it's also about giving credit where it's due indeed otoh, uploaders are also making use of a service where they get (free) reviews * tuantub has quit ("Lost terminal") so if they loose interest, it's only fair that someone else can take over many packages in "needs work" are in pretty good shape, they just need someone to push it along }}} ---- CategoryPackaging