On Wed, Oct 19, 2016 at 09:40:41PM +0200, Maarten van Gompel wrote:
> 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.
;)
The "issues" were not coming from your changes, were instead latitant
there already; I think this is a great time as any to improve them all!
Besides, if you're newish to Debian packaging this is a in my experience
a great way to learn about some subtleness in this "job".
> 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.
You don't need to be shy about uploading new revisions of Debian
packages :D
And yes, indeed we are not in rush.
> > > * git://anonscm.debian.org/debian-science/packages/python-pynlpl.git
> > + 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?
It doesn't, but given that somebody went all the trouble of having the
dependency lists wrapped and otherwise sorted, I find a lot better
to have that list keep ordered.
I don't know cme, I know it does it, but somehow I can't get it to work
now; nonetheless `wrap-and-sort -a` does it.
> > + 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.
Those messages are of I(nfo) and P(edantic) level, not shown by default;
nonetheless is a great idea to enable them, as usually they show you
real issues that costs nothing to fix and improves the quality of your
package somehow (in this case better descriptions, spelling errors and
fix DEP-5 copyright, IMHO all worthwhile goals).
you can either learn to run lintian with a bunch of options
lintian -EIi --pedantic
or if you usually run lintian from your user you can add a ~/.lintianrc
file with something like
info=yes
display-info=yes
display-experimental=yes
pedantic=yes
show-overrides=no
color=always
(except that now looking again at the manpage I discovered ~/.lintianrc
is a deprecated path and I should insteaed use a path following the XDG
conventions (so it should be in ~/.config/lintian/lintianrc in my
case)).
Anyway, lintian(1) and lintian-info(1) contains resources for this
topic.
> I fixed the spelling error. The descriptions are very similar but there is an
> extra phrase "This is the Python x version".
The "not be phrased properly" is due to the trailing full stop; run
lintian-info -t to get more information, or just google the lintian tag
name. Also read
https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions
> What is wrong with the ordering?
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field
Quoting from that:
Multiple Files paragraphs are allowed. The last paragraph that
matches a particular file applies to it. More general paragraphs
should therefore be given first, followed by more specific
overrides.
That means that putting a 'Files: *' at the bottom makes all the
paragraphs above totally ignored while parsing.
Lintian can help you catch these cases (here is simple and I noticed it
by just looking at that, but there are clearly more complex cases).
> > * 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.
ok ^^
> > * 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.
That point (the binaries are unimportant) is possibly even one more
reasons to put them out of the python-* package (so people using the
library won't have the binaries).
But sure, feel free to ignore this for now (even if it really wouldn't
be overkill, it's just a matter of adding a new binary in d/control and
a couple of rm/mv/cp in d/rules).
Oh, I just noticed that commit f55a54cff439a530088b96b17bc34d74f810a73b
is referenced by 2 tags <debian/1.0.9>, <debian/1.0.9-1>. The first is
just bogus; the second please don't do them, unless you're really sure
that's what's going to end up in the archive. In my usual sponsoring
workflow I usually take care of adding the debian/ tag while uploading.
Can you remove those 2 tags from the repository?
Also, we really use our full name in the author field usually (see
`git config --global user.name`) :)
> > > * 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?
'lib' is used nowhere but the in the git repository name, also the
source package is called without 'lib' (the binaries are, because that's
convention).
To have this situation normalized would require to rename the repository
in alioth (and possibly leaving a symlink where the current one is?).
Do you think this would be a worthwhile thing to do?
> Updated
(uh, no need to thank me in all entries! ;))
>
> > * 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/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!
Anytime!
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature