[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: ocropus (3nd try)

Hello Jeffrey,

On Sun, Nov 9, 2008 at 22:01, Jeffrey Ratcliffe
<jeffrey.ratcliffe@gmail.com> wrote:
> I am looking for a sponsor for my package "ocropus".

I'm giving the package a look, and here are my comments:

- please remove "XS-DM-Upload-Allowed" field (that should be called
"DM-Upload-Allowed", since it's official now), since it's something
usually asked by the sponsor after he/she is comfortable with your
"autonomous" work.

- "Document" in short description should be uncapitalized: think at it
like <package> is a <short description>

- I don't know if it's importa (but may exist some backoffice tool
that cares about uppercases), but I'd uncapitalize the email address
in the maintainer field

- please explain what OCR is in the long description, so that even
un-experienced users may understand what the package does

- in long description "OCRopus is development is sponsored by Google"
i think it's better "OCRopus development is sponsored by Google", what

- you don't usually need "usr/bin" in debian/dirs (it's usually
created by install steps)

- what about include in debian/ocroscript.1 the options listed at
http://sites.google.com/site/ocropus/documentation ? consider the
situation where a user has no net connection and still wants to use
ocroscript. And repeating the long description in the manpage adds no
information to the users: please expand it to be usefull and please
forward then upstream (so that they can include in the next release).

- please add a debian/watch file, "man uscan" for examples

- since you claim to be "Standards-Version: 3.8.0" and using a patch
system, you have to add a debian/README.source explaining how you
patch the upstream source code (for a quilt example, take a look at
matplotlib package).

- patches have no documentation about what they do; dpatch added a "#
DP: " line where you can explain what the patch does (along with other
information like the patch author), do you mind add such information
(to be clear about the patch scope)?

- given that "debian/patches/distclean" added some files to be deleted
by upstream distclean target, and "clean: unpatch" this means that the
patch is removed before clean target in debian/rules is called, hence
invalidating the patch. One solution could be add another target:

clean: clean-patched unpatch
clean-patched: patch-stamp
   <commands for the clean target>

- It's usually better depends on patch-stamp (or the exported quilt
variable, check man quilt) instead of patch, so please fix build-stamp

- you can merge the "rm -f" lines into dh_clean call (they do the same thing)

- do you need dh_installexamples and dh_install in binary-arch target ?

- please indent the "upstream authors" section in debian/copyright by
4 spaces, and expand (or remove) "... and several others."

- License section is indeed the copyright one

- please add the correct license section, referring to apache-2.0,
adding the apache license boilerplate (as visible in

- since you claim that your packaging is gplv3, and so are the patches
you wrote, are you sure that those patches can be applied to
apache-2.0 source code? please check. That's the reason we usually
suggest to license the packaging under the same license as upstream

- you completely missed to add information about "External Software"
in debian/copyright

- please check *every* source file: ./ocrocmd/version.h has a
different copyright year, and many others (2006-2008 seems to be the
right years); ./colib/nbest.h (and with it, many other) has different
copyright holder, and you have to list them in the debian/copyright
file; ext/lua/lua.h (and all the related files) has different
copyright holder and license: please add them too and check the
license is compatible with apache-2.0.
  I can continue with many other files: please check the whole
upstream tarball, *every* files, (I exec, from the root level, "find .
-type f -exec less {} \;") and report all the copyright and license
information differing from the "main" ones and whether they are
compatible each other.

- lintian reports some warning:

$ lintian -I ../pbuilder/result/ocropus_0.2*changes
I: ocropus source: debian-watch-file-is-missing
I: ocropus: arch-dep-package-has-big-usr-share 10924kB 78%

what about creating a "ocropus-common" package to contain all those
architecture independent files?

Please reply in case of questions and once you have uploaded an
updated package to mentors (no need to bump revision).

Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Reply to: