RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex
Hi people, I'm kindly asking for overchecking/uploading of the following packages: /python-apps/packages/didjvu/tags/0.2.1-1/ initial release of 0.2.1 /python-apps/packages/djvusmooth/tags/0.2.8-2/ /python-apps/packages/ocrodjvu/tags/0.4.6-3 closes important bug #600539 in testing /python-apps/packages/pybtex/tags/0.14.1-1 new upstream release All packages are lintian clean. Thank you very much in advance, Daniel Stender -- http://www.danielstender.com/granthinam/ GPG key ID: 1654BD9C -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cd442c6.50...@danielstender.com
Re: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex
Hi Daniel (2010.11.05_19:45:42_+0200)
> I'm kindly asking for overchecking/uploading of the following packages:
As a not-yet-DD I can't upload, but here's a review.
First, we don't tag releases until they are uploaded. You can leave the
changelog entry as UNRELEASED, and the sponsor will fix that and tag on
upload.
> /python-apps/packages/didjvu/tags/0.2.1-1/initial release of 0.2.1
> Depends: ${misc:Depends}, ${python:Depends}, python-imaging, libdjvulibre21
> (>= 3.5.21), python-argparse
I'd suggest wrapping that (after every comma is quite neat).
argparse is part of the standard library in Python 2.7. A dependency on
python (>= 2.7) | python-argparse is probably preferable.
The description could probably be broken into a couple of shorter
paragraphs.
debian/copyright mentions jwilk, but not you. You should state the
licencing of your packaging.
debian/rules: Not a fan of dh $...@?
I'm guessing you misunderstood my message on this topic, as you are
totally avoiding the setup.py and using dh_install + dh_link to install
files.
Also, you BD on debhelper >= 7, but use an override, which requires
debhelper >= 7.0.50~.
I think the following debian/rules will do what you want (and you won't
need debian/install or debian/links any more):
#!/usr/bin/make -f
%:
dh $@
override_dh_auto_install:
dh_auto_install -- --install-lib /usr/share/didjvu
For new packages, you should probably consider using dh_python2 instead
of python-support. The eventual plan is to migrate all Python packages
to it.
> /python-apps/packages/djvusmooth/tags/0.2.8-2/
Predates you, but "djvusmooth is a graphical editor for DjVu
files, which allows to:" isn't correct English grammar. ..."which allows
one to" would be better.
You probably want to add yourself to debian/copyright (even if you
haven't made any significant modifications yet). This applies to all the
packages.
> /python-apps/packages/ocrodjvu/tags/0.4.6-3 closes important bug
> #600539 in testing
My previous argparse comment still applies, but this is aimed at squeeze
which doesn't have python2.7, so you don't need to do this yet (but
consider it for the trunk, please).
> /python-apps/packages/pybtex/tags/0.14.1-1new upstream release
I see some trailing whitespace in debian/changelog.
Mixed tabs and spaces in debian/postinst (naughty jwilk)
SR
--
Stefano Rivera
http://tumbleweed.org.za/
H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101105194624.gm29...@bach.rivera.co.za
Re: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex
On Nov 05, 2010, at 09:46 PM, Stefano Rivera wrote: >#!/usr/bin/make -f >%: > dh $@ [...] > >For new packages, you should probably consider using dh_python2 instead >of python-support. The eventual plan is to migrate all Python packages >to it. Which should be as easy as adding "--with python2" to the end of the dh line. -Barry signature.asc Description: PGP signature
Re: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex
* Stefano Rivera , 2010-11-05, 21:46: debian/rules: Not a fan of dh $...@? FWIW, I have nothing against dh $@, but I'm opposed to abuse of %-rules. #!/usr/bin/make -f %: dh $@ override_dh_auto_install: dh_auto_install -- --install-lib /usr/share/didjvu Now you need only to jump through a few hops to let the binary find the modules. ;> /python-apps/packages/ocrodjvu/tags/0.4.6-3 My previous argparse comment still applies, but this is aimed at squeeze which doesn't have python2.7, so you don't need to do this yet (but consider it for the trunk, please). It's been already "python (>= 2.7) | python-argparse" for a while, in both branches. That said, I'm not sure if this change was necessary at all. New python will surely "Provide: python-argparse", won't it? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105210134.ga5...@jwilk.net
Sponsors and ‘UNRELEASED’ suite (was: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex)
Moving this non-Python part of the discussion to ‘debian-mentors’. Stefano Rivera writes: > First, we don't tag releases until they are uploaded. You can leave the > changelog entry as UNRELEASED, and the sponsor will fix that and tag on > upload. Is this common practise among sponsors? I was under the impression that the maintainer should create the package exactly as it should be uploaded into Debian, and the sponsor can expect to make no modifications before re-building. So I always put the intended target suite in the changelog entry. If the above convention (the sponsor will change ‘UNRELEASED’ to the appropriate suite name before re-building) is common, is it documented anywhere? -- \ “From the moment I picked your book up until I laid it down I | `\was convulsed with laughter. Someday I intend reading it.” | _o__)—Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r5ezeafi.fsf...@benfinney.id.au
Re: Sponsors and ‘UNRELE ASED ’ suite (was: RFS: Didjvu, Djvusmooth, Ocrodjvu, Pybtex)
Hi Ben (2010.11.05_23:18:41_+0200) > Is this common practise among sponsors? It is for debian-python. I don't have any experience with other SVN-using teams. > If the above convention (the sponsor will change ‘UNRELEASED’ to the > appropriate suite name before re-building) is common, is it documented > anywhere? No idea about documentation, I've just been told to do this on the IRC channel. The closest is: * After upload, tag the latest revision running svn-buildpackage --svn-tag-only into 'package-foo' directory. from http://python-modules.alioth.debian.org/python-modules-policy.html Yes, it does mean the sponsoree has to state which suite is desired. But it saves on a lot of untagging and retagging in each round of review, and makes it a little easier to know the state of things when reading the repo. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105215758.gn29...@bach.rivera.co.za
