Re: RFS: ocropus (3nd try)
Hi Sandro,
Apologies for the delay in making the changes.
Thanks for looking at the package.
2008/11/10 Sandro Tosi <matrixhasu@gmail.com>:
> - please remove "XS-DM-Upload-Allowed" field (that should be called
Done.
> - "Document" in short description should be uncapitalized: think at it
> like <package> is a <short description>
Done.
> - 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
Done.
> - please explain what OCR is in the long description, so that even
> un-experienced users may understand what the package does
Done.
> - in long description "OCRopus is development is sponsored by Google"
> i think it's better "OCRopus development is sponsored by Google", what
> about?
Yup. Done.
> - you don't usually need "usr/bin" in debian/dirs (it's usually
> created by install steps)
Done.
> - 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
Done.
> - please add a debian/watch file, "man uscan" for examples
I don't think this is possible for software hosted by Google
> - 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).
That one passed me by. Thanks for pointing it out. Done.
> - 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)?
I've just discovered that you can put comments # at the top of a quilt
patch and refresh respects them. Done.
> - 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
> target
OK. I think I've done what you want.
> - you can merge the "rm -f" lines into dh_clean call (they do the same thing)
Done.
> - do you need dh_installexamples and dh_install in binary-arch target ?
Moved to the install target.
> - please indent the "upstream authors" section in debian/copyright by
> 4 spaces, and expand (or remove) "... and several others."
Done.
> - License section is indeed the copyright one
Sorry - what is your point here?
> - please add the correct license section, referring to apache-2.0,
> adding the apache license boilerplate (as visible in
> ./ocrocmd/version.h)
Done.
> - 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
> code.
Done.
> - you completely missed to add information about "External Software"
> in debian/copyright
What do you mean by this?
> - 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.
licensecheck -r --copyright * only finds Apache-2 or unknown.
> what about creating a "ocropus-common" package to contain all those
> architecture independent files?
Done.
I've uploaded the package again.
Regards
Jeff
Reply to: