2009-05-21
Next Session: TBD |
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
Packaging/Training/Logs/2009-05-21 (last edited 2009-05-21 19:32:33 by cpe-72-229-211-120)