[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 all,

I have separated arch-dep and arch-indep files into 2 packages, the
arch-dep package is called ``eviacam'' and the arch-indep package is
called ``eviacam-doc''.

Notice the ``eviacam-doc'' package only includes the files installed
in ``/usr/share/doc/eviacam/help'' directory and nothing else.

Gianfranco, could you please see is the solution I found correct? The
Debian documentation on this seems to be a bit lacking, I found the
solution on askubuntu
<http://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch>.

Besides, does anyone know what's wrong with the desktop file. Lintian
reports ``desktop-entry-lacks-keywords-entry'', but I cannot find
anything wrong with regard to the standard
<http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html>.

Happy weekend!

Cheers,
Alex

On 01/10/2015, Gianfranco Costamagna <costamagnagianfranco@yahoo.it> wrote:
> 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
>

Attachment: debian.tar.xz
Description: application/xz


Reply to: