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

[Cesar Mauri <cesar@crea-si.com>]

Hi,

> 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

done. thanks for the hint.


> 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?

Those lines are probably the result of some trials
that I forgot to cleanup :)

I tidied up a bit the configuration.ac and Makefile.am files


> I would like to understand the rationale for that commit!

The point of that commit was to add the debugging flags to the
compiler command line.

 if ! "$debug"; then
-	COMPFLAGS="$COMPFLAGS -DNDEBUG"
+	COMPFLAGS="$COMPFLAGS -DNDEBUG -O2"
+else
+	COMPFLAGS="$COMPFLAGS -DDEBUG -g -O0"
 fi


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

right


> 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)

OK. Then, let's leave it as is.


> > > P: eviacam source: debian-watch-may-check-gpg-signature
> this is about gpg signing the releases, but I'm not sure sf supports
> that

Not sure about how much important is this issue (says pedantic).

Perhaps I should consider another way to publish the tarball...

 
> > Perhaps I could fix the remaining issues, bump the upstream version
> > number and then upload the (right) tarball.
>
> 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 :)

Agreed. It will be better to keep the packaging files in a different branch.

Moreover, I'm also considering building the tarball directly from the
repository (i.e. using git-archive) instead of building it from sources.
The latter approach (the one I'm currently using) produces (slightly) different
tarballs for each run (due to changes in the atime of some files, I guess),
and so are the digital signatures

I tried with git-archive and it seems that it generate the very same
tarball given a specific commit (even tried cloning the repo).

However, I'm not sure if the git-archive approach has any downsides.
What do you think?


> 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.

Thanks. Finally, I solved like this:

override_dh_auto_build:
	cd po; make update-po; cd ..


> last two issues: "Recommends: wx3.0-i18n"
>
> can you please clarify? is that required or not?

Is not strictly required for running eviacam.


> does the build work with or without?

The build works fine in both cases.


> does it increase the user experience?

I think so. It provides localization for common strings
(e.g. 'Yes', 'No', 'Cancel', etc.)


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

I understand that a dbg package is "...useful if program crashes and you
want to generate stack trace..." [1]. But not sure who might take advantage
if this kind of package. I think that I need more information about this.

[1] https://wiki.debian.org/DebugPackage


Regards, Cesar