Bug#799205: RFS: eviacam/2.0.1-5 [ITP] -- webcam based mouse emulator

[Gianfranco Costamagna <costamagnagianfranco@yahoo.it>]

Hi

>I will try the help2man approach


this is a string I used recently for another package
help2man -N -n "enhanced HTTPS support for httplib and urllib2 using PyOpenSSL" /usr/bin/ndg_httpclient --version-string=v0.4.0 > ndg_httpclient.1

>The code overrides the CPPFLAGS thus, not sure if I have to change anything.


I see

#CPPFLAGS="$CPPFLAGS $COMPFLAGS"
CPPFLAGS="$COMPFLAGS"
#CXXFLAGS="$CXXFLAGS $COMPFLAGS"
CXXFLAGS="$COMPFLAGS"

commit fc42432855a02c6881199ff09eef95e84db43345
Author: Cesar Mauri <cesar@crea>
Date:   Tue Mar 8 20:29:04 2011 +0100

Fixed compilation flags to produce a debuggable in debug mode


well, I guess maybe you didn't apply correctly the patch?

I would like to understand the rationale for that commit!

>>I: eviacam: arch-dep-package-has-big-usr-share 6205kB 84%
>
>Could you provide some hints on how to split the package.


maybe by providing an eviacam-doc package, because I bet the
6MB are because of the documentation.

But well, it isn't too much, you can also just don't care

(just think about small systems, where space matters, but I'm not
sure they will run a webcam)


>> P: eviacam source: debian-watch-may-check-gpg-signature
>
>I'll take a look


this is about gpg signing the releases, but I'm not sure sf supports
that

>Being the upstream developer I would prefer to avoid having to patch the tarball.
>Perhaps I could fix the remaining issues, bump the upstream version number and
>then upload the (right) tarball. What do you think?


yes, but I hope you will considering having the Debian packaging in a different branch
that way you are not forced to do a new upstream release at each Debian upload.
(that might be just because of a packaging issue)


also other linux distros might not like the Debian directory :)


>I completely agree with this, much better if I don't need to distribute
>auto-generated files. However, I tried removing the .gmo files from the
>tarball but after that, the .mo files were missing in the binary package.
>
>Could you please provide some hint here?


I guess override_dh_auto_build:
    dh_auto_build
and here generate them
#         for i in `ls po`; do \
#            msgfmt -o "po/$$i.mo" \
#             "po/$$i.po"; \

#           fi; \
#         done; \


or just generate them in your Makefile.am or whatever

you can also use pocompile if needed, just add the required build-dependency.



last two issues:
"Recommends: wx3.0-i18n"

can you please clarify? is that required or not? does the build work with or without?
does it increase the user experience?

and... what about having a dbg package too?

cheers,

G.