[01:59] <crane> date -u
[02:00] <nhandler> crane: Run that in a Terminal, not your IRC client
[02:01] <crane> nhandler: sorry for my mistake.
[05:53] <qwebirc41742> hi all
[12:49] <dholbach> Packaging Training Session "On-Call Review" with cjwatson, seb128, james_w and me in 12m
[13:00] <dholbach> HELLO EVERYBODY!
[13:00] <dholbach> This is the first time we break out of the tutorial-esque or Q&A-like way of Packaging Training sessions and decided to have an "On-Call Review" session instead. I'm sure we'll all learn something new today and have some fun.
[13:00] <dholbach> we have cjwatson, seb128 and james_w here, but I noticed a bunch of others who are likely able to help out a bit with questions :-)
[13:00] <seb128> hello!
[13:00] <cjwatson> hiya
[13:00] <james_w> hi!
[13:00] <dholbach> who do we have here for the session today and who brought some review requests? :-)
[13:01] <ara> o/
[13:01] <dholbach> hey ara
[13:01] <seb128> hey ara ;-)
[13:01] <juanje> hi
[13:01]  * sebner waves
[13:01]  * noodles775 waves too
[13:02] <dholbach> While we're looking for somebody to pluck up some courage, we could take a look at http://people.canonical.com/~dholbach/sponsoring/ :-)
[13:02] <cjwatson> well then, why don't we go first-come-first-served
[13:02] <juanje> dholbach: I'm up
[13:02] <cjwatson> ara spoke first :)
[13:02] <juanje> ;-)
[13:02] <ara> juanje, you go or I go?
[13:03] <juanje> ara: you, please
[13:03] <ara> ok, bug https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/412882
[13:03] <ara> new upstream version of ldtp
[13:03] <dholbach> I guess we could review packages simultaneously and just say [package A] at the beginning of our sentences to make the logs make more sense afterwards?
[13:04] <ara> [package ldtp] OK ;-)
[13:04] <cjwatson> [ldtp] ok, an upstream merge, so I'll start by fetching the current package from Ubuntu and the Debian package
[13:04] <ara> [package ldtp] yes, cjwatson, that's what I did
[13:04] <dholbach> juanje: what is your review request?
[13:04] <cjwatson> [ldtp] I have a chdist setup to make it trivial to fetch Debian versions of things with 'chdist apt-get unstable -d source ldtp'
[13:05] <ara> [package ldtp] but I also wanted to fix bug https://bugs.launchpad.net/ubuntu/+source/ldtp/+bug/412871
[13:05] <juanje> [nautilus-md5sum] For example -> http://revu.ubuntuwire.com/p/nautilus-md5sum
[13:05]  * dholbach makes a note to investigate chdist afterwards. :-)
[13:05] <dholbach> [nautilus-md5sum] getting the source code with dget -xu
[13:05] <cjwatson> [ldtp] ara: have you contacted the Debian maintainer of this package?
[13:05] <ara> [ldtp] finally I linked the upstream version, attached the diff.gz and subscribe universe sponsors
[13:05] <dutchie> hmm, how long does it take an upload to show up on revu?
[13:06] <ara> [ldtp] cjwatson, yes, we communicate quite often
[13:06] <seb128> [nautilus-md5sum] notice the copyright warning on the page
[13:06] <cjwatson> [ldtp] with upstream updates it's important that we both end up using the same .orig.tar.gz, otherwise it's hard to sync later. ok.
[13:06] <seb128> [nautilus-md5sum]  that's a blocker to get new packages accepted
[13:06] <dholbach> dutchie: can you ask on #ubuntu-motu if there's some REVU admins about who can answer the question?
[13:06] <dutchie> will do
[13:07] <juanje> [nautilus-md5sum] But I don't see any error, just a legal message, but no error
[13:07] <dholbach> [nautilus-md5sum] running a test-build in pbuilder while I'm taking a look at everything else. juanje: do you think you could make the version 0.3.1-0ubuntu1 instead to indicate that it is not in Debian yet?
[13:07] <cjwatson> [ldtp] the interdiff is tiny, and looks mostly correct: http://paste.ubuntu.com/252457/
[13:08] <cjwatson> [ldtp] you should normally *not* update Standards-Version in Ubuntu changes
[13:08] <seb128> [nautilus-md5sum] $ licensecheck * -r
[13:08] <seb128> nautilus-md5sum.py: GPL (v2 or later)
[13:08] <seb128> you need a GPL copy there in the tarball
[13:08] <seb128> otherwise the source can't be distributed
[13:08] <cjwatson> [ldtp] reference: http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-controlfields.html#s-f-Standards-Version
[13:09] <ara> [ldtp]  cjwatson, oh! thanks! I didn't know that :-) just trying to avoid lintian warnings :-)
[13:09] <cjwatson> [ldtp] it'd be a good thing to forward to the Debian maintainer, although it isn't really worth a bug report just for that
[13:09] <juanje> [nautilus-md5sum] seb128: Ok. The thing is the software have no upstream tarball or so, the package itself is the upstream, that is whay there is not GPL copy, but I can copy there...
[13:09] <cjwatson> [ldtp] just as a reminder, one must always check the upgrading-checklist in policy before changing Standards-Version in Debian
[13:10] <dholbach> [nautilus-md5sum] The build succeeded and I just ran lintian -Iiv nautilus-md5sum_0.3.1-1_amd64.changes which indicated no major mistakes.
[13:10] <seb128> [nautilus-md5sum] juanje: that doesn't change the fact that it needs the license text in the tarball, yes please do
[13:10] <cjwatson> [ldtp] Any particular reason you removed yourself from Uploaders?
[13:10] <juanje> [nautilus-md5sum] dholbach: sorry, I think I didn't get the earlier question
[13:10] <dholbach> [nautilus-md5sum] juanje: are you sure about the python-dev Dependency?
[13:11] <ara> [ldtp] cjwatson, I am uploader in the debian package, but not the ubuntu. so I thought it had to be removed
[13:11] <juanje> [nautilus-md5sum] seb128: Ok, I'll do
[13:11] <juanje> [nautilus-md5sum] dholbach: I think this come up with the pbuilder or something
[13:11] <seb128> [nautilus-md5sum] juanje: the dirs file is probably not required
[13:12] <dholbach> [nautilus-md5sum] juanje: the version number in debian/changelog is 0.3.1-1 which indicates that 0.3.1 is the upstream version and -1 the first debian revision. As I see it the package has never been in Debian and this would be its first revision in Ubuntu, so I'd use 0.3.1-0ubuntu1.
[13:12] <cjwatson> [ldtp] Uploaders means nothing to the Ubuntu archive, so you should leave it in to minimise the delta
[13:12] <juanje> [nautilus-md5sum] dholbach: Ok, that is because I was trying at the same time to get into Debian and Ubuntu
[13:12] <dholbach> ok
[13:12] <cjwatson> [ldtp] I'm just checking to ensure that python-wnck is sufficient
[13:13] <dholbach> [nautilus-md5sum] minor: As the package contains no compiled code, but just a python script, you probably don't need ${shlibs:Depends}.
[13:13] <juanje> [nautilus-md5sum] dholbach: Ok
[13:13] <seb128> [nautilus-md5sum] juanje: you might want to use pkg-config to get the nautilus directory rather than coding the abi version there
[13:14] <cjwatson> ./python/ldtpeditor:69:    import gtksourceview
[13:14] <cjwatson> [ldtp] doesn't that mean you need a dependency on python-gtksourceview as well?
[13:14] <juanje> [nautilus-md5sum] seb128: aha... I'll check
[13:14] <james_w> anyone else with a package to review?
[13:15] <AndrewGee> I have https://bugs.launchpad.net/ubuntu/jaunty/+source/osm-gps-map/+bug/387043 as a SRU for Jaunty.
[13:15] <cjwatson> [ldtp] ara: that's everything I can see; if you post a new diff with those changes, I'll sponsor it after this session
[13:15] <ara> [ldtp] cjwatson, thanks for your help!
[13:15] <dholbach> [nautilus-md5sum] more of a "upstream idea": try using python's distutils and python-distutils-extra for translations, but that's just a suggestion. :-)
[13:16] <juanje> [nautilus-md5sum] I have question about non-native packages, and how to use get-orig/watch file to get a "upstream" tarball and build the package
[13:16] <juanje> [nautilus-md5sum] dholbach: yeah, that's my idea ;-)
[13:16] <dholbach> [nautilus-md5sum] debian/copyright does not contain a note about where the source code was retrieved from
[13:16] <dholbach> juanje: just ask :)
[13:16] <cjwatson> [nautilus-md5sum] I ran across a bug yesterday which had the idea of implementing a get-orig-source sequence in dh(1) with the standard uscan thing ...
[13:17] <juanje> [nautilus-md5sum] dholbach: the code was made for a guy from my team and I like he change into python-distutils-extra the code
[13:17] <james_w> AndrewGee: that's tricky as it requires an ok from motu-sru before we can upload, and unfortunately for you I'm not in that team
[13:17] <AndrewGee> james_w: Ah. Nevermind then :)
[13:17] <dholbach> [nautilus-md5sum] juanje: if you have questions about that or need an example, I'm happy to answer that later on in some other place. :-)
[13:18] <arand> Is approvals of queue items in jaunty-proposed in the scope of this session?
[13:19] <james_w> arand: nope, sorry, that's a task restricted to a particular team
[13:19] <cjwatson> [osm-gps-map] I'm not convinced about the correctness of adding dpatch in an SRU; I would stick like glue to the current packaging scheme if I were you
[13:19] <dholbach> [nautilus-md5sum] seb128: Apart from the things we mentioned are you happy with it? :)
[13:19] <juanje> [nautilus-md5sum] The question: I have created debian/watch file and also added get-orig target into the debian/rules file but when I try to build the package the dpkg-buildpackage (or debuild, or pbuilder) cry about not to exist a *.orig directory or tarball, instead of donwload it. Do I need do something before to build?
[13:19] <arand> james_w: okay.
[13:19] <Laney> how about digging into ftbfs? :)
[13:20] <seb128> [nautilus-md5sum] dholbach: I am yes
[13:20] <cjwatson> [nautilus-md5sum] get-orig-source is not called manually; it's purely informational. You have to construct the tarball yourself, perhaps by calling 'debian/rules get-orig-source' manually
[13:20] <AndrewGee> [osm-gps-map] cjwatson: How would I go about that? I thought I'd need a patch system.
[13:20] <cjwatson> [nautilus-md5sum] sorry, I mean "not called automatically"
[13:20] <cjwatson> [osm-gps-map] you can just edit the source directly
[13:20] <juanje> [nautilus-md5sum] cjwatson: ummmm... I was guessed something like that...
[13:21] <AndrewGee> [osm-gps-map] cjwatson: I thought there wasn't allowed to be any modifications outside the debian/ directory in the deb .diff.gz file? Is this not true?
[13:21] <dholbach> [nautilus-md5sum] I don't know where you store the code right now, but if you are going to put it into Launchpad and maintain releases there, you could check out   apt-get source --diff-only storm  for an example of a debian/watch file, so you can just use uscan and uupdate afterwards.
[13:21] <cjwatson> [osm-gps-map] that's a myth
[13:22] <AndrewGee> [osm-gps-map] cjwatson: Okay. I'll get that fixed later :)
[13:22] <AndrewGee> cjwatson: Thanks for your help :)
[13:22] <cjwatson> [osm-gps-map] furthermore, your patches are the wrong way round at the moment anyway, since aclocal.m4 is (presumably) the source of the configure change and ought to be patched first; but for this I would definitely go with the smallest possible change to the package
[13:23] <juanje> [nautilus-md5sum] dholbach: the code is in LP already. Actually, It was always there: lp:nautilus-md5sum
[13:23] <AndrewGee> [osm-gps-map] cjwatson: Okay. Should I just patch the configure script then?
[13:24] <juanje> [nautilus-md5sum] dholbach: I'll check that package, thanks ;-)
[13:24] <cjwatson> [osm-gps-map] just to clarify, many people do find patch systems immensely useful; I'm not a fan myself but it's certainly popular among many developers, and if you find a patch system already there you should use it; you should also make your own mind up for new packages. This advice is just for SRUs
[13:24] <dholbach> [nautilus-md5sum] juanje: ok, I just thought you wanted to put releases there too (0.3.1 somehow indicated there were tarball releases... :-))
[13:24] <cjwatson> [osm-gps-map] you do need to patch whatever the source of that configure chunk is, not just configure
[13:24] <cjwatson> [osm-gps-map] otherwise you leave the package in a very confusing state for the next person to come along
[13:24] <dholbach> what-patch (in ubuntu-dev-tools) can usually tell you quickly which patch system is used by a package. :-)
[13:25] <dholbach> Do we have some more review requests?
[13:25] <AndrewGee> [osm-gps-map] Okay. Sounds good. So I'll patch aclocal.m4 and configure without dpatch then?
[13:25] <juanje> [nautilus-md5sum] dholbach: Actually we are developing the packages in LP and the upstream code is in hte same branch th
[13:25] <juanje> [nautilus-md5sum] that the debian directory
[13:26] <cjwatson> [osm-gps-map] for the SRU, right. I'd also recommend at some point switching the order of the patches for Karmic
[13:26] <dutchie> is this the right place to get http://revu.ubuntuwire.com/p/suvat reviewed?
[13:26] <dholbach> [nautilus-md5sum] juanje: that's fine, then you probably don't need a watch file, just move to 0.3.1 (native package) instead
[13:26] <juanje> [nautilus-md5sum] But I think this is a problem for generating non-native packages automaticaly
[13:26] <AndrewGee> [osm-gps-map] cjwatson: Okay. I'll get that done. Thanks.
[13:27] <juanje> [nautilus-md5sum] dholbach: they were that way before
[13:27] <juanje> [nautilus-md5sum] dholbach: but debian guys ask us to change to non-natives...
[13:27] <cjwatson> [nautilus-md5sum] I think that's correct, native packages are intended for things that really don't have a use outside of Debian and its derivatives, like dpkg
[13:27] <dholbach> [nautilus-md5sum] as an upstream it's probably a good idea to roll release tarballs, so other distros can grab them too
[13:28] <cjwatson> [nautilus-md5sum] they're not intended for cases where it's just a hassle to roll a tarball :)
[13:28] <dholbach> dutchie: I'll take a look now
[13:28] <james_w> (tell that to joey :-)
[13:29] <cjwatson> I thought he just abandoned anything that needed to be non-native :)
[13:29] <dholbach> [suvat] looks like ./tags is a leftover in suvat_0.2-0ubuntu1.diff.gz
[13:29] <dutchie> [suvat] should it not be included?
[13:30] <cjwatson> [suvat] it would be unusual to include it just in the diff, yes; the diff should just be what's needed to do the packaging
[13:30] <cjwatson> [suvat] usually just indicates that somebody forgot to delete it :)
[13:30] <dholbach> [suvat] I'm not sure what it's purpose is - I just saw a diff to the tags file in suvat_0.2-0ubuntu1.diff.gz
[13:30] <dutchie> [suvat] ok, i know where that's come from
[13:31] <cjwatson> [suvat] dh_clean removes files called "TAGS", but "tags" is too generic for that
[13:31] <cjwatson> [suvat] dholbach: it's from tools like exuberant-ctags, for easily following around function names and such in source code
[13:31] <dholbach> alright
[13:31] <cjwatson> integrates smoothly with vim
[13:31] <dholbach> [suvat] 3.8.2 is the current standards-version, you might want to have a look what changed after 3.8.0 in debian-policy
[13:32] <cjwatson> apt-cache show exuberant-ctags | grep ^Maintainer ;-)
[13:33] <dholbach> [suvat] you might want to take a look at http://www.debian.org/doc/packaging-manuals/python-policy/ and call dh_pycentral in debian/rules - it'd avoid installing .pyc files in the resulting package
[13:33] <pleia2> hi everyone, james_w just helped me get slightly up to speed so I could get a php package looked at, I'm actually working with the maintainer to review a whole pile of php packages, but I'm not the most experienced reviewer so some help on one of them would be great (they are all pretty similar)
[13:33] <dutchie> [suvat] it's cdbs - debhelper confused me too much
[13:33] <dutchie> [suvat] (my first package)
[13:33] <pleia2> I come from debian packaging, so I haven't gotten into REVU yet (forgive me!) but here's one: http://princessleia.com/deb/html_qf_advmultiselect/
[13:34] <cjwatson> [suvat] you might consider dh(1) for this package, since it's quite simple; it supports setup.py. You might only need one override target for that symlink at most.
[13:34] <dholbach> [suvat] you can safely remove debian/{pre,post}{inst,rm} - they don't do anything right now
[13:35] <cjwatson> [suvat] and if you use dh(1) it will actually get the setup.py install invocation correct to support python2.6
[13:36] <dholbach> [suvat] to expand on the topic a bit, you just need debian/{pre,post}{inst,rm} if you intend to override the default behaviour during the installation or add something to the process, they will be generated automatically from all the debhelper commands if you choose not change from the default
[13:36] <cjwatson> [suvat] something like http://paste.ubuntu.com/252473/ I think (untested)
[13:37] <cjwatson> [suvat] (BTW this is just a suggestion, totally not a review requirement)
[13:37] <dholbach> [suvat] (minor) lintian suggests to use © instead of (C) in debian/copyright
[13:38] <cjwatson> james_w: you want to do pleia2's? :)
[13:38] <dutchie> [suvat] I tried something like that. It seems that setup.py installs packages to site-packages when used with --prefix
[13:39] <dholbach> [suvat] apart from that I think I'm happy
[13:39] <cjwatson> [suvat] dh_auto_install uses the equivalent of: $(PYTHON) setup.py install --root=$(CURDIR)/debian/$(PACKAGE) --no-compile -O0 --install-layout=deb
[13:39] <james_w> [php-html-quickform-advmultiselect] couldn't it have a shorter name? :-)
[13:40] <dutchie> [suvat] so I should replace my cdbs-y debian/rules file with the one from the paste?
[13:40] <pleia2> [php-html-quickform-advmultiselect] I'm pretty sure this is the correct naming scheme for these, but yes, this ends up long
[13:40] <dholbach> [php-html-quickform-advmultiselect] interestingly enough we packaged php-html-quickform for the Ubuntu NGO team a few weeks ago :-)
[13:40] <dutchie> [suvat] get the changes to tags out of the diff.gz
[13:40] <cjwatson> [suvat] the version I reviewed was not cdbs. It's up to you, you can use cdbs if you like :-)
[13:40] <pleia2> [php-html-quickform-advmultiselect] already I know it needs a standards bump, and there might be a licensing issue (license was fine in older versions, but now lintian is complaining about php license?)
[13:40] <cjwatson> [suvat] the version I reviewed was just a traditional sequence of dh_* commands
[13:41] <james_w> [php-html-quickform-advmultiselect] is dh-make-php needed at build time?
[13:41] <pleia2> dholbach: [php-html-quickform-advmultiselect] ah! we were also working on a NMU for php-html-quickform, I'll have to look at what you guys did
[13:41] <dholbach> [php-html-quickform-advmultiselect] pleia2: https://wiki.ubuntu.com/NGO/ApplicationPackaging
[13:42] <dholbach> [php-html-quickform-advmultiselect] I'm a bit confused by the php-html-quickform-advmultiselectS/usr/share/php/* files in the .diff.gz - I think they shouldn't be there
[13:42] <cjwatson> [suvat] oh, I just noticed, for some reason you use dh_python rather than dh_pycentral (to match your build-dependency); I would expect that to print a warning at build-time)
[13:42] <dutchie> [suvat] I changed it to dh
[13:43] <dutchie> [suvat] I'll upload what I've got, hang on a moment
[13:43] <cjwatson> [suvat] remove that README.Debian, it's not mandatory to have one and it should be user-relevant if you do :-)
[13:45] <cjwatson> [php-html-quickform-advmultiselect] no need to have stamp files for configure/build targets that don't do anything; the targets could just be empty
[13:45] <dholbach> [php-html-quickform-advmultiselect] in debian/examples I'd change HTML_QuickForm_advmultiselect-1.5.1/examples/* to HTML_QuickForm_advmultiselect-*/examples/* to not have to update it for every release
[13:45] <pleia2> [php-html-quickform-advmultiselect] specifically the S one? I think you're right, this looks like a mistake
[13:46] <cjwatson> [php-html-quickform-advmultiselect] that's the sort of thing that happens if you make a typo in the package name in debian/control, and then correct it without first running debuild clean
[13:46] <cjwatson> BTDTGTTS
[13:46] <dholbach> [php-html-quickform-advmultiselect] you can remove the usr/share/php/.registry/.channel.doc.php.net/ directory from the package
[13:47] <pleia2> [php-html-quickform-advmultiselect] sneaky dot files, good catch
[13:48] <cjwatson> any more for any more? I think we're coming close to the end of the currently open reviews
[13:48] <dholbach> [php-html-quickform-advmultiselect] the debian/watch file does not work - for php-html-quickform I used "http://pear.php.net/package/HTML_QuickForm http://download.pear.php.net/package/HTML_QuickForm-([\d.RC]+).tgz"
[13:48] <dutchie> [suvat] I've uploaded it, might take a few minutes to show up
[13:49] <dholbach> [php-html-quickform-advmultiselect] pleia2: who are you working with in Debian to get it included? :-)
[13:49]  * ideamonk is away: I'm busy
[13:50] <pleia2> [php-html-quickform-advmultiselect] dholbach: the debian php team in alioth, and seanius but he had the nerve to go on vacation ;)
[13:50] <dholbach> ah ok :)
[13:51] <dholbach> ok, do we have any more review requests?
[13:54] <dutchie> [suvat] OK, the upload is showing up now.
[13:54] <cjwatson> [suvat] did that ln -s in build: that was there before not turn out to be required, then?
[13:55] <dutchie> [suvat] not really
[13:57] <dutchie> [suvat] setup.py puts a .so in build/lib.$ARCH/ that needs to be in . to run the program, that was all
[13:57] <dholbach> We have ~3 minutes left in the session - are there any comments about the way how we ran the session today? Did you find it confusing, helpful, fun, great, 'orrible? :)
[13:58] <cjwatson> [suvat] ok, if you feel you need to add it back later then you can use an override_dh_auto_build: target; you need to build-depend on debhelper (>= 7.0.50) if you do that
[13:58] <dutchie> [suvat] is it otherwise ok as it is?
[13:59] <alourie|work> dholbach: great :-)
[13:59] <dholbach> so something we should repeat? :-)
[14:00] <dutchie> dholbach: definitely
[14:00] <dholbach> thanks a lot to the reviewers and those who plucked up the courage to put up their review request!
[14:00] <dholbach> have a great day!
[14:00] <pleia2> thanks!
[14:00] <cjwatson> thanks, everyone
[14:01]  * dholbach will put up the logs later on
[14:02] <seb128> thanks
[14:03] <ccm> lol, my firefox in karmic crashes every time i try to open http://lists.ubuntu.com
[14:03] <ccm> this is rather funny
[14:03] <seb128> works there
[14:03] <seb128> stacktrace?
[14:04] <ccm> firefox 3.0 also
[14:05] <ccm> sure its a plugin
[14:06] <juanje> thanks for the help, guys! :-)
[14:06] <ccm> seb128: just on it
[16:03] <Laney> wc
[16:03] <Laney> whoops