Re: Sponsor upload needed for updated packages: python-pynlpl, libticcutils, libfolia, uctodata, ucto
Hi Mattia,
Thanks for your very extensive review of the packages. I didn't really expect
that many issues to pop up considering the few changes, and I'm fairly new to
debian packaging, but I'll go through them.
> Note that the freeze that will happen on the 5th of November is a
> transition request deadline, you simply can't do library transitions
> after that date; the actual freeze where no updates to testing can
> happen will be 2017-Feb-05 (with various other softer freezes before);
> see https://release.debian.org/ (section "Key release dates").
Thanks, it wasn't entirely clear to me what freeze does what, so I guess that
means we're not too rushed. I was planning on doing about 4 package updates per
year, assuming upstream has new releases of course.
> btw, I'd personally be happier with just package names, if they are
> already in the archive I can just debcheckout(1) them, if they are ITPs
> I still already know where to look for them; furthermore git:// is a so
> bad protocol, other than being read-only whilst I may be interested in
> pushing too (but for this I have rules in my ~/.gitconfig to translate
> most common alioth's addresses to git+ssh:// URIs).
Ok, these are all updates to existing packages, so no ITPs, my first release
were mostly sponsored by Anton Gladky not too long ago.
> > * git://anonscm.debian.org/debian-science/packages/python-pynlpl.git
>
> * d/control:
> + "Testsuite: autopkgtest" is not needed: dpkg-source already adds it
> to the .dsc when it detects a d/tests/control file
removed
> + trailing whitespaces at line 33 and 50
fixed
> + build-deps not really sorted (see wrap-and-sort(1) or
> `cme fix-dpkg-control` (or somesuch, I don't use cme myself))
I ran cme fix dpkg-control but it didn't change it. Does the order matter?
> + I: python-pynlpl source: duplicate-short-description python-pynlpl python3-pynlpl
> + description-synopsis-might-not-be-phrased-properly
> * d/copyright:
> + the order is wrong, and also lintian complains about this with
> unused-file-paragraph-in-dep5-copyright
> + spelling-error-in-copyright Containts Contains
Is the above from Lintian? I'm a bit confused because mine didn't output all this.
I fixed the spelling error. The descriptions are very similar but there is an
extra phrase "This is the Python x version".
What is wrong with the ordering?
> * d/python3-pynlpl.manpages:
> + why not just using a wildcard with 'debian/manpages/*' insted of
> linsting everything? (just a question, I'm fine with it as it is)
Because I didn't know I could do that :) I'll leave it and rather be explicit
though.
> + I: python3-pynlpl: spelling-error-in-manpage usr/share/man/man1/pynlpl-computepmi.1.gz occuring occurring
fixed (my lintian didn't report this either though)
> * what about bumping the compat level to 10? (you'd gain automatic
> parallel building)
Sure, bumped to 10 now.
> * d/python-pynlpl.lintian-overrides + "python3-pynlpl: library-package-name-for-application"
> + IMHO the best solution for this would be to move the binaries and
> the manpages to a 'pynlpl' binary package in Section:science, and
> keeep the python libraries in Section:python (where they should be);
> maybe in the future though.
It's a bit of a constructed solution yeah. However, the few executables in pynlpl
are extremely unimportant and mostly unused, packaging it separately would be
overkill. It's the library that counts.
> > * git://anonscm.debian.org/debian-science/packages/libticcutils.git
>
> why this repository name doesn't match the source package name?!?
Good point, upstream it's called 'ticcutils' but it is purely a C++ library, so the
lib prefix was used for debian. Is changing Source at this point a good idea even?
> * d/changelog:
> + trailing whitespaces at line 2
Fixed
> + you didn't document a bunch of changes, please be comprehensive in
> the changelog
> * d/control:
> + please use https in Vcs-Git, and the cgit frontend in Vcs-Browser;
> bonus point for using https with /git/ for both (i.e. same address
> in both fields)
Updated
> + the name of the -dev package contains the libary SONAME (the version
> number, I mean). That's usually a bad idea, possibly consider
> renaming it to remove the number one day in the future.
Hmm.. I inherited it like this yes, I don't know too much about library
versioning conventions in Debian yet.
> * d/copyright:
> + same ordening problem
(ok, same question)
> + GPL-3+ is duplicate, that needs a separated standalone license
> paragraph
> + now I notice it's not following the DEP-5 at all. It's very near
> though, can you finish the "rewrite"?
Hmm.. I wonder why my lintian doesn't complain then. I did see similar messages
before. I tried to update it now.
> * d/libticcutils1-dev.install
> + this binary doesn't exist, please delete the file
> * d/libticcutils1.install
> + ditto
Right, removed
> * d/*
> + i don't get what that commit in the first line of nearly all files
> is doing there
The comment you mean? No idea, legacy stuff, I removed it now.
> * d/rules
> + cdbs :(
> this seems to be a pretty standard package, I'd be very happy to see
> it using dh (maybe with compat level 10, which would do autoreconf
> without specifying anything else (but I'm fine with it as it is now
> if maybe the other maintainer prefers it that way).
I don't really know much about this so can't really comment.
I'll continue with the remaining three packages later, probably friday, thanks
for all the help!
Regards,
--
Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen
proycon@anaproy.nl
http://proycon.anaproy.nl
http://github.com/proycon
GnuPG key: 0x1A31555C
XMPP: proycon@anaproy.nl Matrix: @proycon:anaproy.nl
Telegram: proycon IRC: proycon (freenode)
Twitter: https://twitter.com/proycon
Bitcoin: 1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd
Reply to: