Ubuntu Wiki

   1 [19:02] <mok0> Hi! Welcome to the class! Can we have a count of hands, please?
   2 [19:02]  * asomething raises hand
   3 [19:02]  * Rail waves
   4 [19:02]  * weboide says 'me!'
   5 [19:03] <mok0> This class is going to be about packaging and reviewing packages on the REVU site.
   6 [19:03] <mok0> 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/
   7 [19:04] <mok0> 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 :-)
   8 [19:05] <mok0> That is a modified version of the Debian Policy Manual found here: http://www.debian.org/doc/debian-policy/
   9 [19:05] <mok0> Another good place to get information is the MOTU packaging guide: https://wiki.ubuntu.com/PackagingGuide
  10 [19:05] <mok0> Any questions at this point?
  11 [19:06] <mok0> 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.
  12 [19:06] <mok0> Does everyone have a Launchpad ID? (Just checking :-))
  13 [19:06]  * Rail has
  14 [19:07]  * weboide also
  15 [19:07] <mok0> 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).
  16 [19:08] <mok0> Any suggestions for packages to look at? Perferably some that haven't been reviewed before
  17 [19:09] <mok0> How about "gammapage"
  18 [19:09] <mok0> 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 [19:09] <asomething> sure
  20 [19:09] <mok0> 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.
  21 [19:10] <mok0> What's the verdict?
  22 [19:10] <weboide> not in debian ;)
  23 [19:10] <mok0> Right
  24 [19:11] <mok0> 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.
  25 [19:11] <mok0> (Select the LATEST upload of gammapage)
  26 [19:12] <mok0> This one looks ok!
  27 [19:12] <weboide> Question: Do every src files need a license header also? What if they don't?
  28 [19:13] <mok0> Answer: Ideally, yes.
  29 [19:14] <mok0> It's something that the packager might negotiate with upstream about
  30 [19:14] <mok0> 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
  31 [19:14] <mok0> OK, let's move on
  32 [19:14] <mok0> 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.
  33 [19:15] <mok0> I usually do this in /tmp :-)
  34 [19:16] <mok0> 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.
  35 [19:17] <mok0> So, now let's check to see that nothing else is in the .diff.gz file:
  36 [19:17] <mok0> lsdiff -z <package>.diff.gz
  37 [19:17] <mok0> Is everyone with me at this point?
  38 [19:18]  * Rail is
  39 [19:18]  * weboide is too
  40 [19:18]  * tuantub :D
  41 [19:18] <mok0> What's the situation with gammapage_0.5.1-0ubuntu1.diff.gz ?
  42 [19:18] <asomething> looks like there are some direct changes to the source in the diff.gz
  43 [19:18] <mok0> It does indeed
  44 [19:21] <weboide> diffstat says 1418 insertions into gammapage file. Big change.
  45 [19:21] <mok0> Can you see what's going on?
  46 [19:21] <mok0> Exactly. Looks like the file gammapage is not in the tarball
  47 [19:22] <Rail> actually the file was renamed
  48 [19:22] <weboide> yeah, filename is gammapage-0.5.1/GAMMApage
  49 [19:22] <Rail> mv GAMMApage gammapage
  50 [19:22] <mok0> Well copied
  51 [19:23] <mok0> Do we like this way of doing things?
  52 [19:23] <Rail> symlink would be better at least
  53 [19:23] <loic-m> nope, better patch in debian/
  54 [19:23] <mok0> loic-m: yes
  55 [19:23] <asomething> it would be better to do it in debian/rules i'd think, no patch needed
  56 [19:24] <mok0> And the question is if the app should be renamed at all
  57 [19:24] <loic-m> indeed, we'd get a different command than other distros
  58 [19:24] <mok0> There's not anything in policy saying that we can't have caps in application names
  59 [19:25] <tuantub> what is when we use dpatch insteed ?
  60 [19:25] <mok0> So this is something we need to tell the uploader.
  61 [19:25] <mok0> tuantub: Hm, it's not worth adding a patch system to do something as simple as that.
  62 [19:26] <mok0> If we _must_ rename it, better do it in debian/rules
  63 [19:26] <mok0> But I would choose to let upstream decide how the name of the app should be spelled
  64 [19:27] <mok0> 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.
  65 [19:27] <mok0> setup.py is a special case perhaps :-)
  66 [19:27] <tuantub> mok0: so far i know, we'd better use dpatch than touching the source :-/
  67 [19:28] <mok0> tuantub: that's true, but sometimes it's a pain to patch files used by the build
  68 [19:29] <tuantub> mok0: i think we can tell the rules to patch before building ?
  69 [19:29] <mok0> tuantub: we can
  70 [19:29] <asomething> the diff in setup.py is only about the renaming. if they drop the rename, they don't need it
  71 [19:30] <mok0> asomething: right
  72 [19:30] <mok0> So that problem goes away
  73 [19:30]  * tuantub :)
  74 [19:30] <Rail> moving the file after "python setup.py install..." is the solution
  75 [19:30] <mok0> Rail: yes
  76 [19:31] <mok0> 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
  77 [19:31] <mok0> 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!
  78 [19:31] <mok0> Do we have a volunteer to write down the review, and post it later?
  79 [19:32] <Rail> ok, if you want to rename it, moving is better than patch
  80 [19:32] <mok0> Rail: yes
  81 [19:32] <tuantub> Question: must we build the packages on the newest release of ubuntu ?
  82 [19:32]  * asomething will post the review
  83 [19:32] <mok0> asomething, thanks.
  84 [19:33] <mok0> tuantub: Generally, yes
  85 [19:33] <mok0> tuantub: but if you don't have a karmic builder, never mind for now
  86 [19:33] <mok0> 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!
  87 [19:33] <mok0> 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.
  88 [19:35] <Rail> hmm, lintian file is 0 bytes, but I can see at least one warning regarding standards-version...
  89 [19:35] <asomething> on debian.mentors most sponsors require an empty watch file commenting why one can't be used
  90 [19:35] <Rail> /see/predict/
  91 [19:35] <mok0> Right. The current version is 3.8.1
  92 [19:35] <tuantub> mok0: debian/config ?
  93 [19:36] <asomething> Rail: I find running "lintian -iI --pedantic" more useful
  94 [19:36] <mok0> tuantub: it's set to 5, which is ok IMO... if you don't require anything from the later versions of debhelper
  95 [19:36] <tuantub> mok0: did you mean compat ?
  96 [19:37] <mok0> tuantub: yes, sorry
  97 [19:37] <tuantub> mok0: ;)
  98 [19:37] <Rail> asomething: a'm talking about the lintian output on the revu site
  99 [19:38] <loic-m> Rail: package was uploaded when version vas still 3.8.0, no?
 100 [19:38] <loic-m> s/vas/was/
 101 [19:38] <Rail> ah, yes
 102 [19:38] <asomething> Rail: REVU probably only runs it at the up load time
 103 [19:38] <mok0> loic-m: yes, but it needs to be updated for karmic now
 104 [19:39] <mok0> Running lintian with the -I switch gives some points to discus
 105 [19:39] <mok0> s
 106 [19:40] <mok0> Generally, for packages in REVU, I like them to be completely clean
 107 [19:40] <loic-m> 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)
 108 [19:40] <asomething> Build-Depends-Indep should be used
 109 [19:41] <mok0> loic-m: no :-)
 110 [19:41] <loic-m> (sorry, I've got gloves today ;) )
 111 [19:41] <mok0> loic-m: but it should be on the list of things to do
 112 [19:41] <mok0> 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.
 113 [19:41] <asomething> loic-m: sure if that's the only comment
 114 [19:42] <mok0> What about debian/rules?
 115 [19:42] <loic-m> mok0: what if an uploader doesn't answer neither review or emails for month but you'd like to get the package in Ubuntu?
 116 [19:43] <mok0> loic-m: let's discuss that after class :-)
 117 [19:43] <loic-m> mok0: ok
 118 [19:43] <Rail> i'd prefer to use cdbs to avoid copy/paste in debian/rules :)
 119 [19:43] <asomething> well something is amiss, it's FTBFS in a pbuilder (sorry, if that's getting ahead).
 120 [19:44] <mok0> Rail: well, that's the choice of the packager
 121 [19:45] <mok0> debian/rules contains boilerplate comments at the top, they must go
 122 [19:45] <mok0> Otherwise, it's nice and clean, good work
 123 [19:45] <asomething> http://paste.ubuntu.com/177375/
 124 [19:46] <mok0> asomething: yes the building is not working
 125 [19:46] <stefanlsd> mok0: do you know where we can find more information about each dh_ call?  (besides man page)
 126 [19:46] <mok0> And it's because of debian/rules
 127 [19:46] <mok0> And it's because of debian/control sorry
 128 [19:46] <Rail> i'd add a blank line between install: and binary-indep: :)
 129 [19:47] <mok0> stefanlsd: no, it's badly missing. I've looked at the source once in a while
 130 [19:47] <Rail> stefanlsd: vi =dh_whatever ;)
 131 [19:47] <mok0> Rail: me too, but it doesn't matter
 132 [19:48] <Rail> +1
 133 [19:48] <mok0> This is a python package, so we should use python_central
 134 [19:48] <mok0> ... or rather the uploader should fix it.
 135 [19:49] <mok0> We can leave a URL in the comment: http://wiki.debian.org/DebianPython/NewPolicy
 136 [19:49] <stefanlsd> http://python-modules.alioth.debian.org/python-central_howto.txt
 137 [19:50] <mok0> ... and we need a "XS-Python-Version:" field in debian/control
 138 [19:50] <mok0> stefanlsd: thx
 139 [19:50] <mok0> The package also needs a watch file
 140 [19:51] <mok0> asomething: are you up to speed with the review? You might pastebin it and we can take a look
 141 [19:52] <asomething> mok0: sorry, I was just going to go back into the log and write it when we were done
 142 [19:52] <mok0> asomething: ah ok
 143 [19:53] <mok0> After looking at the files in debian/ I usually do a build
 144 [19:53] <mok0> It is absolutely recommended that you use a pbuilder , cowbuilder og sbuilder for that
 145 [19:55] <Rail> (pbuilder-dist is the easiest, IMHO)
 146 [19:55] <mok0> It is
 147 [19:56] <mok0> Hm. I'm a bit puzzled at the dh_testroot error
 148 [19:57] <mok0> Well, if you remove it from the clean: target, it builds
 149 [19:58]  * tuantub_ :D
 150 [20:00] <mok0> Now finally, any comments about the description field in debian/control?
 151 [20:01] <weboide> the short description isn't very meaningful?
 152 <mok0> ... and the long description ain't very long :-)
 153 <weboide> true
 154 * Rafik has quit (Read error: 104 (Connection reset by peer))
 155 <mok0> The uploader has written a manpage, which I usually thank them for especially. But this one is very short as well
 156 <mok0> A man page should say HOW the program is to be used, not only WHAT it does
 157 <mok0> 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?
 158 <mok0> So while it's good that uploaders write a manpage, it should be a _good_ manpage also
 159 <mok0> So, at this point, I think we have enough for a lengthy review...
 160 <asomething> Alright. Here's what I have so far. Anything missing? http://paste.ubuntu.com/177390/
 161 <mok0> asomething: that is very good!
 162 * theru (n=kim@0x5552c2fe.adsl.cybercity.dk) has left #ubuntu-classroom
 163 <mok0> asomething: also tell him to remove the boilerplate comment in debian/rules (at the top)
 164 <asomething> mok0: will do!
 165 <Rail> no Vcs-* in debian/control, must be :)
 166 <weboide> asomething: and maybe also a more meaningful short-description
 167 <mok0> right, leave this link:  http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis
 168 <mok0> Well, perhaps it's time to end the lesson. Any questions?
 169 * k0001 (n=k0001@host1.190-30-3.telecom.net.ar) has joined #ubuntu-classroom
 170 <asomething> mok0: thanks!
 171 <tuantub_> mok0: thanks ;)
 172 <weboide> Is it required to package the lastest version of the software for the package to get included into ubuntu?
 173 <Rail> mok0: tahnk you very much
 174 <loic-m> thanks mok0
 175 <weboide> thanks for the lesson mok0
 176 <mok0> My pleasure! Thanks for coming along!
 177 <mok0> Now for the question we postponed
 178 * mok0 searches scrollback
 179 <weboide> gotta go now, thank you again mok0 , see you all!
 180 <mok0> hm can't locate it
 181 * weboide has quit ("Yeeehaaaa!")
 182 <mok0> Ah
 183 <mok0> what if an uploader doesn't answer neither review or emails for month but you'd like to get the package in Ubuntu?
 184 <mok0> If the uploader doesn't reply in a reasonable time, you are free to take over the package
 185 <mok0> Anyone can make a new upload
 186 * eitreach has quit ("Ex-Chat")
 187 <mok0> 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
 188 * joaopinto (n=janito@85.138.171.34) has joined #ubuntu-classroom
 189 <loic-m> 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?
 190 <mok0> loic-m: No
 191 <mok0> loic-m: usually the packager has  used a free software license for the packaging
 192 <mok0> loic-m: I think it's fair to continue the work on the uploaded package
 193 * tuantub_ is now known as tuantub
 194 <mok0> If the uploader is MIA the package is fair game
 195 <loic-m> 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)?
 196 <mok0> 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
 197 <loic-m> ok
 198 <mok0> loic-m: it's also about giving credit where it's due
 199 <loic-m> indeed
 200 <mok0> otoh, uploaders are also making use of a service where they get (free) reviews
 201 * tuantub has quit ("Lost terminal")
 202 <mok0> so if they loose interest, it's only fair that someone else can take over
 203 <mok0> many packages in "needs work" are in pretty good shape, they just need someone to push it along