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

[Cesar Mauri]

Hi,

Great! Thank you Gianfranco and Alex for all your support!

Regards, Cesar

El 19/10/2015 a las 19:04, Gianfranco Costamagna escribió:

Hi,
Built, thanks for the nice contribution to Debian!

cheers,

G.

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

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Cesar,

> Running debuild after unpacking the tarball and the debian/
> directory works for me. Not sure how to reproduce this issue.
> 

http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.3-1/
buildlog

extract the tarball with the debian directory,
run dpkg-buildpackage -S -sa

then
pbuilder-dist sid create
pbuilder-dist sid build eviacam_version.dsc

and you will reproduce the issue.

Probably you are not running a clean sid environment.

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWJN3WAAoJEPNPCXROn13ZLicQALRd8ZM8Liem67s9Z9E1va/N
XlLPobdP4McQKzQ+NulKOOWijXJR3rKh9+F5lBcBaxv1qLUhIXiKvuzlaZeBcH10
opOXZZh80AUmwzFXaDo3RIaPuB86RSdFRc+F7LKpDzJcEzpRKrJnnhso7nMXGtd4
X7K0lgDt/aAo8jboavGa6zVXwGqGFj+2baMIrKH+GXB/2Mv44btwFRv9gGg6kj+q
I4SLwxFrVV4BAeQChKQu9eLv/MNUl0zntAu/vdrhvAiaY7TmKJrjG+//WmjocseV
aGSi9R/rIiLDfrERgjOKpWfvsxYcm6rWftMZ5nyC3CToSN40hfMDr9oCsg+6eqcX
Wf9hNT0A2wt502fVB8NjRW5+cLakDhvAIlCtTp407KDAPFhQt3LbuYTA51No4Z/1
fm/LXAt1UhYOz9dppg0bDzh8J1znCyhmI417cH3KtEDhnSH5Pw3zLz/xdHmJNved
EAm7EgjDGJGm8XC2R+FOIgYLU7QlRduYsY5wenXxoNCAk+nLztyR/g1i7SN/ybRu
xZ1hB21OTVDLQZeU2D/VUZibRDicvpK3sGeMZ8VE79JkNN8lWUDG3Vmy9kDl8xfn
VgXK/2T1oJEfF1Roo9FOldNpOz2QF0PXCPwkJZ0Tl8l4bEia4elbLqWrmmJwEre3
x6KByEUogc5PfHfSvjVM
=pucg
-END PGP SIGNATURE-

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

[Cesar Mauri]

Hi Gianfranco and all,


http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.3-1/
buildlog

extract the tarball with the debian directory,
run dpkg-buildpackage -S -sa

then
pbuilder-dist sid create
pbuilder-dist sid build eviacam_version.dsc

and you will reproduce the issue.

Probably you are not running a clean sid environment.


I've added the fix suggested by Alex and now

pbuilder-dist sid build eviacam_version.dsc

works fine for me.

Regards, Cesar

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

[Gianfranco Costamagna]

Hi,
Built, thanks for the nice contribution to Debian!

cheers,

G.





Il Lunedì 19 Ottobre 2015 17:43, Cesar Mauri  ha scritto:
Hi Gianfranco and all,

>> http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.3-1/
>> buildlog
>>
>> extract the tarball with the debian directory,
>> run dpkg-buildpackage -S -sa
>>
>> then
>> pbuilder-dist sid create
>> pbuilder-dist sid build eviacam_version.dsc
>>
>> and you will reproduce the issue.
>>
>> Probably you are not running a clean sid environment.
>>
I've added the fix suggested by Alex and now


pbuilder-dist sid build eviacam_version.dsc

works fine for me.

Regards, Cesar

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

[Cesar Mauri]

Hi,

Thanks both for your feedback.


First, if I try to build using debuild, I get the error
`dh_autoreconf: autoreconf -f -i returned exit code 1'. I think it is
because dh_autoreconf is running "naked" `autoreconf' instead of
`autogen.sh'. So I think the fix is to add the following entry into
debian/rule:

override dh_autoreconf:
dh_autoreconf ./autogen.sh
Running debuild after unpacking the tarball and the debian/ directory 
works for me. Not sure how to reproduce this issue.




Besides, if I try to re-build I get `dpkg-source: error:
unrepresentable changes to source'. Now I don't really know how to fix
since I don't know how translation works. Maybe Gianfranco could help?

I'm not sure which is the "correct" fix, but I presume the po files should be 
updated
"prior" to release the tarball, and not during the debian build (where the po 
should just
be compiled)

My fault. I forgot to run "make update-po" before generating the tarball.

Fixed and added a check to avoid forgetting about this in future.



I see some *.gmo files created and not deleted during clean, this should be 
fixed upstream or
with a simple
find po -name "*.gmo" -delete
in the dh_clean target
and also the "po/stamp-po" should be cleaned during clean,
and this seems to be an upstream issue too.
Currently, the tarball does not contain .gmo files, nor the 
"po/stamp-po". Anyway, the override_dh_clean now looks like this:


override_dh_clean:
debconf-updatepo
dh_clean
find po -name "*.gmo" -delete
-rm po/stamp-po



and please change
cd po; make update-po; cd ..


to "$(MAKE) -C po update-po"

but I'm pretty sure this is already done automatically.

So I would even drop the override_dh_auto_build targetw

Dropped and working properly :-)


Updated version available in mentors and sf.


Regards, Cesar

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

[Gianfranco Costamagna]

>

>I think Cesar has fixed almost all lintian warnings except the "too
>much arch independent data" warning, including the "keyword" keyword
>funny issue mentioned by Gianfranco. However, I see mainly 2 problems.
>First, if I try to build using debuild, I get the error
>`dh_autoreconf: autoreconf -f -i returned exit code 1'. I think it is
>because dh_autoreconf is running "naked" `autoreconf' instead of
>`autogen.sh'. So I think the fix is to add the following entry into
>debian/rule:
>
>override dh_autoreconf:
>dh_autoreconf ./autogen.sh
>
>Besides, if I try to re-build I get `dpkg-source: error:
>unrepresentable changes to source'. Now I don't really know how to fix
>since I don't know how translation works. Maybe Gianfranco could help?


I see some *.gmo files created and not deleted during clean, this should be 
fixed upstream or
with a simple
find po -name "*.gmo" -delete
in the dh_clean target

the other problem is that the timestamp of the po files gets updated during the 
build and 

this makes the source content change.

I'm not sure which is the "correct" fix, but I presume the po files should be 
updated
"prior" to release the tarball, and not during the debian build (where the po 
should just
be compiled)

--- eviacam-2.0.3.orig/po/ar.po
+++ eviacam-2.0.3/po/ar.po
@@ -2,7 +2,7 @@ msgid ""
msgstr ""
"Project-Id-Version: viacam 1.3.1\n"
"Report-Msgid-Bugs-To: ce...@crea-si.com\n"
-"POT-Creation-Date: 2015-09-24 15:52+0200\n"
+"POT-Creation-Date: 2015-10-10 11:12+0200\n"
"PO-Revision-Date: \n"
"Last-Translator: Hatim Alahmadi \n"
"Language-Team: Hatim Alahmadi \n"
@@ -590,7 +590,7 @@ msgstr ""
"ﻪﻟ ﺕﺮﻳﺩ ﺍﻼﺴﺘﻣﺭﺍﺭ؟"

#: src/wconfiguration.cpp:1747 src/wconfiguration.cpp:1882
-#: src/wconfiguration.cpp:2008 src/viacamcontroller.cpp:383
+#: src/wconfiguration.cpp:2008 src/viacamcontroller.cpp:385
#: src/cmotioncalibration.cpp:186
msgid "eViacam warning"
msgstr "ﺖﺣﺬﻳﺭ ﻢﻧ ﻒﻳﺍ ﻙﺎﻣ"





and please change
cd po; make update-po; cd ..


to "$(MAKE) -C po update-po"

but I'm pretty sure this is already done automatically.

So I would even drop the override_dh_auto_build target

and also the "po/stamp-po" should be cleaned during clean,
and this seems to be an upstream issue too.

cheers,

G.

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

[Alex Vong]

Hi everyone,

I think Cesar has fixed almost all lintian warnings except the "too
much arch independent data" warning, including the "keyword" keyword
funny issue mentioned by Gianfranco. However, I see mainly 2 problems.
First, if I try to build using debuild, I get the error
`dh_autoreconf: autoreconf -f -i returned exit code 1'. I think it is
because dh_autoreconf is running "naked" `autoreconf' instead of
`autogen.sh'. So I think the fix is to add the following entry into
debian/rule:

override dh_autoreconf:
dh_autoreconf ./autogen.sh

Besides, if I try to re-build I get `dpkg-source: error:
unrepresentable changes to source'. Now I don't really know how to fix
since I don't know how translation works. Maybe Gianfranco could help?

Cheers,
Alex

On 10/10/2015, Cesar Mauri  wrote:
> Hi
>
> Thanks for your feedback.
>
>>> 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 :)
> I recently changed CPPFLAGS to CXXFLAGS which I think is more appropriate
> (preprocessor flags vs. compiler flags). But frankly, I never fully mastered
> automake and friends so, not sure if it can be still improved.
>
>
>> you can publish the tarball as always, just sign it in a tarball.gpg or
>> whatever
>> detached file.
>> 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
> Now d/watch look like this:
>
> version=3
> opts=pgpsigurlmangle=s/$/.asc/
> http://sf.net/eviacam/eviacam_(.+)\.orig\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
> debian uupdate
>
> and
>
> uscan --debug --force-download
> dpkg-buildpackage -S -sa
>
> works  for me
>
>>> 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)
> I see. Perhaps we could wait for the automatic debug packages. In the
> meantime, if someone reports a crash, I could try to provide a debug
> package.
>
>
>> (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)
> Me too.  I have been busy lately.
>
> I've uploaded a new version (2.0.3) to mentors.
>
>
> Regards, Cesar
>
>

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

[Cesar Mauri]

Hi

Thanks for your feedback.


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

I recently changed CPPFLAGS to CXXFLAGS which I think is more appropriate 
(preprocessor flags vs. compiler flags). But frankly, I never fully mastered 
automake and friends so, not sure if it can be still improved.



you can publish the tarball as always, just sign it in a tarball.gpg or whatever
detached file.
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

Now d/watch look like this:

version=3
opts=pgpsigurlmangle=s/$/.asc/ 
http://sf.net/eviacam/eviacam_(.+)\.orig\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))
 debian uupdate

and

uscan --debug --force-download
dpkg-buildpackage -S -sa

works  for me


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)

I see. Perhaps we could wait for the automatic debug packages. In the meantime, 
if someone reports a crash, I could try to provide a debug package.



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

Me too.  I have been busy lately.

I've uploaded a new version (2.0.3) to mentors.


Regards, Cesar

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

[Gianfranco Costamagna]

Hi Alex,




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

>

seems good so far, you can see to some packages I maintain to find some bits
poedit and python-pyqtgraph.

the first builds a -common package, with the architecture-independent bits

while the seconds builds a -doc package, with the documentation files.

(note: the -doc packages usually have also a .docs and .doc-base file, look e.g.
to the python-pyqtgraph package)


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


well, this is a tag I had many troubles understanding a while ago.

the keyword missing is *exactly* the "Keyword" keyword.

well, lintian should explain it better, but I'm unsure lintian folks changed 
the description
(I asked this a while ago on irc IIRC and they acked the description was 
difficult to understand)



look e.g. to a patch for the desktop file
https://github.com/mate-desktop/caja/commit/764ae67a0b5dd61f04f3f5cd9bad58533ec4bce4


and to the link you posted above:
"
A list of strings which may be used in addition to other metadata to describe 
this entry. This can be useful e.g. to facilitate searching through entries. 
The values are not meant for display, and should not be redundant with the 
values of Name or GenericName. "

>
>Happy weekend!


you too!


Cheers,

Gianfranco
(I didn't see the package on mentors)

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

[Alex Vong]

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
.

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
.

Happy weekend!

Cheers,
Alex

On 01/10/2015, Gianfranco Costamagna  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
>


debian.tar.xz
Description: application/xz

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

[Gianfranco Costamagna]

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

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

[Cesar Mauri]

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

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

[Gianfranco Costamagna]

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

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

[Cesar Mauri]

Hi Gianfranco


I don't know which remaining issues you are talking about...


http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian

See below:


W: eviacam source: dep5-copyright-license-name-not-unique (paragraph at line 68)
W: eviacam source: dep5-copyright-license-name-not-unique (paragraph at line 92)
W: eviacam: old-fsf-address-in-copyright-file


Solved. Thanks Alex for your patch! :-)



I: eviacam: desktop-entry-lacks-keywords-entry 
usr/share/applications/eviacam.desktop
I: eviacam: spelling-error-in-binary usr/bin/eviacam appropiate appropriate
I: eviacam: spelling-error-in-binary usr/bin/eviacam Allows to Allows one to


Fixed.



W: eviacam: binary-without-manpage usr/bin/eviacam
W: eviacam: binary-without-manpage usr/bin/eviacamloader


I will try the help2man approach



I: eviacam: hardening-no-fortify-functions usr/bin/eviacam
I: eviacam: hardening-no-fortify-functions usr/bin/eviacamloader



about fortify you need to be sure the code doesn't override
CPPFLAGS CFLAGS and LDFLAGS (or uses them indeed)
IIRC that warning is about CPPFLAGS


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


I: eviacam: arch-dep-package-has-big-usr-share 6205kB 84%

Could you provide some hints on how to split the package.



P: eviacam source: debian-watch-may-check-gpg-signature


I'll take a look



anyway I can find one for you:

rm ../eviacam_2.0.1.orig.tar.gz uscan --debug --force-download
dpkg-buildpackage -S -sa

"dpkg-source: error: cannot represent change to po/ar.gmo: binary
file contents changed dpkg-source: error: add po/ar.gmo in
debian/source/include-binaries if you want to store the modified
binary in the debian tarball [...]

dpkg-source: error: cannot represent change to po/zh_TW.gmo: binary
file contents changed dpkg-source: error: add po/zh_TW.gmo in
debian/source/include-binaries if you want to store the modified
binary in the debian tarball dpkg-source: error: unrepresentable
changes to source dpkg-buildpackage: error: dpkg-source -b
eviacam-2.0.1 gave error exit status 2

"

you seem to have a different tarball from the upstream one.


Right



I suggest you to use the exact tarball as the one you download from
sf website, and add patches with debian/patches.


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?



In this case since they are because of translation issues you might
just remove them in clean target, and recreate them on build.

(dpkg-source gives a warning on deletion, but not an error).

Moreover recreating from source is the preferred Debian way of doing
things. (being able to recreate is mandatory, recreating is
preferred).


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?


Regards, Cesar

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

[Gianfranco Costamagna]

Hi Cesar,


>I go on with the remaining issues.



I don't know which remaining issues you are talking about...
anyway I can find one for you:

rm ../eviacam_2.0.1.orig.tar.gz
uscan --debug --force-download
dpkg-buildpackage -S -sa

"dpkg-source: error: cannot represent change to po/ar.gmo: binary file contents 
changed
dpkg-source: error: add po/ar.gmo in debian/source/include-binaries if you want 
to store the modified binary in the debian tarball
[...]

dpkg-source: error: cannot represent change to po/zh_TW.gmo: binary file 
contents changed
dpkg-source: error: add po/zh_TW.gmo in debian/source/include-binaries if you 
want to store the modified binary in the debian tarball
dpkg-source: error: unrepresentable changes to source
dpkg-buildpackage: error: dpkg-source -b eviacam-2.0.1 gave error exit status 2

"

you seem to have a different tarball from the upstream one.

I suggest you to use the exact tarball as the one you download from sf website, 
and add patches with debian/patches.

In this case since they are because of translation issues you might just remove 
them in clean target, and recreate them on build.

(dpkg-source gives a warning on deletion, but not an error).

Moreover recreating from source is the preferred Debian way of doing things.
(being able to recreate is mandatory, recreating is preferred).

But using the orig tarball with the same md5 hash is for me mandatory too :)

cheers,

G.

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

[Gianfranco Costamagna]

>
>
>Not sure how to change this. I think this string comes from here [1].
>
>[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634840


hint:
https://www.debian.org/Bugs/server-control#retitle

>OK. I want to maintain this feature available for win32 and manually builds. I 
>could add a switch to the ./configure script to disable this feature, but not 
>sure if this is the proper debian way. >What do you think?


a configure switch might be the best way, in case other linux distros want to 
package it too.

I'm fine with a Debian patch too, feel free to choose your favourite way
(a Debian patch for configure, that will be dropped on the next upstream 
release might be the best way)

but I don't know how much effort will it require, so if you have a better 
way... it is up to you!

cheers,

G.

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

[Gianfranco Costamagna]

I guess something like
(checked for override_dh_auto_configure: on codesearch.debian.net)

override_dh_auto_configure:
dh_auto_configure -- --disable-update

or something similar

cheers,

G.





Il Mercoledì 23 Settembre 2015 16:34, Cesar Mauri  ha 
scritto:
> hint:
> https://www.debian.org/Bugs/server-control#retitle

Done!


> a configure switch might be the best way, in case other linux distros want to 
> package it too.
>
> I'm fine with a Debian patch too, feel free to choose your favourite way
> (a Debian patch for configure, that will be dropped on the next upstream 
> release might be the best way)
>
> but I don't know how much effort will it require, so if you have a better 
> way... it is up to you!

For me it is fine the configure switch. Could you please provide a hint on how 
to invoke the configure script with the right flag from d/rules?

Regards, Cesar

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

[Cesar Mauri]

hint:
https://www.debian.org/Bugs/server-control#retitle


Done!


a configure switch might be the best way, in case other linux distros want to 
package it too.

I'm fine with a Debian patch too, feel free to choose your favourite way
(a Debian patch for configure, that will be dropped on the next upstream 
release might be the best way)

but I don't know how much effort will it require, so if you have a better 
way... it is up to you!


For me it is fine the configure switch. Could you please provide a hint on how 
to invoke the configure script with the right flag from d/rules?

Regards, Cesar

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

[Cesar Mauri]

I guess something like
(checked for override_dh_auto_configure: on codesearch.debian.net)

override_dh_auto_configure:
 dh_auto_configure -- --disable-update

or something similar


Worked like a charm :) No more check for updates under debian


I go on with the remaining issues.

Regards, Cesar

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

[Cesar Mauri]

Hi Gianfranco,

Thanks for your review.


maybe run "debconf-updatepo" in the clean target, to avoid forgetting of 
updating translations.




Done



nack :) you did it correctly, but that way dh_clean is never called :)

override_dh_clean:
 debconf-updatepo
 dh_clean


this is what I meant.


Got it. I hope now is done :)



"#634840 (wishlist): RFP: eviacam -- A cross platform webcam based mouse 
emulator"


can you please change it back to ITP?


Not sure how to change this. I think this string comes from here [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634840



eviacam (2.0.1-5) unstable; urgency=medium


well, you should call it 2.0.1-1, since it never has been in Debian before.
(you can upload the same version on mentors)


OK. Version set to 2.0.1-1



"check for updates"

well, this is mostly impossible for Debian packages, please patch it :)


OK. I want to maintain this feature available for win32 and manually builds. I 
could add a switch to the ./configure script to disable this feature, but not 
sure if this is the proper debian way. What do you think?



the package seems to be working really well! at least with my face :)


Great!


Regards, Cesar

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

[Gianfranco Costamagna]

nope, but maybe autogenerating one starting from help2man and pushing upstream 
might be worth the effort


about fortify you need to be sure the code doesn't override CPPFLAGS CFLAGS and 
LDFLAGS (or uses them indeed)

IIRC that warning is about CPPFLAGS


cheers,


G.

Sent from Yahoo Mail on Android

From:"Alex Vong" 
Date:Tue, 22 Sep, 2015 at 20:21
Subject:Bug#799205: RFS: eviacam/2.0.1-5 [ITP] -- webcam based mouse emulator

Hi Cesar and Gianfranco,

I have fixed 2 lintian warnings about `debian/copyright', it is in the
attachment. They are `dep5-copyright-license-name-not-unique' and
`old-fsf-address-in-copyright-file'. I think it would be great to
update the address of FSF in the source files as well.

I notice there are some extra warnings when I run:
    $ lintian -EviIL +pedantic ../*.changes

The most important onces are `hardening-no-fortify-functions' and
`binary-without-manpage'. I think `hardening-no-fortify-functions' has
to do with `dpkg-buildflags' in `debian/rules'. About man page, is it
essential?

Cheers,
Alex

2015-09-22 22:07 GMT+08:00, Gianfranco Costamagna
:


> Hi again,
> some lintian stuff
> http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian
>
> cheers,
>
>
> G.
>
>

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

[Alex Vong]

Hi Cesar and Gianfranco,

I have fixed 2 lintian warnings about `debian/copyright', it is in the
attachment. They are `dep5-copyright-license-name-not-unique' and
`old-fsf-address-in-copyright-file'. I think it would be great to
update the address of FSF in the source files as well.

I notice there are some extra warnings when I run:
$ lintian -EviIL +pedantic ../*.changes

The most important onces are `hardening-no-fortify-functions' and
`binary-without-manpage'. I think `hardening-no-fortify-functions' has
to do with `dpkg-buildflags' in `debian/rules'. About man page, is it
essential?

Cheers,
Alex

2015-09-22 22:07 GMT+08:00, Gianfranco Costamagna
:
> Hi again,
> some lintian stuff
> http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian
>
> cheers,
>
>
> G.
>
>


copyright
Description: Binary data

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

[Gianfranco Costamagna]

Hi Cesar,


>> maybe run "debconf-updatepo" in the clean target, to avoid forgetting of 
>> updating translations.

>
>Done


nack :) you did it correctly, but that way dh_clean is never called :)

override_dh_clean:
debconf-updatepo
dh_clean


this is what I meant.




"#634840 (wishlist): RFP: eviacam -- A cross platform webcam based mouse 
emulator"


can you please change it back to ITP?



eviacam (2.0.1-5) unstable; urgency=medium


well, you should call it 2.0.1-1, since it never has been in Debian before.
(you can upload the same version on mentors)

"check for updates"

well, this is mostly impossible for Debian packages, please patch it :)

the package seems to be working really well! at least with my face :)


cheers,

G.

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

[Cesar Mauri]

Hi Gianfranco,



the other stuff might be food

maybe run "debconf-updatepo" in the clean target, to avoid forgetting of 
updating translations.


Done



I've uploaded an updated version to mentors. I've also fixed some issues 
(missing .mo files in .deb, remove unneeded files and dependencies). The binary 
package builds and seem to run fine on debian jessie.


Regards, Cesar

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

[Gianfranco Costamagna]

Hi again,
some lintian stuff
http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian

cheers,


G.

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

[Cesar Mauri]

I've uploaded a new version which fixes the unversioned-copyright-format-uri 
warning

Regards,

Cesar

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

[Cesar Mauri]

Hi Gianfranco and Alex,

Thanks for your reviews. Hopefully, I've addressed most of the issues.


lets review:

d/changelog: please remove the space before ")"
d/rules: usually it is better to use dh-autoreconf instead of autotools-dev, 
because the first is a superset
(this means a change on control file too, and the drop of autotools-dev)
d/control: please run "wrap-and-sort" command, to sort dependencies


Done. dh-autoreconf worked without issues.



"Recommends: wx2.8-i18n" what?


It contains localization strings for the wx library. Should be required 
package, perhaps?



the whole wx2.8 is not in testing, please use wx3.0, otherwise your package 
won't be included in Stretch.


Updated dependencies to wx3.0 (was already working with this library)



d/copyright: missing sone GPL2 licenses



I removed some unneeded files from the orig.tar.gz and I added missing GPL2 
licenses



the other stuff might be food

maybe run "debconf-updatepo" in the clean target, to avoid forgetting of 
updating translations.


I use to run 'make deb-src' to generate the source package which already update 
translations.
I might take a look.



I grape the source from . I
think I find a problem with the build dependencies, the build
dependencies contain `libopencv-dev | libcv-dev'. I first choose to
install `libcv-dev', but I get a build failure. After that, I choose
to install `libopencv-dev' instead and everything works fine. So in
short, I think `libopencv-dev | libcv-dev' should be changed to
`libopencv-dev' in `debian/control' file.

Message to Cesar: I have just found out you are the upstream
developer, your program looks interesting to me!

Message to Gianfranco: Could be reproduce this? I am running Sid. I
remember Cesar mentioning he is running Jessie.




true story.


Perhaps you should add the directory containing `opencv.pc'
to the PKG_CONFIG_PATH environment variable
No package 'opencv' found
not found
configure: error: opencv is required.



apt-file search opencv.pc
libopencv-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/opencv.pc


so maybe the second dependency (alternative) is simply wrong as you said :)


I guess the 2nd dependency was wrong.

libopencv-dev depends on libcv-dev, so is enough with the first. I also removed 
other unneeded dependencies.


Updated package available at mentors.

Changes tracked at debian-review branch:
https://github.com/cmauri/eviacam/commits/debian-review


Regards

Cesar

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

[Gianfranco Costamagna]

Hi Alex,

>

>
>I grape the source from . I
>think I find a problem with the build dependencies, the build
>dependencies contain `libopencv-dev | libcv-dev'. I first choose to
>install `libcv-dev', but I get a build failure. After that, I choose
>to install `libopencv-dev' instead and everything works fine. So in
>short, I think `libopencv-dev | libcv-dev' should be changed to
>`libopencv-dev' in `debian/control' file.
>
>Message to Cesar: I have just found out you are the upstream
>developer, your program looks interesting to me!
>
>Message to Gianfranco: Could be reproduce this? I am running Sid. I
>remember Cesar mentioning he is running Jessie.



true story.


Perhaps you should add the directory containing `opencv.pc'
to the PKG_CONFIG_PATH environment variable
No package 'opencv' found
not found
configure: error: opencv is required.



apt-file search opencv.pc
libopencv-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/opencv.pc


so maybe the second dependency (alternative) is simply wrong as you said :)

cheers,

G.

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

[Alex Vong]

Hi everyone,

I grape the source from . I
think I find a problem with the build dependencies, the build
dependencies contain `libopencv-dev | libcv-dev'. I first choose to
install `libcv-dev', but I get a build failure. After that, I choose
to install `libopencv-dev' instead and everything works fine. So in
short, I think `libopencv-dev | libcv-dev' should be changed to
`libopencv-dev' in `debian/control' file.

Message to Cesar: I have just found out you are the upstream
developer, your program looks interesting to me!

Message to Gianfranco: Could be reproduce this? I am running Sid. I
remember Cesar mentioning he is running Jessie.

2015-09-18 21:32 GMT+08:00, Gianfranco Costamagna
:
> Hi Cesar,
>
> lets review:
>
> d/changelog: please remove the space before ")"
> d/rules: usually it is better to use dh-autoreconf instead of autotools-dev,
> because the first is a superset
> (this means a change on control file too, and the drop of autotools-dev)
> d/control: please run "wrap-and-sort" command, to sort dependencies
>
> "Recommends: wx2.8-i18n" what?
>
>
> the whole wx2.8 is not in testing, please use wx3.0, otherwise your package
> won't be included in Stretch.
>
> d/copyright: missing sone GPL2 licenses
>
>
> the other stuff might be food
>
> maybe run "debconf-updatepo" in the clean target, to avoid forgetting of
> updating translations.
>
> (note: I didn't do any full copyright review and build/testing).
>
> cheers,
>
> G.
>
>
>
>
>
>
> Il Venerdì 18 Settembre 2015 9:42, Cesar Mauri  ha
> scritto:
> I've uploaded a new version which fixes the unversioned-copyright-format-uri
> warning
>
>
> Regards,
>
> Cesar
>
>

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

[Gianfranco Costamagna]

Hi Cesar,

lets review:

d/changelog: please remove the space before ")"
d/rules: usually it is better to use dh-autoreconf instead of autotools-dev, 
because the first is a superset
(this means a change on control file too, and the drop of autotools-dev)
d/control: please run "wrap-and-sort" command, to sort dependencies

"Recommends: wx2.8-i18n" what?


the whole wx2.8 is not in testing, please use wx3.0, otherwise your package 
won't be included in Stretch.

d/copyright: missing sone GPL2 licenses


the other stuff might be food

maybe run "debconf-updatepo" in the clean target, to avoid forgetting of 
updating translations.

(note: I didn't do any full copyright review and build/testing).

cheers,

G.






Il Venerdì 18 Settembre 2015 9:42, Cesar Mauri  ha scritto:
I've uploaded a new version which fixes the unversioned-copyright-format-uri 
warning


Regards,

Cesar

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

[Gianfranco Costamagna]

yes, as explained on that link, section "Example header paragraph"

(I just copy-paste from there or from another package usually)





Il Giovedì 17 Settembre 2015 17:54, Cesar Mauri  ha scritto:
Hi Gianfranco,

Thanks for your feedback.

Before uploading a new version, could you please confirm that this is the right 
fix?

$ git diff debian/copyright
diff --git a/debian/copyright b/debian/copyright
index e48a7c9..0cbc23e 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://dep.debian.net/deps/dep5/
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/



Regards,
Cesar



El 17/09/2015 a las 17:16, Gianfranco Costamagna escribió:
> Hi, can you please fix also this lintian pedantic?
> P unversioned-copyright-format-uri
> http://dep.debian.net/deps/dep5/
>
> (sorry, due to lack of time I can't review it properly now)
>
> cheers,
>
> G.
>
>
>
> Il Mercoledì 16 Settembre 2015 20:57, Cesar Mauri  ha 
> scritto:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "eviacam":
>
> * Package name: eviacam
> Version : 2.0.1-5
> Upstream Author : Cesar Mauri 
> * URL : http://viacam.org
> * License : GPLv3
> Section : x11
>
> It builds those binary packages:
>
> eviacam - webcam based mouse emulator
>
> To access further information about this package, please visit the following 
> URL:
>
> http://mentors.debian.net/package/eviacam
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_2.0.1-5.dsc
>
> More information about hello can be obtained from http://viacam.org
>
> Changes since the last upload:
>
> eviacam (2.0.1-5) UNRELEASED; urgency=medium
>
> * Initial release (closes: #634840 )
>
>
> Regards,
> Cesar Mauri
>

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

[Cesar Mauri]

Hi Gianfranco,

Thanks for your feedback.

Before uploading a new version, could you please confirm that this is the right 
fix?

$ git diff debian/copyright
diff --git a/debian/copyright b/debian/copyright
index e48a7c9..0cbc23e 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://dep.debian.net/deps/dep5/
+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/



Regards,
Cesar


El 17/09/2015 a las 17:16, Gianfranco Costamagna escribió:

Hi, can you please fix also this lintian pedantic?
P unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5/

(sorry, due to lack of time I can't review it properly now)

cheers,

G.



Il Mercoledì 16 Settembre 2015 20:57, Cesar Mauri  ha 
scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "eviacam":

* Package name: eviacam
Version : 2.0.1-5
Upstream Author : Cesar Mauri 
* URL : http://viacam.org
* License : GPLv3
Section : x11

It builds those binary packages:

eviacam - webcam based mouse emulator

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/eviacam


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_2.0.1-5.dsc

More information about hello can be obtained from http://viacam.org

Changes since the last upload:

eviacam (2.0.1-5) UNRELEASED; urgency=medium

* Initial release (closes: #634840 )


Regards,
Cesar Mauri

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

[Gianfranco Costamagna]

Hi, can you please fix also this lintian pedantic?
P unversioned-copyright-format-uri
http://dep.debian.net/deps/dep5/

(sorry, due to lack of time I can't review it properly now)

cheers,

G.



Il Mercoledì 16 Settembre 2015 20:57, Cesar Mauri  ha 
scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "eviacam":

* Package name: eviacam
   Version : 2.0.1-5
   Upstream Author : Cesar Mauri 
* URL : http://viacam.org
* License : GPLv3
   Section : x11

It builds those binary packages:

   eviacam - webcam based mouse emulator

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/eviacam


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_2.0.1-5.dsc

More information about hello can be obtained from http://viacam.org

Changes since the last upload:

eviacam (2.0.1-5) UNRELEASED; urgency=medium

* Initial release (closes: #634840 )


Regards,
Cesar Mauri

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

[Cesar Mauri]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "eviacam":

* Package name: eviacam
  Version : 2.0.1-5
  Upstream Author : Cesar Mauri 
* URL : http://viacam.org
* License : GPLv3
  Section : x11

It builds those binary packages:

  eviacam - webcam based mouse emulator

To access further information about this package, please visit the following 
URL:

http://mentors.debian.net/package/eviacam


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_2.0.1-5.dsc

More information about hello can be obtained from http://viacam.org

Changes since the last upload:

eviacam (2.0.1-5) UNRELEASED; urgency=medium

* Initial release (closes: #634840 )


Regards,
Cesar Mauri