| === ejat is now known as e-jat | ||
| === nick is now known as Guest46725 | ||
| === Guest46725 is now known as ziroday | ||
| === MaWaLe1 is now known as MaWaLe | ||
| === MaWaLe1 is now known as MaWaLe | ||
| === Rafik_ is now known as Rafik | ||
| mok0 | We'll wait just a couple of minutes to allow people to show up... | 18:59 |
|---|---|---|
| mok0 | 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:02 | |
| mok0 | This class is going to be about packaging and reviewing packages on the REVU site. | 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/ | 19:03 |
| 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 :-) | 19:04 |
| mok0 | That is a modified version of the Debian Policy Manual found here: http://www.debian.org/doc/debian-policy/ | 19:05 |
| mok0 | Another good place to get information is the MOTU packaging guide: https://wiki.ubuntu.com/PackagingGuide | 19:05 |
| mok0 | Any questions at this point? | 19:05 |
| 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. | 19:06 |
| mok0 | Does everyone have a Launchpad ID? (Just checking :-)) | 19:06 |
| * Rail has | 19:06 | |
| * weboide also | 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). | 19:07 |
| mok0 | Any suggestions for packages to look at? Perferably some that haven't been reviewed before | 19:08 |
| mok0 | How about "gammapage" | 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:09 |
| asomething | sure | 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. | 19:09 |
| mok0 | What's the verdict? | 19:10 |
| weboide | not in debian ;) | 19:10 |
| mok0 | Right | 19:10 |
| 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. | 19:11 |
| mok0 | (Select the LATEST upload of gammapage) | 19:11 |
| mok0 | This one looks ok! | 19:12 |
| weboide | Question: Do every src files need a license header also? What if they don't? | 19:12 |
| mok0 | Answer: Ideally, yes. | 19:13 |
| mok0 | It's something that the packager might negotiate with upstream about | 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 | 19:14 |
| mok0 | OK, let's move on | 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. | 19:14 |
| mok0 | I usually do this in /tmp :-) | 19:15 |
| 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. | 19:16 |
| mok0 | So, now let's check to see that nothing else is in the .diff.gz file: | 19:17 |
| mok0 | lsdiff -z <package>.diff.gz | 19:17 |
| mok0 | Is everyone with me at this point? | 19:17 |
| * Rail is | 19:18 | |
| * weboide is too | 19:18 | |
| * tuantub :D | 19:18 | |
| mok0 | What's the situation with gammapage_0.5.1-0ubuntu1.diff.gz ? | 19:18 |
| asomething | looks like there are some direct changes to the source in the diff.gz | 19:18 |
| mok0 | It does indeed | 19:18 |
| weboide | diffstat says 1418 insertions into gammapage file. Big change. | 19:21 |
| mok0 | Can you see what's going on? | 19:21 |
| mok0 | Exactly. Looks like the file gammapage is not in the tarball | 19:21 |
| Rail | actually the file was renamed | 19:22 |
| weboide | yeah, filename is gammapage-0.5.1/GAMMApage | 19:22 |
| Rail | mv GAMMApage gammapage | 19:22 |
| mok0 | Well copied | 19:22 |
| mok0 | Do we like this way of doing things? | 19:23 |
| Rail | symlink would be better at least | 19:23 |
| loic-m | nope, better patch in debian/ | 19:23 |
| mok0 | loic-m: yes | 19:23 |
| asomething | it would be better to do it in debian/rules i'd think, no patch needed | 19:23 |
| mok0 | And the question is if the app should be renamed at all | 19:24 |
| loic-m | indeed, we'd get a different command than other distros | 19:24 |
| mok0 | There's not anything in policy saying that we can't have caps in application names | 19:24 |
| tuantub | what is when we use dpatch insteed ? | 19:25 |
| mok0 | So this is something we need to tell the uploader. | 19:25 |
| mok0 | tuantub: Hm, it's not worth adding a patch system to do something as simple as that. | 19:25 |
| mok0 | If we _must_ rename it, better do it in debian/rules | 19:26 |
| mok0 | But I would choose to let upstream decide how the name of the app should be spelled | 19:26 |
| 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. | 19:27 |
| mok0 | setup.py is a special case perhaps :-) | 19:27 |
| tuantub | mok0: so far i know, we'd better use dpatch than touching the source :-/ | 19:27 |
| mok0 | tuantub: that's true, but sometimes it's a pain to patch files used by the build | 19:28 |
| tuantub | mok0: i think we can tell the rules to patch before building ? | 19:29 |
| mok0 | tuantub: we can | 19:29 |
| asomething | the diff in setup.py is only about the renaming. if they drop the rename, they don't need it | 19:29 |
| mok0 | asomething: right | 19:30 |
| mok0 | So that problem goes away | 19:30 |
| * tuantub :) | 19:30 | |
| Rail | moving the file after "python setup.py install..." is the solution | 19:30 |
| mok0 | Rail: yes | 19:30 |
| 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 | 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! | 19:31 |
| mok0 | Do we have a volunteer to write down the review, and post it later? | 19:31 |
| Rail | ok, if you want to rename it, moving is better than patch | 19:32 |
| mok0 | Rail: yes | 19:32 |
| tuantub | Question: must we build the packages on the newest release of ubuntu ? | 19:32 |
| * asomething will post the review | 19:32 | |
| mok0 | asomething, thanks. | 19:32 |
| mok0 | tuantub: Generally, yes | 19:33 |
| mok0 | tuantub: but if you don't have a karmic builder, never mind for now | 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! | 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. | 19:33 |
| Rail | hmm, lintian file is 0 bytes, but I can see at least one warning regarding standards-version... | 19:35 |
| asomething | on debian.mentors most sponsors require an empty watch file commenting why one can't be used | 19:35 |
| Rail | /see/predict/ | 19:35 |
| mok0 | Right. The current version is 3.8.1 | 19:35 |
| tuantub | mok0: debian/config ? | 19:35 |
| asomething | Rail: I find running "lintian -iI --pedantic" more useful | 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 | 19:36 |
| tuantub | mok0: did you mean compat ? | 19:36 |
| mok0 | tuantub: yes, sorry | 19:37 |
| tuantub | mok0: ;) | 19:37 |
| Rail | asomething: a'm talking about the lintian output on the revu site | 19:37 |
| loic-m | Rail: package was uploaded when version vas still 3.8.0, no? | 19:38 |
| loic-m | s/vas/was/ | 19:38 |
| Rail | ah, yes | 19:38 |
| asomething | Rail: REVU probably only runs it at the up load time | 19:38 |
| mok0 | loic-m: yes, but it needs to be updated for karmic now | 19:38 |
| mok0 | Running lintian with the -I switch gives some points to discus | 19:39 |
| mok0 | s | 19:39 |
| mok0 | Generally, for packages in REVU, I like them to be completely clean | 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) | 19:40 |
| asomething | Build-Depends-Indep should be used | 19:40 |
| mok0 | loic-m: no :-) | 19:41 |
| loic-m | (sorry, I've got gloves today ;) ) | 19:41 |
| mok0 | loic-m: but it should be on the list of things to do | 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. | 19:41 |
| asomething | loic-m: sure if that's the only comment | 19:41 |
| mok0 | What about debian/rules? | 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? | 19:42 |
| mok0 | loic-m: let's discuss that after class :-) | 19:43 |
| loic-m | mok0: ok | 19:43 |
| Rail | i'd prefer to use cdbs to avoid copy/paste in debian/rules :) | 19:43 |
| asomething | well something is amiss, it's FTBFS in a pbuilder (sorry, if that's getting ahead). | 19:43 |
| mok0 | Rail: well, that's the choice of the packager | 19:44 |
| mok0 | debian/rules contains boilerplate comments at the top, they must go | 19:45 |
| mok0 | Otherwise, it's nice and clean, good work | 19:45 |
| asomething | http://paste.ubuntu.com/177375/ | 19:45 |
| mok0 | asomething: yes the building is not working | 19:46 |
| stefanlsd | mok0: do you know where we can find more information about each dh_ call? (besides man page) | 19:46 |
| mok0 | And it's because of debian/rules | 19:46 |
| mok0 | And it's because of debian/control sorry | 19:46 |
| Rail | i'd add a blank line between install: and binary-indep: :) | 19:46 |
| mok0 | stefanlsd: no, it's badly missing. I've looked at the source once in a while | 19:47 |
| Rail | stefanlsd: vi =dh_whatever ;) | 19:47 |
| mok0 | Rail: me too, but it doesn't matter | 19:47 |
| Rail | +1 | 19:48 |
| mok0 | This is a python package, so we should use python_central | 19:48 |
| mok0 | ... or rather the uploader should fix it. | 19:48 |
| mok0 | We can leave a URL in the comment: http://wiki.debian.org/DebianPython/NewPolicy | 19:49 |
| stefanlsd | http://python-modules.alioth.debian.org/python-central_howto.txt | 19:49 |
| mok0 | ... and we need a "XS-Python-Version:" field in debian/control | 19:50 |
| mok0 | stefanlsd: thx | 19:50 |
| mok0 | The package also needs a watch file | 19:50 |
| mok0 | asomething: are you up to speed with the review? You might pastebin it and we can take a look | 19:51 |
| asomething | mok0: sorry, I was just going to go back into the log and write it when we were done | 19:52 |
| mok0 | asomething: ah ok | 19:52 |
| mok0 | After looking at the files in debian/ I usually do a build | 19:53 |
| mok0 | It is absolutely recommended that you use a pbuilder , cowbuilder og sbuilder for that | 19:53 |
| Rail | (pbuilder-dist is the easiest, IMHO) | 19:55 |
| mok0 | It is | 19:55 |
| mok0 | Hm. I'm a bit puzzled at the dh_testroot error | 19:56 |
| mok0 | Well, if you remove it from the clean: target, it builds | 19:57 |
| * tuantub_ :D | 19:58 | |
| mok0 | Now finally, any comments about the description field in debian/control? | 20:00 |
| weboide | the short description isn't very meaningful? | 20:01 |
| mok0 | right | 20:01 |
| mok0 | ... and the long description ain't very long :-) | 20:01 |
| weboide | true | 20:02 |
| mok0 | The uploader has written a manpage, which I usually thank them for especially. But this one is very short as well | 20:03 |
| mok0 | A man page should say HOW the program is to be used, not only WHAT it does | 20:03 |
| 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? | 20:05 |
| mok0 | So while it's good that uploaders write a manpage, it should be a _good_ manpage also | 20:05 |
| mok0 | So, at this point, I think we have enough for a lengthy review... | 20:06 |
| asomething | Alright. Here's what I have so far. Anything missing? http://paste.ubuntu.com/177390/ | 20:06 |
| mok0 | asomething: that is very good! | 20:07 |
| mok0 | asomething: also tell him to remove the boilerplate comment in debian/rules (at the top) | 20:08 |
| asomething | mok0: will do! | 20:08 |
| Rail | no Vcs-* in debian/control, must be :) | 20:08 |
| weboide | asomething: and maybe also a more meaningful short-description | 20:08 |
| mok0 | right, leave this link: http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-pkg-synopsis | 20:09 |
| mok0 | Well, perhaps it's time to end the lesson. Any questions? | 20:10 |
| asomething | mok0: thanks! | 20:11 |
| tuantub_ | mok0: thanks ;) | 20:11 |
| weboide | Is it required to package the lastest version of the software for the package to get included into ubuntu? | 20:11 |
| Rail | mok0: tahnk you very much | 20:11 |
| loic-m | thanks mok0 | 20:12 |
| weboide | thanks for the lesson mok0 | 20:12 |
| mok0 | My pleasure! Thanks for coming along! | 20:12 |
| mok0 | Now for the question we postponed | 20:12 |
| * mok0 searches scrollback | 20:12 | |
| weboide | gotta go now, thank you again mok0 , see you all! | 20:13 |
| mok0 | hm can't locate it | 20:14 |
| mok0 | Ah | 20:14 |
| mok0 | what if an uploader doesn't answer neither review or emails for month but you'd like to get the package in Ubuntu? | 20:14 |
| mok0 | If the uploader doesn't reply in a reasonable time, you are free to take over the package | 20:15 |
| mok0 | Anyone can make a new upload | 20:15 |
| 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 | 20:16 |
| 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? | 20:17 |
| mok0 | loic-m: No | 20:17 |
| mok0 | loic-m: usually the packager has used a free software license for the packaging | 20:18 |
| mok0 | loic-m: I think it's fair to continue the work on the uploaded package | 20:18 |
| === tuantub_ is now known as tuantub | ||
| mok0 | If the uploader is MIA the package is fair game | 20:19 |
| 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)? | 20:19 |
| 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 | 20:20 |
| loic-m | ok | 20:20 |
| mok0 | loic-m: it's also about giving credit where it's due | 20:20 |
| loic-m | indeed | 20:21 |
| mok0 | otoh, uploaders are also making use of a service where they get (free) reviews | 20:21 |
| mok0 | so if they loose interest, it's only fair that someone else can take over | 20:22 |
| mok0 | many packages in "needs work" are in pretty good shape, they just need someone to push it along | 20:22 |
| stefanlsd | mok0: it feels like motu's are reluctant to advocate packages... (maybe for fear of missing something, someone else picks up on?) - how can we change this / improve it... | 20:22 |
| mok0 | stefanlsd: It's true | 20:23 |
| mok0 | stefanlsd: one reason is that not many motus are actively reviewing | 20:23 |
| stefanlsd | mok0: and maybe, what kind of impact do we have on universe if a 'not so great - but working package' makes it into universe? | 20:24 |
| mok0 | ... so if the probability of finding one reviewer is p, then the probability of finding two reviewers is p**2 | 20:24 |
| Rail | becoming a motu is the solution :) | 20:24 |
| mok0 | stefanlsd: I don't think it matters much. | 20:24 |
| mok0 | But our hope is that uploaders stick around and care for their packages | 20:25 |
| mok0 | It's been discussed that some kind of commitment should be required, but it's uncertain how that can be implemented | 20:25 |
| stefanlsd | i agree, but i think its also unfair for uploaders to ask and ask, and nobody really looks at it. they get tired of trying, and move on | 20:26 |
| mok0 | stefanlsd: indeed. | 20:26 |
| stefanlsd | (different if comments were made by reviewer and they haven't responded) | 20:26 |
| Rail | yes, someties passing NEW queue at Debian is easier than getting revu... | 20:27 |
| mok0 | But we do have REVU day every friday, and this is a good time to show up on #ubuntu-motu and ask for feedback | 20:27 |
| stefanlsd | also maybe i think we need to be less harsh on packages? if they have the basics right, copyright is ok, package builds... lets get it into ubuntu. chances are, for the little things, the uploader will improve as he goes, or users now using it will file a bug and fix it... | 20:28 |
| mok0 | I disagree, actually | 20:28 |
| mok0 | Once the package has been accepted, it will never improve | 20:29 |
| mok0 | It's much better to get the package in _perfect_ shape from the outset | 20:29 |
| mok0 | That also makes maintenance of it much simpler | 20:29 |
| mok0 | But I do understand the frustration | 20:29 |
| stefanlsd | mok0: i agree with that, but to be honest, as a user.. i really just want to apt-get install somethingnew. i guess its a balance... | 20:30 |
| mok0 | In fact, I think the packages that make it into Ubuntu are generally in much better shape than those coming from Debian. | 20:30 |
| kklimonda | mok0: Do I have to add copyright file to every package if I split source package into few binary packages and they all depend on a package that has copyright (and links /usr/share/doc/package-foobar to single directory)? | 20:30 |
| mok0 | kklimonda: the dpkg-buildpackage system takes care of that | 20:31 |
| mok0 | kklimonda: you only need to make sure one debian/copyright file is there :-) | 20:31 |
| asomething | mok0: but do we follow up with maintenance or let them bit rot? | 20:31 |
| kklimonda | mok0: but I have few different packages - crawl-common, crawl-console, crawl-x11 | 20:31 |
| stefanlsd | mok0: again it may be so, but for the end user - if its not in the repo - ubuntu sucks. it doesnt even have X (but i get the point of X man page not being complete or wrong and causing more frustration to users) | 20:32 |
| kklimonda | mok0: crawl-common has all documentation files (including copyright) and /usr/share/doc/crawl-{console,x11} links to /usr/share/doc/crawl-common/ | 20:32 |
| mok0 | asomething: maintenance, and that's the problem if the uploader abandons the package | 20:32 |
| mok0 | kklimonda: dpkg-buildpackage makes sure there's a copyright file in all | 20:33 |
| mok0 | stefanlsd: fortunately, we have the PPAs now | 20:33 |
| stefanlsd | mok0: mmm. we need to incentivise reviewers somehow | 20:33 |
| mok0 | stefanlsd: true | 20:33 |
| mok0 | I have not been doing reviews yet for this cycle (because of work) but I will start again soon | 20:34 |
| asomething | mok0: without having specific maintainers how do we go about getting people to make that commitment? | 20:34 |
| mok0 | asomething: good question! | 20:34 |
| asomething | I wonder if there could be a way to automatically subscribe someone to the new packages bug page | 20:34 |
| mok0 | We do encourage people to get their packages into Debian, because they have a system of maintainership | 20:35 |
| mok0 | otoh getting packages into Debian is even more wait-ful | 20:35 |
| mok0 | So perhaps having a system of maintainership would be something to consider. | 20:36 |
| mok0 | One argument often heard from MOTUs is: "We have > 1000 packages to care for already, why should we have more?" | 20:37 |
| asomething | mok0: my problem with debian.mentors hasn't actually been getting new packages in. they're exciting people want to sponsor. it's been getting sponsors for unsexy uploads, little upstream releases | 20:37 |
| mok0 | asomething: I've been able to get things uploaded only via being in a team | 20:37 |
| mok0 | s/uploaded/sponsored | 20:38 |
| mok0 | Unfortunately, Debian does not accept packages from Ubuntu directly | 20:38 |
| asomething | it's the flip side of our more lose system. I can get smaller fixes into ubuntu much quicker. my packages often end up ahead in ubuntu as I get frustrated waiting for the changes to make it in debian | 20:39 |
| mok0 | asomething: indeed | 20:39 |
| mok0 | What we need are some DDs/MOTUs working across the aile | 20:40 |
| mok0 | Someone who would take the responsibility of sponsoring -0ubuntu1 packages, and naming a maintainer | 20:41 |
| asomething | definitely, one day I'll make DD, but hopefully I'll be a MOTU much sooner | 20:41 |
| mok0 | asomething: sound great! | 20:41 |
| asomething | there was a program for awhile, but it seems to have died out. the list still exists | 20:42 |
| mok0 | asomething: what program are you thinking of? | 20:42 |
| asomething | mok0: http://wiki.debian.org/Utnubu | 20:43 |
| mok0 | Ah that. It's been dead as long as I remember | 20:44 |
| asomething | ya, I CCed the list on a debian RFS and people seemed surprised that it still existed | 20:45 |
| mok0 | Well, I think there was bad blood for a while after Ubuntu forked off and took some of the best developers | 20:45 |
| stefanlsd | mok0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522138 (whats the status on the ITP? - how do i know if someone is working on it?) | 20:45 |
| mok0 | stefanlsd: It's only a few months old. I think you should mail the guy | 20:46 |
| asomething | stefanlsd: you could check http://mentors.debian.net/ and see if there's been an upload as well | 20:46 |
| stefanlsd | mok0: who do i mail, the owner? | 20:47 |
| stefanlsd | Rail and I actually already did it for Ubuntu - http://revu.ubuntuwire.com/p/gears | 20:47 |
| mok0 | stefanlsd: yes | 20:48 |
| asomething | stefanlsd: might be worth mentioning it on the debian bug. if nothing else, it might be helpful for them | 20:48 |
| mok0 | It is possible to get a package into Ubuntu, but if it get's into Debian later, it will likely be overridden | 20:49 |
| mok0 | ... which is kinda a waste of work | 20:49 |
| asomething | well, I must be going... thanks for the great session, mok0! | 20:49 |
| mok0 | so it's better to communicate with the Debian folks | 20:49 |
| mok0 | OK see you later! | 20:49 |
| stefanlsd | mok0: kk. thanks. mailed the owner | 20:50 |
| mok0 | stefanlsd: good luck! | 20:50 |
| Rail | see you all, mok0 tahnks a lot | 20:50 |
| mok0 | Byebye! | 20:50 |
| Rail | zzz... | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!