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

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



Hi,




>done. thanks for the hint.

>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


wonderful

>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


yes, but I fail to see why you should override CPPFLAGS anyway :)

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


ack
>Not sure about how much important is this issue (says pedantic).
>
>Perhaps I should consider another way to publish the tarball...


you can publish the tarball as always, just sign it in a tarball.gpg or whatever
detached file.

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


how upstream builds the archive is not a Debian problem :)
I mean, use your favourite way, just don't change it too often to avoid
debian/watch file broken

you can also use gitattributes to automagically ignore stuff to export in the tarball
e.g.

http://anonscm.debian.org/cgit/pkg-boinc/scripts.git/tree/export-boinc?id=ec52f711cc6d1e3aafdfd9e98b2a941aa602080b


with github as soon as you do a git tag and you push the tag, the tarball is created.
>Thanks. Finally, I solved like this:
>
>override_dh_auto_build:
>    cd po; make update-po; cd ..


I would have done:
override_dh_auto_build:
    dh_auto_build
    $(MAKE) -C po update-po

but it is the same


>Is not strictly required for running eviacam.
>The build works fine in both cases.

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


oh well, isn't it automatically added by *:Depends somewhere?
you can leave it then


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


well, consider a person giving you a bug like

"the version X.Y crashes"

you might want them to install the dbg package and give you a stack trace with
some useful pointers inside.

but automatic debug packages are coming soon (TM) in Debian, so you can just avoid it
(although it is a nice learning experience)

cheers,

(sorry for the delay, let me know as soon as you have something on mentors, I guess this involves
a new upstream minor release or a bunch of debian/patches)

Gianfranco


Reply to: