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
