RFS: eviacam

[Cesar Mauri]

Dear mentors,

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

* Package name: eviacam
  Version : 1.5.2
  Upstream Author : Cesar Mauri 
* URL : http://viacam.org
* License : GPL
  Section : x11

It builds these binary packages:
eviacam- A cross platform webcam based mouse emulator

My main motivation for maintaining this software is due to the
lack of a full featured, well maintained replacement.

Enable Viacam (aka eViacam) is a mouse replacement software that
moves the pointer as you move your head. It works on standard
computer equipped with a web camera. No additional hardware is
required. Based on the award winning Facial Mouse software.

Launched in 2008, it is a mature and actively maintained project
whose main purpose is to provide an alternative access method
for people with disabilities.  In fact some of its contributors
are actual users of the software.

I was able to fix most Lintian errors and warnings, but I feel that to 
fix the remaining warnings I would need some help.


W: eviacam source: non-native-package-with-native-version
W: eviacam source: empty-debian-diff

The upload would fix bug: 634840

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/e/eviacam
- Source repository: deb-src http://mentors.debian.net/debian unstable 
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_1.5.2.dsc


- Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634840

I would be glad if someone uploaded this package for me.

Please, answer me in CC.

Kind regards
 Cesar Mauri


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e26f84b@crea-si.com

Re: RFS: eviacam

[Luke Yelavich]

On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:
> Hi,
> 
> I've managed to upload eviacam again to mentors site and appears to be
> lintian clean.
> 
> http://mentors.debian.net/package/eviacam

Hey folks. We in the Ubuntu desktop team have been contacted by Cesar once
again about getting this into Ubuntu and Debian. It seems that this was
left by the wayside back in 2011. Such things often happen, but perhaps
we can take another look, ahd hoefully get a DD to sponsor this.

Seems this URL doesn't take me to a page where I can download the package
and have a look. Cesar, do you have a recent revision of this package
anywhere? I am not a DD, but I am happy to take a look and comment on how
ready it is for upload to Debian.

Luke

Re: RFS: eviacam

[Cesar Mauri]

Hi Luke and all,

I uploaded source packages for the latest upstream version (2.0.1) here 
[1]. Source code repo here [2].


[1] https://mentors.debian.net/package/eviacam
[2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/

Cesar

El 16/09/2015 a las 2:10, Luke Yelavich escribió:

On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:

Hi,

I've managed to upload eviacam again to mentors site and appears to be
lintian clean.

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

Hey folks. We in the Ubuntu desktop team have been contacted by Cesar once
again about getting this into Ubuntu and Debian. It seems that this was
left by the wayside back in 2011. Such things often happen, but perhaps
we can take another look, ahd hoefully get a DD to sponsor this.

Seems this URL doesn't take me to a page where I can download the package
and have a look. Cesar, do you have a recent revision of this package
anywhere? I am not a DD, but I am happy to take a look and comment on how
ready it is for upload to Debian.

Luke

Re: RFS: eviacam

[Gianfranco Costamagna]

Hi Cesar, please open an RFS bug and fix the lintian stuff shown on mentors.d.o 
page.

+ Buildsystem: Package uses debhelper with an old compatibility level

– Package uploaded for the unreleased distribution

– Watch file is not present


after that I'll have a look at it.

cheers,

G.




Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha 
scritto:
Hi Luke and all,

I uploaded source packages for the latest upstream version (2.0.1) here 
[1]. Source code repo here [2].

[1] https://mentors.debian.net/package/eviacam
[2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/

Cesar


El 16/09/2015 a las 2:10, Luke Yelavich escribió:
> On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:
>> Hi,
>>
>> I've managed to upload eviacam again to mentors site and appears to be
>> lintian clean.
>>
>> http://mentors.debian.net/package/eviacam
> Hey folks. We in the Ubuntu desktop team have been contacted by Cesar once
> again about getting this into Ubuntu and Debian. It seems that this was
> left by the wayside back in 2011. Such things often happen, but perhaps
> we can take another look, ahd hoefully get a DD to sponsor this.
>
> Seems this URL doesn't take me to a page where I can download the package
> and have a look. Cesar, do you have a recent revision of this package
> anywhere? I am not a DD, but I am happy to take a look and comment on how
> ready it is for upload to Debian.
>
> Luke

Re: RFS: eviacam

[Cesar Mauri]

Hi Gianfranco (and all),

I just filled a RFS bug [1]. Package seems know to be lintian clean (version 
2.0.1-5).

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

Thanks for the support.

Regards,

Cesar


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

Hi Cesar, please open an RFS bug and fix the lintian stuff shown on mentors.d.o 
page.

+ Buildsystem: Package uses debhelper with an old compatibility level

– Package uploaded for the unreleased distribution

– Watch file is not present


after that I'll have a look at it.

cheers,

G.




Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha 
scritto:
Hi Luke and all,

I uploaded source packages for the latest upstream version (2.0.1) here
[1]. Source code repo here [2].

[1] https://mentors.debian.net/package/eviacam
[2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/

Cesar


El 16/09/2015 a las 2:10, Luke Yelavich escribió:

On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:

Hi,

I've managed to upload eviacam again to mentors site and appears to be
lintian clean.

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

Hey folks. We in the Ubuntu desktop team have been contacted by Cesar once
again about getting this into Ubuntu and Debian. It seems that this was
left by the wayside back in 2011. Such things often happen, but perhaps
we can take another look, ahd hoefully get a DD to sponsor this.

Seems this URL doesn't take me to a page where I can download the package
and have a look. Cesar, do you have a recent revision of this package
anywhere? I am not a DD, but I am happy to take a look and comment on how
ready it is for upload to Debian.

Luke

Re: RFS: eviacam

[Alex Vong]

Hi Cesar,

It is early in the morning and I have spot "Debhelper compatibility
level 7" in  but I believe
the latest "Debhelper compatibility level" is "9". Perhaps you should
try
$ echo 9 > debian/compat
and adding
Build-Depends: debhelper (>= 9)
to debian/control
and see if the package works nice with the latest "compatibility level".

Cheers,
Alex

2015-09-17 3:38 GMT+08:00, Cesar Mauri :
> Hi Gianfranco (and all),
>
> I just filled a RFS bug [1]. Package seems know to be lintian clean (version
> 2.0.1-5).
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799205
>
> Thanks for the support.
>
> Regards,
>
> Cesar
>
>
> El 16/09/2015 a las 18:39, Gianfranco Costamagna escribió:
>> Hi Cesar, please open an RFS bug and fix the lintian stuff shown on
>> mentors.d.o page.
>>
>> + Buildsystem: Package uses debhelper with an old compatibility level
>>
>> – Package uploaded for the unreleased distribution
>>
>> – Watch file is not present
>>
>>
>> after that I'll have a look at it.
>>
>> cheers,
>>
>> G.
>>
>>
>>
>>
>> Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha
>> scritto:
>> Hi Luke and all,
>>
>> I uploaded source packages for the latest upstream version (2.0.1) here
>> [1]. Source code repo here [2].
>>
>> [1] https://mentors.debian.net/package/eviacam
>> [2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/
>>
>> Cesar
>>
>>
>> El 16/09/2015 a las 2:10, Luke Yelavich escribió:
>>> On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:
 Hi,

 I've managed to upload eviacam again to mentors site and appears to be
 lintian clean.

 http://mentors.debian.net/package/eviacam
>>> Hey folks. We in the Ubuntu desktop team have been contacted by Cesar
>>> once
>>> again about getting this into Ubuntu and Debian. It seems that this was
>>> left by the wayside back in 2011. Such things often happen, but perhaps
>>> we can take another look, ahd hoefully get a DD to sponsor this.
>>>
>>> Seems this URL doesn't take me to a page where I can download the
>>> package
>>> and have a look. Cesar, do you have a recent revision of this package
>>> anywhere? I am not a DD, but I am happy to take a look and comment on
>>> how
>>> ready it is for upload to Debian.
>>>
>>> Luke
>
>

Re: RFS: eviacam

[Cesar Mauri]

Hi Alex,

Thanks for your support.

I followed your instructions and it seems to work fine on my debian jessie box.

However, I'm not sure how to share the updated package. I mean, do I have to 
remove and upload the (updated) package again without touching the version number? 
Or perhaps, is it better to bump the version number (i.e. 2.0.1-5 -> 2.0.1-6)?

Regards,

Cesar

El 17/09/2015 a las 3:28, Alex Vong escribió:

Hi Cesar,

It is early in the morning and I have spot "Debhelper compatibility
level 7" in  but I believe
the latest "Debhelper compatibility level" is "9". Perhaps you should
try
 $ echo 9 > debian/compat
and adding
 Build-Depends: debhelper (>= 9)
to debian/control
and see if the package works nice with the latest "compatibility level".

Cheers,
Alex

2015-09-17 3:38 GMT+08:00, Cesar Mauri :

Hi Gianfranco (and all),

I just filled a RFS bug [1]. Package seems know to be lintian clean (version
2.0.1-5).

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

Thanks for the support.

Regards,

Cesar


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

Hi Cesar, please open an RFS bug and fix the lintian stuff shown on
mentors.d.o page.

+ Buildsystem: Package uses debhelper with an old compatibility level

– Package uploaded for the unreleased distribution

– Watch file is not present


after that I'll have a look at it.

cheers,

G.




Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha
scritto:
Hi Luke and all,

I uploaded source packages for the latest upstream version (2.0.1) here
[1]. Source code repo here [2].

[1] https://mentors.debian.net/package/eviacam
[2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/

Cesar


El 16/09/2015 a las 2:10, Luke Yelavich escribió:

On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:

Hi,

I've managed to upload eviacam again to mentors site and appears to be
lintian clean.

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

Hey folks. We in the Ubuntu desktop team have been contacted by Cesar
once
again about getting this into Ubuntu and Debian. It seems that this was
left by the wayside back in 2011. Such things often happen, but perhaps
we can take another look, ahd hoefully get a DD to sponsor this.

Seems this URL doesn't take me to a page where I can download the
package
and have a look. Cesar, do you have a recent revision of this package
anywhere? I am not a DD, but I am happy to take a look and comment on
how
ready it is for upload to Debian.

Luke







--
César Mauri Loba
CREA Sistemes Informàtics
+34 685817309

AVISO LEGAL: Este mensaje y sus archivos adjuntos van dirigidos exclusivamente 
a su destinatario, pudiendo contener información
confidencial sometida a secreto profesional. No está permitida su comunicación, 
reproducción o distribución sin la autorización
expresa de CESAR MAURI LOBA. Si usted no es el destinatario final, por favor 
elimínelo e infórmenos por esta vía.

De acuerdo con la LOPD, le informamos que los datos personales y dirección de 
correo electrónico, recabados del
propio interesado o de fuentes públicas, formarán parte de un fichero 
responsabilidad de CESAR MAURI LOBA, siendo
la finalidad del mismo el envío de comunicaciones sobre nuestros productos y 
servicios. Si lo desea, podrá usted
ejercitar los derechos de acceso, rectificación, cancelación y oposición de sus 
datos dirigiéndose a la dirección
Carrer Sant Isidre, 4 - 2 C CONSTANTÍ (TARRAGONA) o enviando un mensaje al 
correo electrónico ce...@crea-si.com.

LEGAL NOTICE: This message and any attachments are intended exclusively for 
their destination and may contain
confidential information subject to professional secrecy. Is not permitted 
their communication, reproduction
or distribution without the express written permission of CESAR MAURI LOBA. If 
you are not the intended recipient,
please delete and inform us by this route.
According to the LOPD, we inform you that the personal information and email 
address, obtained from the data subject
or of public sources, will be part of a file of CESAR MAURI LOBA, with the 
finality of it send communications about
our products and services. If you wish, you may exercise your rights of access, 
rectification, cancellation and
opposition of their data by contacting the address Carrer Sant Isidre, 4 - 2 C 
43120 CONSTANTÍ (TARRAGONA) or by
sending an email to ce...@crea-si.com.

Re: RFS: eviacam

[Gianfranco Costamagna]

Reuploading without changing the version number is completely fine on mentors.

Please don't bump the version number if the package never appeared on 
debian/unstable.

cheers,

G.




Il Giovedì 17 Settembre 2015 14:30, Cesar Mauri  ha scritto:
Hi Alex,

Thanks for your support.

I followed your instructions and it seems to work fine on my debian jessie box.

However, I'm not sure how to share the updated package. I mean, do I have to 
remove and upload the (updated) package again without touching the version 
number? Or perhaps, is it better to bump the version number (i.e. 2.0.1-5 -> 
2.0.1-6)?

Regards,

Cesar

El 17/09/2015 a las 3:28, Alex Vong escribió:
> Hi Cesar,
>
> It is early in the morning and I have spot "Debhelper compatibility
> level 7" in  but I believe
> the latest "Debhelper compatibility level" is "9". Perhaps you should
> try
>  $ echo 9 > debian/compat
> and adding
>  Build-Depends: debhelper (>= 9)
> to debian/control
> and see if the package works nice with the latest "compatibility level".
>
> Cheers,
> Alex
>
> 2015-09-17 3:38 GMT+08:00, Cesar Mauri :
>> Hi Gianfranco (and all),
>>
>> I just filled a RFS bug [1]. Package seems know to be lintian clean (version
>> 2.0.1-5).
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799205
>>
>> Thanks for the support.
>>
>> Regards,
>>
>> Cesar
>>
>>
>> El 16/09/2015 a las 18:39, Gianfranco Costamagna escribió:
>>> Hi Cesar, please open an RFS bug and fix the lintian stuff shown on
>>> mentors.d.o page.
>>>
>>> + Buildsystem: Package uses debhelper with an old compatibility level
>>>
>>> – Package uploaded for the unreleased distribution
>>>
>>> – Watch file is not present
>>>
>>>
>>> after that I'll have a look at it.
>>>
>>> cheers,
>>>
>>> G.
>>>
>>>
>>>
>>>
>>> Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha
>>> scritto:
>>> Hi Luke and all,
>>>
>>> I uploaded source packages for the latest upstream version (2.0.1) here
>>> [1]. Source code repo here [2].
>>>
>>> [1] https://mentors.debian.net/package/eviacam
>>> [2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/
>>>
>>> Cesar
>>>
>>>
>>> El 16/09/2015 a las 2:10, Luke Yelavich escribió:
 On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:
> Hi,
>
> I've managed to upload eviacam again to mentors site and appears to be
> lintian clean.
>
> http://mentors.debian.net/package/eviacam
 Hey folks. We in the Ubuntu desktop team have been contacted by Cesar
 once
 again about getting this into Ubuntu and Debian. It seems that this was
 left by the wayside back in 2011. Such things often happen, but perhaps
 we can take another look, ahd hoefully get a DD to sponsor this.

 Seems this URL doesn't take me to a page where I can download the
 package
 and have a look. Cesar, do you have a recent revision of this package
 anywhere? I am not a DD, but I am happy to take a look and comment on
 how
 ready it is for upload to Debian.

 Luke
>>
>>
>

-- 
César Mauri Loba
CREA Sistemes Informàtics
+34 685817309

AVISO LEGAL: Este mensaje y sus archivos adjuntos van dirigidos exclusivamente 
a su destinatario, pudiendo contener información
confidencial sometida a secreto profesional. No está permitida su comunicación, 
reproducción o distribución sin la autorización
expresa de CESAR MAURI LOBA. Si usted no es el destinatario final, por favor 
elimínelo e infórmenos por esta vía.

De acuerdo con la LOPD, le informamos que los datos personales y dirección de 
correo electrónico, recabados del
propio interesado o de fuentes públicas, formarán parte de un fichero 
responsabilidad de CESAR MAURI LOBA, siendo
la finalidad del mismo el envío de comunicaciones sobre nuestros productos y 
servicios. Si lo desea, podrá usted
ejercitar los derechos de acceso, rectificación, cancelación y oposición de sus 
datos dirigiéndose a la dirección
Carrer Sant Isidre, 4 - 2 C CONSTANTÍ (TARRAGONA) o enviando un mensaje al 
correo electrónico ce...@crea-si.com.

LEGAL NOTICE: This message and any attachments are intended exclusively for 
their destination and may contain
confidential information subject to professional secrecy. Is not permitted 
their communication, reproduction
or distribution without the express written permission of CESAR MAURI LOBA. If 
you are not the intended recipient,
please delete and inform us by this route.
According to the LOPD, we inform you that the personal information and email 
address, obtained from the data subject
or of public sources, will be part of a file of CESAR MAURI LOBA, with the 
finality of it send communications about
our products and services. If you wish, you may exercise your rights of access, 
rectification, cancellation and
opposition of their data by contacting the address Carrer Sant Isidre, 4 - 2 C 
43120 CONSTANTÍ (TARRAGONA) or by
sending an email to ce...@crea-si.com.

Re: RFS: eviacam

[Cesar Mauri]

I've reuploaded the (updated) package without changing the version number.

Regards,

Cesar

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

Reuploading without changing the version number is completely fine on mentors.

Please don't bump the version number if the package never appeared on 
debian/unstable.

cheers,

G.




Il Giovedì 17 Settembre 2015 14:30, Cesar Mauri  ha scritto:
Hi Alex,

Thanks for your support.

I followed your instructions and it seems to work fine on my debian jessie box.

However, I'm not sure how to share the updated package. I mean, do I have to 
remove and upload the (updated) package again without touching the version number? 
Or perhaps, is it better to bump the version number (i.e. 2.0.1-5 -> 2.0.1-6)?

Regards,

Cesar

El 17/09/2015 a las 3:28, Alex Vong escribió:

Hi Cesar,

It is early in the morning and I have spot "Debhelper compatibility
level 7" in  but I believe
the latest "Debhelper compatibility level" is "9". Perhaps you should
try
  $ echo 9 > debian/compat
and adding
  Build-Depends: debhelper (>= 9)
to debian/control
and see if the package works nice with the latest "compatibility level".

Cheers,
Alex

2015-09-17 3:38 GMT+08:00, Cesar Mauri :

Hi Gianfranco (and all),

I just filled a RFS bug [1]. Package seems know to be lintian clean (version
2.0.1-5).

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

Thanks for the support.

Regards,

Cesar


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

Hi Cesar, please open an RFS bug and fix the lintian stuff shown on
mentors.d.o page.

+ Buildsystem: Package uses debhelper with an old compatibility level

– Package uploaded for the unreleased distribution

– Watch file is not present


after that I'll have a look at it.

cheers,

G.




Il Mercoledì 16 Settembre 2015 18:22, Cesar Mauri  ha
scritto:
Hi Luke and all,

I uploaded source packages for the latest upstream version (2.0.1) here
[1]. Source code repo here [2].

[1] https://mentors.debian.net/package/eviacam
[2] https://sourceforge.net/p/eviacam/eviacam/ci/master/tree/

Cesar


El 16/09/2015 a las 2:10, Luke Yelavich escribió:

On Wed, Sep 07, 2011 at 05:36:47AM AEST, Cesar Mauri wrote:

Hi,

I've managed to upload eviacam again to mentors site and appears to be
lintian clean.

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

Hey folks. We in the Ubuntu desktop team have been contacted by Cesar
once
again about getting this into Ubuntu and Debian. It seems that this was
left by the wayside back in 2011. Such things often happen, but perhaps
we can take another look, ahd hoefully get a DD to sponsor this.

Seems this URL doesn't take me to a page where I can download the
package
and have a look. Cesar, do you have a recent revision of this package
anywhere? I am not a DD, but I am happy to take a look and comment on
how
ready it is for upload to Debian.

Luke









--
César Mauri Loba
CREA Sistemes Informàtics
+34 685817309

AVISO LEGAL: Este mensaje y sus archivos adjuntos van dirigidos exclusivamente 
a su destinatario, pudiendo contener información
confidencial sometida a secreto profesional. No está permitida su comunicación, 
reproducción o distribución sin la autorización
expresa de CESAR MAURI LOBA. Si usted no es el destinatario final, por favor 
elimínelo e infórmenos por esta vía.

De acuerdo con la LOPD, le informamos que los datos personales y dirección de 
correo electrónico, recabados del
propio interesado o de fuentes públicas, formarán parte de un fichero 
responsabilidad de CESAR MAURI LOBA, siendo
la finalidad del mismo el envío de comunicaciones sobre nuestros productos y 
servicios. Si lo desea, podrá usted
ejercitar los derechos de acceso, rectificación, cancelación y oposición de sus 
datos dirigiéndose a la dirección
Carrer Sant Isidre, 4 - 2 C CONSTANTÍ (TARRAGONA) o enviando un mensaje al 
correo electrónico ce...@crea-si.com.

LEGAL NOTICE: This message and any attachments are intended exclusively for 
their destination and may contain
confidential information subject to professional secrecy. Is not permitted 
their communication, reproduction
or distribution without the express written permission of CESAR MAURI LOBA. If 
you are not the intended recipient,
please delete and inform us by this route.
According to the LOPD, we inform you that the personal information and email 
address, obtained from the data subject
or of public sources, will be part of a file of CESAR MAURI LOBA, with the 
finality of it send communications about
our products and services. If you wish, you may exercise your rights of access, 
rectification, cancellation and
opposition of their data by contacting the address Carrer Sant Isidre, 4 - 2 C 
43120 CONSTANTÍ (TARRAGONA) or by
sending an email to ce...@crea-si.com.

Re: RFS: eviacam

[Paul Wise]

On Wed, Jul 20, 2011 at 5:46 PM, Cesar Mauri wrote:

> eviacam    - A cross platform webcam based mouse emulator
>
> My main motivation for maintaining this software is due to the
> lack of a full featured, well maintained replacement.
>
> Enable Viacam (aka eViacam) is a mouse replacement software that
> moves the pointer as you move your head. It works on standard
> computer equipped with a web camera.

You might want to send a copy of your RFS to the debian-accessibility
mailing list, people there might be interested in sponsoring this.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6ExceNLgi0a1LPWUorO0asA5sMb47Bi1795k=xcdm0...@mail.gmail.com

Re: RFS: eviacam

[Paul Gevers]

Hi Cesar,

Although I am no Debian Developer and can thus not sponsor your package,
I will have a look at your package somewhere soon.

As suggested by Paul Wise, cc'd the accessibility list (I am part of
that team) to let them know as well.

Paul

On 20-07-11 17:46, Cesar Mauri wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "eviacam".
> 
> * Package name: eviacam
>   Version : 1.5.2
>   Upstream Author : Cesar Mauri 
> * URL : http://viacam.org
> * License : GPL
>   Section : x11
> 
> It builds these binary packages:
> eviacam- A cross platform webcam based mouse emulator
> 
> My main motivation for maintaining this software is due to the
> lack of a full featured, well maintained replacement.
> 
> Enable Viacam (aka eViacam) is a mouse replacement software that
> moves the pointer as you move your head. It works on standard
> computer equipped with a web camera. No additional hardware is
> required. Based on the award winning Facial Mouse software.
> 
> Launched in 2008, it is a mature and actively maintained project
> whose main purpose is to provide an alternative access method
> for people with disabilities.  In fact some of its contributors
> are actual users of the software.
> 
> I was able to fix most Lintian errors and warnings, but I feel that to
> fix the remaining warnings I would need some help.
> 
> W: eviacam source: non-native-package-with-native-version
> W: eviacam source: empty-debian-diff
> 
> The upload would fix bug: 634840
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/e/eviacam
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/e/eviacam/eviacam_1.5.2.dsc
> 
> - Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634840
> 
> I would be glad if someone uploaded this package for me.
> 
> Please, answer me in CC.
> 
> Kind regards
>  Cesar Mauri
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: RFS: eviacam

[Paul Gevers]

As promised, here is my review.

> I am looking for a sponsor for my package "eviacam".
> 
> * Package name: eviacam
>   Version : 1.5.2
>   Upstream Author : Cesar Mauri 
> * URL : http://viacam.org
> * License : GPL

Version 3 or higher according to your copyright file.

>   Section : x11
> 
> It builds these binary packages:
> eviacam- A cross platform webcam based mouse emulator

For Debian it is not relevant that this software is cross platform. Also
the synopsis should not start with "A". I would suggest:
eviacom - webcam based mouse emulator

> I was able to fix most Lintian errors and warnings, but I feel that to
> fix the remaining warnings I would need some help.
> 
> W: eviacam source: non-native-package-with-native-version

This should be solved by adding a DEBIAN version to the version number
in your changelog. I.e. 1.5.2-1.

> W: eviacam source: empty-debian-diff

This is because your upstream package already includes the debian
directory and there are no changes to be put in the diff and you are
using source 1.0 (implicit). If you want to continue also distributing
the debian directory in the upstream release I strongly suggest using
source version 3.0 (quilt) to avoid problems with NMU's. See also
dpkg-source(1).

> Please, answer me in CC.

Done.

Further, my comments on your debian/* files:
changelog
- As mentioned above, include the Debian version in the first line
- Close your ITP bug in the first entry like so:
* Initial release (closes: #634840 )
- Please update the time stamp to something more appropriate

changelog.in
- Not sure if this will be useful in the future. You will most likely
  be editing the changelog manually (with the help of dch)

compat
- I believe ideas about which version should be used for new packages
  varies from sponsor to sponsor, but 7 or 8 is most common nowadays. Of
  course this influences your build dependencies.

control
- Your standards version is very old. The current version is 3.9.2.
  Check what you need to change, and update accordingly.
- Any reason for not having priority "optional"?
- Consider putting your Debian packaging in a VCS and add the
  appropriate tags
- I don't think it is appropriate to mention the website in the
  description. The "Homepage" field is made for this purpose.
- As mentioned above, improve the short description
- I am no native speaker but I believe "a software" is rather strange.
  If you want to improve the description you could ask on
  debian-l10n-engl...@lists.debian.org
- I don't have understanding of wx2, but do your recommends work, i.e.
  does the package find the right version, depending on the development
  package used in the build-depends?

copyright
- Not mandatory, but quite some sponsors want it: consider to change
  your copyright file to the DEP5 format [1].
- Please link to the versioned GPL in common-licenses.
- You did not include the copyright information of all the files. The
  copyright file MUST list all the copyright holders and all licenses
  of ALL files in your project.

dirs
- I don't think you need this with this content.

docs
- NEWS is empty, don't install it.
- Why install README.ca and not README.es?

rules
- I find the clean target a little strange, why copy the config.sub and
  config.guess there?
- Clean up commented lines
- Not sure, but I think quite some options in your ./configure line are
  added by the builder automatically.


Further comments:

Please include a watch file.

Your package is newer than the latest upstream release. As you are
upstream yourself, why didn't you create this new release yet?

The package FTBFS (fails to build from sourse) with the following error:
configure: error: Couldn't find linux/videodev.h nor libv4l1-videodev.h
Adding libv4l-dev to the build-depends helps to start building the
package. It would help to build your own packages in a clean environment
to check against such problems (and build in sid as well). Tools such as
pbuilder can help you there.

With libv4l-dev, it still FTBFS with the output as found below. The
complete output can be found here [2] (for a month).

Hope this helps to improve the package.

Paul
[1] http://dep.debian.net/deps/dep5/
[2] http://pastebin.com/FZStE1TJ

Making all in wxutil
make[3]: Entering directory `/tmp/buildd/eviacam-1.5.2/wxutil'
/bin/bash ../libtool --tag=CXX   --mode=compile i486-linux-gnu-g++
-DHAVE_CONFIG_H -I. -I..   -Wall -fexceptions -Wconversion
-I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6
-DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
-DNO_GCC_PRAGMA -I/usr/include/opencv   -pthread -I/usr/include/atk-1.0
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -DNDEBUG -O2  -Wall 

Re: RFS: eviacam

[Cesar Mauri]

Hi,


As promised, here is my review.


Thanks Paul for your thorough review! I (hopefully) managed to fix all 
the issues you pointed out. I uploaded an updated version to the mentors 
site which also appears to be lintian clean.


I hope that all these improvement will help to find an sponsor for eviacam.

More details are provided below.


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

* Package name: eviacam
   Version : 1.5.2
   Upstream Author : Cesar Mauri
* URL : http://viacam.org
* License : GPL


Version 3 or higher according to your copyright file.


Right.


   Section : x11

It builds these binary packages:
eviacam- A cross platform webcam based mouse emulator


For Debian it is not relevant that this software is cross platform. Also
the synopsis should not start with "A". I would suggest:
eviacom - webcam based mouse emulator


Updated debian/control


I was able to fix most Lintian errors and warnings, but I feel that to
fix the remaining warnings I would need some help.

W: eviacam source: non-native-package-with-native-version


This should be solved by adding a DEBIAN version to the version number
in your changelog. I.e. 1.5.2-1.


Done.


W: eviacam source: empty-debian-diff


This is because your upstream package already includes the debian
directory and there are no changes to be put in the diff and you are
using source 1.0 (implicit). If you want to continue also distributing
the debian directory in the upstream release I strongly suggest using
source version 3.0 (quilt) to avoid problems with NMU's. See also
dpkg-source(1).


OK. Switched to source version 3.0.


Further, my comments on your debian/* files:
changelog
- As mentioned above, include the Debian version in the first line
- Close your ITP bug in the first entry like so:
 * Initial release (closes: #634840 )
- Please update the time stamp to something more appropriate


Done.


changelog.in
- Not sure if this will be useful in the future. You will most likely
   be editing the changelog manually (with the help of dch)


changelog.in removed and left changelog alone.


compat
- I believe ideas about which version should be used for new packages
   varies from sponsor to sponsor, but 7 or 8 is most common nowadays. Of
   course this influences your build dependencies.


Set to 7


control
- Your standards version is very old. The current version is 3.9.2.
   Check what you need to change, and update accordingly.


Updated standards version to 3.9.1


- Any reason for not having priority "optional"?


None. Set priority from extra to optional.


- Consider putting your Debian packaging in a VCS and add the
   appropriate tags


Can you provide additional details about this?


- I don't think it is appropriate to mention the website in the
   description. The "Homepage" field is made for this purpose.


Fixed.


- As mentioned above, improve the short description


Done.


- I am no native speaker but I believe "a software" is rather strange.
   If you want to improve the description you could ask on
   debian-l10n-engl...@lists.debian.org


Changed "software" by "program"


- I don't have understanding of wx2, but do your recommends work, i.e.
   does the package find the right version, depending on the development
   package used in the build-depends?


Removed old dependency to wx2.6 which also generated the compilation 
error you point below.



copyright
- Not mandatory, but quite some sponsors want it: consider to change
   your copyright file to the DEP5 format [1].
- Please link to the versioned GPL in common-licenses.
- You did not include the copyright information of all the files. The
   copyright file MUST list all the copyright holders and all licenses
   of ALL files in your project.


Done


dirs
- I don't think you need this with this content.


Done. File removed.


docs
- NEWS is empty, don't install it.


Old (manually maintained in upstream) ChangeLog file renamed as NEWS 
file and added automatic ChangeLog generation from git



- Why install README.ca and not README.es?


Fixed. Now installs both.


rules
- I find the clean target a little strange, why copy the config.sub and
   config.guess there?


Removed.


- Clean up commented lines


Done.


- Not sure, but I think quite some options in your ./configure line are
   added by the builder automatically.


Not sure also.


Further comments:

Please include a watch file.


Included.


Your package is newer than the latest upstream release. As you are
upstream yourself, why didn't you create this new release yet?


Just in case the debianization triggers some changes in upstream.


The package FTBFS (fails to build from sourse) with the following error:
configure: error: Couldn't find linux/videodev.h nor libv4l1-videodev.h
Adding libv4l-dev to the build-depends helps to start building the
package. It would help to build your own packages in a clean environment
to check against such problems (and buil

Re: RFS: eviacam

[Kilian Krause]

Hi César,

On Tue, Jul 26, 2011 at 02:30:24PM +0200, Cesar Mauri wrote:
[...]
> >control
> >- Your standards version is very old. The current version is 3.9.2.
> >   Check what you need to change, and update accordingly.
> 
> Updated standards version to 3.9.1

Without futher review of the actual package: Why not to 3.9.2?


[...]
> >- Consider putting your Debian packaging in a VCS and add the
> >   appropriate tags
> 
> Can you provide additional details about this?

The VCS (version control system) for the Debian packaging would be the Svn,
Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly
alioth.debian.org is a good starting point if you've nowhere else that's
already publically offering your VCS tree.

[...]
> >rules
> >- I find the clean target a little strange, why copy the config.sub and
> >   config.guess there?
> 
> Removed.

I hope you changed that to autotools-dev use. Usually it's a sensible
default to use autotools-dev (e.g. dh --with autotools_dev) if your package
does use autotools.

[...]
> >- Not sure, but I think quite some options in your ./configure line are
> >   added by the builder automatically.
> 
> Not sure also.

See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact
details.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Cesar Mauri]

Hi,

Thanks Kilian for your feedback which helped me to improve the package. 
I've updated and uploaded it again to the mentors site. The package 
appears to be lintian clean.



[...]

Updated standards version to 3.9.1


Without futher review of the actual package: Why not to 3.9.2?


I had chosen that version to make lintian (stable version) happy.

OK. Changed to 3.9.2 (and updated lintian on my box to the latest version).


[...]

- Consider putting your Debian packaging in a VCS and add the
   appropriate tags


Can you provide additional details about this?


The VCS (version control system) for the Debian packaging would be the Svn,
Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly
alioth.debian.org is a good starting point if you've nowhere else that's
already publically offering your VCS tree.


I already use git on sf.net for upstream. May be the best approach is to 
adopt the scheme described here [1]. Isn't it?


[1] http://documentation.debian-projects.org/other/debian-packaging-git/


[...]

rules
- I find the clean target a little strange, why copy the config.sub and
   config.guess there?


Removed.


I hope you changed that to autotools-dev use. Usually it's a sensible
default to use autotools-dev (e.g. dh --with autotools_dev) if your package
does use autotools.


Finally I've decided to adopt the newer debian/rules format (shorter) 
and I've added the "--with autotools_dev" option.



[...]

- Not sure, but I think quite some options in your ./configure line are
   added by the builder automatically.


Not sure also.


See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact
details.


Not a problem any more with the new debian/rules format.

Best regards,

César Mauri


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2f3ca8.5080...@crea-si.com

Re: RFS: eviacam

[Kilian Krause]

Hi Cesar,

On Wed, Jul 27, 2011 at 12:16:08AM +0200, Cesar Mauri wrote:
> Thanks Kilian for your feedback which helped me to improve the
> package. I've updated and uploaded it again to the mentors site. The
> package appears to be lintian clean.

Thanks for your work!

I see however some LGPL undocumented in debian/copyright. Moreover you may
want to explain about why the SUID bit is required on eviacamloader in some
README.Debian or so and move the SUID bit setting including creating a
group to postinst so that you limit the impact to an acceptable minimum.
Having an open root access for everybody on a system is quite a bit
too generous IMHO.

Moreover you can release 1.5.2 on sf.net and update the latest pointer too
so that debian/watch will work ok.

Please ping me again once these are fixed.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Cesar Mauri]

Hi Kilian,

Thanks for your comments. I have (hopefully) addressed all the issues 
you pointed out. I have uploaded an updated version to the mentors site 
which appears to be lintian clean and pbuilds fine for sid. See below 
for additional details.



I see however some LGPL undocumented in debian/copyright.


Fixed. Added to debian/copyright


Moreover you may
want to explain about why the SUID bit is required on eviacamloader in some
README.Debian


Added README.Debian file saying why eviacamloader should be a SUID binary.


or so and move the SUID bit setting including creating a
group to postinst so that you limit the impact to an acceptable minimum.
Having an open root access for everybody on a system is quite a bit
too generous IMHO.


I don't like also having a SUID binary but it is the only way I found to 
raise the priority of the process. I've moved the "chmod" to the 
postinst script but I couldn't create a group to setuid to because the 
nice system call (see nice(2)) needs superuser privileges.


See README.Debian for additional details.


Moreover you can release 1.5.2 on sf.net and update the latest pointer too
so that debian/watch will work ok.


I've uploaded the source package to sf.net.


Please ping me again once these are fixed.


Here I'm :-)

Regards,

César


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e38bf3f.9060...@crea-si.com

Re: RFS: eviacam

[Kilian Krause]

Hi Cesar,

On Wed, Aug 03, 2011 at 05:23:43AM +0200, Cesar Mauri wrote:
> Thanks for your comments. I have (hopefully) addressed all the
> issues you pointed out. I have uploaded an updated version to the
> mentors site which appears to be lintian clean and pbuilds fine for
> sid. See below for additional details.

Thanks for your work!


[...]
> >or so and move the SUID bit setting including creating a
> >group to postinst so that you limit the impact to an acceptable minimum.
> >Having an open root access for everybody on a system is quite a bit
> >too generous IMHO.
> 
> I don't like also having a SUID binary but it is the only way I
> found to raise the priority of the process. I've moved the "chmod"
> to the postinst script but I couldn't create a group to setuid to
> because the nice system call (see nice(2)) needs superuser
> privileges.

I seem to have not expressed my idea correctly:
- Have your binary chmod 4750
- with uid 0 (thus the setUID) and 
- group "whateveryournewgroupname"

In debian/postinst that would look like:
chmod 4750 $BINARY
chown 0:$GID $BINARY

where $GID is the group id of the group you create in postinst.

That will make sure it gets the UID 0 correctly so that nice(2) will work ok
and also will make sure that only users of the group are allowed to execute
it.

Does that make sense for you?

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Cesar Mauri]

Hi Kilian,


[...]

or so and move the SUID bit setting including creating a
group to postinst so that you limit the impact to an acceptable minimum.
Having an open root access for everybody on a system is quite a bit
too generous IMHO.


I don't like also having a SUID binary but it is the only way I
found to raise the priority of the process. I've moved the "chmod"
to the postinst script but I couldn't create a group to setuid to
because the nice system call (see nice(2)) needs superuser
privileges.


I seem to have not expressed my idea correctly:
- Have your binary chmod 4750
- with uid 0 (thus the setUID) and
- group "whateveryournewgroupname"

In debian/postinst that would look like:
chmod 4750 $BINARY
chown 0:$GID $BINARY

where $GID is the group id of the group you create in postinst.

That will make sure it gets the UID 0 correctly so that nice(2) will work ok
and also will make sure that only users of the group are allowed to execute
it.

Does that make sense for you?


Got it! Before creating a new group, is there any previously existing 
group that would be suitable for such a job (i.e. that a common desktop 
user would be part of)?


I think that if we need to create a new group may be some non-expert 
users won't be able to run eviacam properly (i.e. they might fail to add 
their username to such group). Other options include:


i) ask the user whether to make eviacamloader SUID and explain that a 
new group is needed and such and such.
ii) completely get rid of the SUID thing at the expense of less 
responsiveness.


What do you think? Thanks.

Regards,

César


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e392f7e.4000...@crea-si.com

Re: RFS: eviacam

[Kilian Krause]

Hi Cesar,

On Wed, 2011-08-03 at 13:22 +0200, Cesar Mauri wrote:
> > [...]
> >>> or so and move the SUID bit setting including creating a
> >>> group to postinst so that you limit the impact to an acceptable minimum.
> >>> Having an open root access for everybody on a system is quite a bit
> >>> too generous IMHO.
> >>
> >> I don't like also having a SUID binary but it is the only way I
> >> found to raise the priority of the process. I've moved the "chmod"
> >> to the postinst script but I couldn't create a group to setuid to
> >> because the nice system call (see nice(2)) needs superuser
> >> privileges.
> >
> > I seem to have not expressed my idea correctly:
> > - Have your binary chmod 4750
> > - with uid 0 (thus the setUID) and
> > - group "whateveryournewgroupname"
> >
> > In debian/postinst that would look like:
> > chmod 4750 $BINARY
> > chown 0:$GID $BINARY
> >
> > where $GID is the group id of the group you create in postinst.
> >
> > That will make sure it gets the UID 0 correctly so that nice(2) will work ok
> > and also will make sure that only users of the group are allowed to execute
> > it.
> >
> > Does that make sense for you?
> 
> Got it! Before creating a new group, is there any previously existing 
> group that would be suitable for such a job (i.e. that a common desktop 
> user would be part of)?

None that would fit the requirements we have here IMHO.


> I think that if we need to create a new group may be some non-expert 
> users won't be able to run eviacam properly (i.e. they might fail to add 
> their username to such group). Other options include:
> 
> i) ask the user whether to make eviacamloader SUID and explain that a 
> new group is needed and such and such.

Can be done with debconf quite easily as:
a) Ask whether SUID should be activated
b) which users should be added to the group interactively

Please set sensible defaults so that you can also work with
DEBCONF_FRONTEND=noninteractive


> ii) completely get rid of the SUID thing at the expense of less 
> responsiveness.

If that's possible and doesn't limit core functionality it sounds like a
valid option. What downsides would that bring?

I think debconf as explained above together with properly adding a new
group and importing users through debconf would be a good thing.

-- 
Best regards,
Kilian


signature.asc
Description: This is a digitally signed message part

Re: RFS: eviacam

[Cesar Mauri]

Hi Kilian,


[...]
- Have your binary chmod 4750
- with uid 0 (thus the setUID) and
- group "whateveryournewgroupname"

In debian/postinst that would look like:
chmod 4750 $BINARY
chown 0:$GID $BINARY

where $GID is the group id of the group you create in postinst.

That will make sure it gets the UID 0 correctly so that nice(2) will work ok
and also will make sure that only users of the group are allowed to execute
it.
[...]



I think that if we need to create a new group may be some non-expert
users won't be able to run eviacam properly (i.e. they might fail to add
their username to such group). Other options include:

i) ask the user whether to make eviacamloader SUID and explain that a
new group is needed and such and such.


Can be done with debconf quite easily as:
a) Ask whether SUID should be activated


Done. Package uploaded.


b) which users should be added to the group interactively


I would need some help here. Can you point a good document (or better, 
an example) on how to interactively add users to a group using debconf?



Please set sensible defaults so that you can also work with
DEBCONF_FRONTEND=noninteractive


The default option is to *NOT* use SUID.


ii) completely get rid of the SUID thing at the expense of less
responsiveness.


If that's possible and doesn't limit core functionality it sounds like a
valid option. What downsides would that bring?


The core functionality is exactly the same. The only downside is that 
eviacam won't work as smooth as if it were running in high priority 
(i.e. the user might notice that the mouse pointer is less responsive 
when CPU load is high).



I think debconf as explained above together with properly adding a new
group and importing users through debconf would be a good thing.


Agreed. But some help needed :-). Thanks.

Regards,

César


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e39af06.9070...@crea-si.com

Re: RFS: eviacam

[Kilian Krause]

Hi César,

On Wed, Aug 03, 2011 at 10:26:46PM +0200, Cesar Mauri wrote:
> Hi Kilian,
> 
> >>>[...]
> >>>- Have your binary chmod 4750
> >>>- with uid 0 (thus the setUID) and
> >>>- group "whateveryournewgroupname"
> >>>
> >>>In debian/postinst that would look like:
> >>>chmod 4750 $BINARY
> >>>chown 0:$GID $BINARY
> >>>
> >>>where $GID is the group id of the group you create in postinst.
> >>>
> >>>That will make sure it gets the UID 0 correctly so that nice(2) will work 
> >>>ok
> >>>and also will make sure that only users of the group are allowed to execute
> >>>it.
> >>>[...]
> 
> >>I think that if we need to create a new group may be some non-expert
> >>users won't be able to run eviacam properly (i.e. they might fail to add
> >>their username to such group). Other options include:
> >>
> >>i) ask the user whether to make eviacamloader SUID and explain that a
> >>new group is needed and such and such.
> >
> >Can be done with debconf quite easily as:
> >a) Ask whether SUID should be activated
> 
> Done. Package uploaded.

Good!

The file debian/po/templates.pot has a lot of template headers still though.
Please fill in all fields that are still holding bogus data.

Regarding the activation I'd still vote for a group to be created and the
chmod to be 4750 if SUID and 0755 if not SUID. You may want to use
dpkg-statoverride for this to set both user:group and chmod permissions in
one line.

If you need a good template I'd need to dig among the last packages I have
reviewed. There was a really good postinst doing exactly this.

Your text then should also include the name of the group (probably eviacam)
and that the sysadmin should add users if they're supposed to use the
program.

> >b) which users should be added to the group interactively
> 
> I would need some help here. Can you point a good document (or
> better, an example) on how to interactively add users to a group
> using debconf?

I was thinking of the libc version asking for which processes need to be
restarted. Not sure though if that's useful considering that e.g. sudo
leaves this to the sysadmin too. I guess we can live with just the SUID-yes
and SUID-no question in debconf.


> >Please set sensible defaults so that you can also work with
> >DEBCONF_FRONTEND=noninteractive
> 
> The default option is to *NOT* use SUID.

Very good. ;-)

> >>ii) completely get rid of the SUID thing at the expense of less
> >>responsiveness.
> >
> >If that's possible and doesn't limit core functionality it sounds like a
> >valid option. What downsides would that bring?
> 
> The core functionality is exactly the same. The only downside is
> that eviacam won't work as smooth as if it were running in high
> priority (i.e. the user might notice that the mouse pointer is less
> responsive when CPU load is high).
> 
> >I think debconf as explained above together with properly adding a new
> >group and importing users through debconf would be a good thing.
> 
> Agreed. But some help needed :-). Thanks.

Hth. ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Cesar Mauri]

Hi Kilian,

Thanks for your review.


The file debian/po/templates.pot has a lot of template headers still though.
Please fill in all fields that are still holding bogus data.


Done. Also added Catalan and Spanish translations.

However, every time I run debconf-updatepo this file gets overwritten 
and so the headers. Is there a way to update this file without losing 
the headers?



Regarding the activation I'd still vote for a group to be created and the
chmod to be 4750 if SUID and 0755 if not SUID. You may want to use
dpkg-statoverride for this to set both user:group and chmod permissions in
one line.

If you need a good template I'd need to dig among the last packages I have
reviewed. There was a really good postinst doing exactly this.


I tried the dpkg-override way (I took mlocate package as reference) but 
I didn't find a proper way to reset ownership/permissions when the user 
chooses not SUID without resorting to chown/chmod commands. Thus I left 
the chown/chmod commands.



Your text then should also include the name of the group (probably eviacam)
and that the sysadmin should add users if they're supposed to use the
program.


Done.


b) which users should be added to the group interactively


I would need some help here. Can you point a good document (or
better, an example) on how to interactively add users to a group
using debconf?


I was thinking of the libc version asking for which processes need to be
restarted. Not sure though if that's useful considering that e.g. sudo
leaves this to the sysadmin too. I guess we can live with just the SUID-yes
and SUID-no question in debconf.


OK. Fine for me also.

Unfortunately, due to problems with mentors site (I've already contacted 
the support team to find a solution) I haven't been able to upload the 
new changes. Once the problems are sorted out I'll ping you again. In 
the meantime you might find the latest changes in the git repo

(sorry for the inconvenience):

http://eviacam.git.sourceforge.net/git/gitweb-index.cgi

Best regards!

Cesar


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e5428db.2010...@crea-si.com

Re: RFS: eviacam

[Jakub Wilk]

* Cesar Mauri , 2011-08-24, 00:25:
I tried the dpkg-override way (I took mlocate package as reference) but 
I didn't find a proper way to reset ownership/permissions when the user 
chooses not SUID without resorting to chown/chmod commands.  Thus I 
left the chown/chmod commands.


Running chown/chmod in a maintainer script on a file that is shipped by 
the binary package is (almost?) never the right thing to do. Please do 
use dpkg-statoverride.


I also took a look at the suid helper, and to be honest it doesn't look 
good:

- Exit codes of setuid and setgid are ignored. (Yes, then _can_ fail.)
- setuid and setgid are called in the wrong order. You should always 
call setgid first.
- Unless I'm missing something, calls to seteuid and setegid are 
redundant.


I would strongly advise you against including the helper in your 
package.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110824002043.ga1...@jwilk.net

Re: RFS: eviacam

[Cesar Mauri]

Jakub,

Thanks for your comments.


I tried the dpkg-override way (I took mlocate package as reference)
but I didn't find a proper way to reset ownership/permissions when the
user chooses not SUID without resorting to chown/chmod commands. Thus
I left the chown/chmod commands.


Running chown/chmod in a maintainer script on a file that is shipped by
the binary package is (almost?) never the right thing to do. Please do
use dpkg-statoverride.


OK, but how do I manage to reset ownership/permissions when the user 
chooses not SUID without using chown/chmod when e.g. running 
dpkg-reconfigure? That is to say, I cannot run:


dpkg-statoverride --update --remove /usr/bin/eviacamloader

May be using dh_fixperms?


I also took a look at the suid helper, and to be honest it doesn't look
good:
- Exit codes of setuid and setgid are ignored. (Yes, then _can_ fail.)


Fixed.


- setuid and setgid are called in the wrong order. You should always
call setgid first.


Fixed.


- Unless I'm missing something, calls to seteuid and setegid are redundant.


Right. In fact both seteuid and setegid are not needed at all so I 
removed them.



I would strongly advise you against including the helper in your package.


I am not terribly happy with such helper but is the only way I found to 
run the program in higher priority (note that as a mouse replacement 
responsiveness is important). Is there any alternative to raise the 
priority of the process without resorting to a SUID binary?


Thanks again for your useful comments.

Regards,

Cesar


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e54d52c.1020...@crea-si.com

Re: RFS: eviacam

[Cesar Mauri]

Hi,

I've managed to upload eviacam again to mentors site and appears to be 
lintian clean.


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

Thanks,

César

El 24/08/2011 0:25, Cesar Mauri escribió:

Hi Kilian,

Thanks for your review.


The file debian/po/templates.pot has a lot of template headers still
though.
Please fill in all fields that are still holding bogus data.


Done. Also added Catalan and Spanish translations.

However, every time I run debconf-updatepo this file gets overwritten
and so the headers. Is there a way to update this file without losing
the headers?


Regarding the activation I'd still vote for a group to be created and the
chmod to be 4750 if SUID and 0755 if not SUID. You may want to use
dpkg-statoverride for this to set both user:group and chmod
permissions in
one line.

If you need a good template I'd need to dig among the last packages I
have
reviewed. There was a really good postinst doing exactly this.


I tried the dpkg-override way (I took mlocate package as reference) but
I didn't find a proper way to reset ownership/permissions when the user
chooses not SUID without resorting to chown/chmod commands. Thus I left
the chown/chmod commands.


Your text then should also include the name of the group (probably
eviacam)
and that the sysadmin should add users if they're supposed to use the
program.


Done.


b) which users should be added to the group interactively


I would need some help here. Can you point a good document (or
better, an example) on how to interactively add users to a group
using debconf?


I was thinking of the libc version asking for which processes need to be
restarted. Not sure though if that's useful considering that e.g. sudo
leaves this to the sysadmin too. I guess we can live with just the
SUID-yes
and SUID-no question in debconf.


OK. Fine for me also.

Unfortunately, due to problems with mentors site (I've already contacted
the support team to find a solution) I haven't been able to upload the
new changes. Once the problems are sorted out I'll ping you again. In
the meantime you might find the latest changes in the git repo
(sorry for the inconvenience):

http://eviacam.git.sourceforge.net/git/gitweb-index.cgi

Best regards!

Cesar



--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e66764f.9000...@crea-si.com

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

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

[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

[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

[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

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

[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

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

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

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

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

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

[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

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

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

[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

[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

>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-1 [ITP] -- webcam based mouse emulator

[Alex Vong]

Hi everyone,

About the `hardening-no-fortify-functions' lintian warning, I use the
`debian/rule' template generated by dh_make and merges it with the
original `debian/rule' file. Now the warning goes away with the new
`debian/rule' file, which is in the attachment. Please try to see if
it works!

I will search the net and see if it is easy to separate the
documentation into another package.

Cheers,
Alex

2015-09-25 23:23 GMT+08:00, 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.
>


rules
Description: Binary data

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-1 [ITP] -- webcam based mouse emulator

[Cesar Mauri]

Hi Alex (and all),


About the `hardening-no-fortify-functions' lintian warning, I use the
`debian/rule' template generated by dh_make and merges it with the
original `debian/rule' file. Now the warning goes away with the new
`debian/rule' file, which is in the attachment. Please try to see if
it works!


I merged your changes. I builds fine and it seems that the lintian warning
is gone.

Thank you!

Regards, Cesar

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

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

[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

[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

[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

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

-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&Signed&Uploaded, 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,

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&Signed&Uploaded, thanks for the nice contribution to Debian!

cheers,

G.