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#799813: RFS: snes9x [ITP] -- Cross-platform SNES emulator

[Sérgio Benjamim]

Hey Stephen,

Mednafen SNES is based on an old bsnes version (059), it seems it's 
faster than the current bsnes version but less accurate (it comes from a 
time that there's no performance/balanced/accuracy build). It does not 
have some LLE audio updates/improvements (problem with special games 
chips like Mega Man X series?).


http://emulation.gametechwiki.com/index.php/SNES

I bet it uses more resources than Snes9x.

Sergio Benjamim


On 23/09/2015 08:52, Stephen Kitt wrote:

Hi Sérgio,

On Tue, 22 Sep 2015 18:44:23 -0300, Sérgio Benjamim 
wrote:

Looking for a sponsor for this package:

* Package name : snes9x

[...]

* License  : non-free/non-commercial

[...]

It's worth to mention that Snes9x is more accurate than ZSNES and use less
hardware resources than bsnes.

How does it compare with Mednafen's SNES support?

Regards,

Stephen

Bug#799813: RFS: snes9x [ITP] -- Cross-platform SNES emulator

[Stephen Kitt]

Hi Sérgio,

On Tue, 22 Sep 2015 18:44:23 -0300, Sérgio Benjamim 
wrote:
> Looking for a sponsor for this package:
> 
> * Package name : snes9x
[...]
> * License  : non-free/non-commercial
[...]
> 
> It's worth to mention that Snes9x is more accurate than ZSNES and use less
> hardware resources than bsnes.

How does it compare with Mednafen's SNES support?

Regards,

Stephen


pgpX9xHtT_51t.pgp
Description: OpenPGP digital signature

Re: Modifying the environment variables of a parent process

[Gianfranco Costamagna]

Hi Markhazy,

first I guess this isn't the right place, but well, the damage is done :)




TLTR;
you have a cdiv code that gives in output two numbers, real and the imaginary 
part
you want to store them into bash variables.

so, why can't you do a simple bash script for doing this?

I see a trivial solution: get the return of the cvid program and store in a 
temp variable.

then split it.
user@user:-$ A=-1
user@user:-$ B=6
"cdiv $A 5 $B 0"
-0.16667 + j0.8333

so I would do something like

TEMP=`cdiv $A 5 $B 0`

or
TEMP=$(cdiv $A 5 $B 0)

note the special "`" character

AC=$(echo $TEMP  | cut -d "+" -f 1)
ACIM=$(echo $TEMP  | cut -d "+" -f 2)

if you want to strip the j
ACIM=$(echo $TEMP  | cut -d "+" -f 2 | cut -d "j" -f 2)

man cut
man echo

can help you :)

(of course this is a bad solution, a nicer solution might be to save the output 
in a file and parte is,
directly use some bash command to calculate that, e.g. some bc scripting [1] or 
even make your cdiv communicate with sockets, dbus or just by printing
output on more lines, to avoid the need to parse the output with bash)


[1] http://phodd.net/gnu-bc/code/complex.bc

HTH, even if I'm not sure I understood the question.

cheers,

G.

Re: Modifying the environment variables of a parent process

[Thomas Schmitt]

Hi,

Gianfranco Costamagna wrote:
> first I guess this isn't the right place, but well, the damage is done :)

Maybe we should move to debian-u...@lists.debian.org
if we discuss on. :))


Markhazy wrote:
> > the desired effect
> > user@user:-$ cdiv -1 5 6 0
> >-0.16667 + j0.8333
> > user@user:-$ echo $AC
> > -0.16667
> > user@user:-$ echo $ACIM
> > 0.8333

Parent environment is out of reach. At least by tradition.

Shell functions can set their caller's variables. 
How about this one decoding the output line of cdiv:

my_cdiv () {
  read AC plus_dummy ACIM <

Bug#799869: RFS: pyfftw/0.9.2+dfsg-4

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pyfftw"

* Package name: pyfftw
  Version : 0.9.2+dfsg-4
  Upstream Author : Henry Gomersall 
* URL : http://hgomersall.github.io/pyFFTW/
* License : BSD-3-clause
  Section : python

It builds those binary packages:

  python-pyfftw - Pythonic wrapper around FFTW - Python 2
  python-pyfftw-dbg - Pythonic wrapper around FFTW - Python 2 (debug)
  python3-pyfftw - Pythonic wrapper around FFTW - Python 3
  python3-pyfftw-dbg - Pythonic wrapper around FFTW - Python 3 (debug)

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


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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pyfftw/pyfftw_0.9.2+dfsg-4.dsc


Changes since the last upload:

  * Remove install dependency on the long-double version of FFTW on
arm{el,hf} architectures. (Closes: 799831)

Regards,
Ghislain Vaillant

Bug#799869: marked as done (RFS: pyfftw/0.9.2+dfsg-4)

[Debian Bug Tracking System]

Your message dated Wed, 23 Sep 2015 14:22:43 + (UTC)
with message-id <525162433.469696.1443018163971.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#799869: RFS: pyfftw/0.9.2+dfsg-4
has caused the Debian Bug report #799869,
regarding RFS: pyfftw/0.9.2+dfsg-4
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
799869: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799869
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pyfftw"

* Package name: pyfftw
  Version : 0.9.2+dfsg-4
  Upstream Author : Henry Gomersall 
* URL : http://hgomersall.github.io/pyFFTW/
* License : BSD-3-clause
  Section : python

It builds those binary packages:

  python-pyfftw - Pythonic wrapper around FFTW - Python 2
  python-pyfftw-dbg - Pythonic wrapper around FFTW - Python 2 (debug)
  python3-pyfftw - Pythonic wrapper around FFTW - Python 3
  python3-pyfftw-dbg - Pythonic wrapper around FFTW - Python 3 (debug)

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


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

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

  dget -x 
http://mentors.debian.net/debian/pool/main/p/pyfftw/pyfftw_0.9.2+dfsg-4.dsc


Changes since the last upload:

  * Remove install dependency on the long-double version of FFTW on
arm{el,hf} architectures. (Closes: 799831)

Regards,
Ghislain Vaillant
--- End Message ---
--- Begin Message ---
Built, thanks for your contribution to Debian!

next time, can you please try to fix the mips* build too? it should need just a 
tweak of the arm patch.

cheers,

G.




Il Mercoledì 23 Settembre 2015 16:09, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "pyfftw"

* Package name: pyfftw
   Version : 0.9.2+dfsg-4
   Upstream Author : Henry Gomersall 
* URL : http://hgomersall.github.io/pyFFTW/
* License : BSD-3-clause
   Section : python

It builds those binary packages:

   python-pyfftw - Pythonic wrapper around FFTW - Python 2
   python-pyfftw-dbg - Pythonic wrapper around FFTW - Python 2 (debug)
   python3-pyfftw - Pythonic wrapper around FFTW - Python 3
   python3-pyfftw-dbg - Pythonic wrapper around FFTW - Python 3 (debug)

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

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

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

   dget -x 
http://mentors.debian.net/debian/pool/main/p/pyfftw/pyfftw_0.9.2+dfsg-4.dsc

Changes since the last upload:

   * Remove install dependency on the long-double version of FFTW on
 arm{el,hf} architectures. (Closes: 799831)

Regards,
Ghislain Vaillant--- End Message ---

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1

[Bill Blough]

Thanks for your review.

I normally use uscan, so I haven't really thought about get-orig-source.  But
it seems like a good idea-  I'll look into adding it.

As for sf.net vs github, the project is in the process of changing hosting.
The old repo has commits disabled and all new development is being done on
github.  I expect the website links will be updated eventually.

Thanks again.

Bill

On Tue, Sep 22, 2015 at 10:45:35PM +0300, Eugene Zhukov wrote:
> Hi,
> I took a peek and didn't find get-orig-source in d/rules. d/watch has link to
> github, while pwsafe.org links to sourceforge.
> 

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

[Gianfranco Costamagna]

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

override_dh_auto_configure:
dh_auto_configure -- --disable-update

or something similar

cheers,

G.





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

Done!


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

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

Regards, Cesar

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

[Cesar Mauri]

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


Done!


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

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

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


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

Regards, Cesar

Bug#799615: RFS: netmask/2.4.0 - helps determine network masks

[Paul Wise]

On Sun, Sep 20, 2015 at 10:28 PM, Guilhem Moulin wrote:

> I am looking for a sponsor for my package "netmask"

I don't intend to sponsor this but here are some thoughts:

The source package should not be a native source package as netmask
isn't Debian specific.

Are buildflags.mk and override_dh_auto_build nessecary? Usually they
aren't for autoconf.

Is debian/info nessecary? Usually the upstream build system is
responsible for installing info documents.

The upstream NEWS file doesn't look very useful, I would suggest
asking upstream to rename the ChangeLog to NEWS (or just not
installing NEWS).

The upstream README file has an incorrect version number and claim
about initial public release in it, you might want to suggest upstream
to remove the version number from it.

Is debian/dirs nessecary? Usually the upstream build system and
debhelper automatically create those two dirs.

I would suggest adding a Homepage field pointing at the github page to
debian/control.

I would suggest adding a debian/watch file and a debian/upstream/metadata file.

https://wiki.debian.org/debian/watch
https://wiki.debian.org/UpstreamMetadata

I would suggest that upstream tag their releases and upload their
tarballs to github using the releases feature.

https://github.com/talby-/netmask/releases

I would suggest that upstream should remove from git all the files
generated or copied in by autotools.

Yourself and upstream might want to OpenPGP-sign git commits, git tags
and release tarballs:

http://mikegerwitz.com/papers/git-horror-story
https://help.riseup.net/en/security/message-security/openpgp/best-practices

This line in the upstream configure.in looks weird, usually -O only
goes up to 3:

: ${CFLAGS='-Wall -g -O6'}

Automatic checks:

build:

aclocal: warning: autoconf input should be named 'configure.ac', not
'configure.in'
automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'
configure.in:3: warning: AM_INIT_AUTOMAKE: two- and three-arguments
forms are deprecated.  For more info, see:
configure.in:3:
http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
automake: warning: autoconf input should be named 'configure.ac', not
'configure.in'

lintian:

X: netmask source: deprecated-configure-filename

check-all-the-things:

$ cme check dpkg
Warning in 'dirs:0' value 'usr/bin': Make sure that this directory is
actually needed. See
L
for details
Warning in 'dirs:1' value 'usr/share/doc/netmask': Make sure that this
directory is actually needed. See
L
for details

$ codespell --quiet-level=3
./ChangeLog:5: agressively  ==> aggressively
./config.sub:1276: nto  ==> not  | disable due to \n
./errors.c:29: compatability  ==> compatibility
./errors.c:45: compatability  ==> compatibility
./texinfo.tex:1101: openin  ==> opening
./texinfo.tex:2676: openin  ==> opening
./texinfo.tex:2685: openin  ==> opening
./texinfo.tex:3486: openin  ==> opening
./texinfo.tex:3515: openin  ==> opening
./texinfo.tex:5001: openin  ==> opening
./texinfo.tex:5145: openin  ==> opening
./netmask.c:35: occured  ==> occurred

$ cppcheck -j1 --quiet -f .
[netmask.c:168]: (error) Uninitialized variable: n

$ duck
E: debian/control: Vcs-Git: https://git.guilhem.org/netmask: ERROR
(Certainty:certain)
   fatal: unable to access 'https://git.guilhem.org/netmask/': server
certificate verification failed. CAfile:
/etc/ssl/certs/ca-certificates.crt CRLfile: none

$ fdupes -q -r .
./testdata.14
./testdata.15

./testdata.19
./testdata.23

./version.texi
./stamp-vti

$ licensecheck --check=. --recursive --copyright . | grep -i incorrect
./errors.h: GPL (v2 or later) (with incorrect FSF address)
./main.c: GPL (v2 or later) (with incorrect FSF address)
./missing: GPL (v2 or later) (with incorrect FSF address)
./mdate-sh: GPL (v2 or later) (with incorrect FSF address)
./errors.c: GPL (v2 or later) (with incorrect FSF address)
./texinfo.tex: GPL (v2 or later) (with incorrect FSF address)
./netmask.c: GPL (v2 or later) (with incorrect FSF address)

$ licensecheck --check=. --recursive --copyright . | grep -F 'GENERATED FILE'
./configure: GENERATED FILE
./Makefile.in: GENERATED FILE

$ suspicious-source
./netmask.info

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Splitting a source package with a new upstream version

[Christian Kastner]

On 2015-09-23 11:56, Jakub Wilk wrote:
> * Christian Kastner , 2015-09-22, 11:08:
>> 1. upload a 2.2.0 version of the library, with the Python bindings
>> dropped. python-pyfann currently has a versioned dependency on a
>> specific version of the library, libfann2 (=2.1.0~beta+dfsg-1).
>> Therefore, The library itself will not be upgradeable without breaking
>> or removing python-pyfann.
>> 2. Upload the Python bindings from the new upstream source, built
>> against the new version of the library
>> 3. After the bindings have passed NEW, both library and bindings
>> should be upgradeable smoothly.
> 
> Sounds good to me.

Thank you for the feedback!

> Although to minimize time when python-pyfann is uninstallable, you
> might want to do it in a different order: upload src:pyfann first, 
> wait until it's accepted, then upload src:libfann that no longer
> builds python-pyfann.

That is better indeed.

Regards,
Christian

Bug#799886: RFS: arrayfire/3.1.1+dfsg1-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "arrayfire"

* Package name: arrayfire
  Version : 3.1.1+dfsg1-2
  Upstream Author : ArrayFire Development Group
* URL : http://arrayfire.com/
* License : BSD
  Section : science

It builds those binary packages:

  libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend)
  libarrayfire-cpu3 - High performance library for parallel computing 
(CPU backend)

  libarrayfire-cpu3-dbg - Debugging symbols for ArrayFire (CPU backend)
  libarrayfire-doc - Common documentation for ArrayFire

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


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


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

  dget -x 
http://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.1.1+dfsg1-2.dsc


Changes since the last upload:

  * d/gbp.conf: use dfsg-clean branch as upstream branch.
  * Add upstream d/p/bugfix-cpuid-usage.patch, fixes FTBFS on several
architectures.

Regards,
Ghislain Vaillant

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1 [ITP] -- Simple & Secure Password Management

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #745126

PS:
The announcement about the move of the repositoriy to github is here:
https://sourceforge.net/p/passwordsafe/news/2015/08/passwordsafes-git-repository-moved-to-github/?limit=25

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1 [ITP] -- Simple & Secure Password Management

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #745126
Control: owner -1 !

Hi Bill,

I'll take a look tonight.

Tobi

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

systemd service unit causing lintian init issues

[Matt Zagrabelny]

Greetings,

I'm packaging up a firewall script that ships with a systemd service
unit file. lintian is complaining about an init script:

% lintian fw-skel_0.06-1_all.deb
W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel
%

There is, of course, no init script:

% dpkg-deb -c fw-skel_0.06-1_all.deb  | grep init
%

The postinst and prerm both reference an absent init script:

% dpkg-deb -e fw-skel_0.06-1_all.deb
% grep init DEBIAN/*
DEBIAN/postinst:# Automatically added by dh_installinit
DEBIAN/postinst:if [ -x "/etc/init.d/fw-skel" ]; then
DEBIAN/postrm:# Automatically added by dh_installinit
DEBIAN/prerm:# Automatically added by dh_installinit
DEBIAN/prerm:if [ -x "/etc/init.d/fw-skel" ]; then
%

It seems that dh-systemd is working in some capacity:

% dpkg-deb -c fw-skel_0.06-1_all.deb| grep systemd
drwxr-xr-x root/root 0 2015-09-23 15:18 ./lib/systemd/
drwxr-xr-x root/root 0 2015-09-23 15:18 ./lib/systemd/system/
-rw-r--r-- root/root   200 2015-09-23 15:18
./lib/systemd/system/fw-skel.service
%

I'm building this using a sid cowbuilder + gbp, FWIW.

Any ideas for keeping SysV init out of the postinst and friends?

Thanks!

-m

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1

[Tobias Frost]

Am Mittwoch, den 23.09.2015, 10:33 -0400 schrieb Bill Blough:
> Thanks for your review.
> 
> I normally use uscan, so I haven't really thought about get-orig
> -source.  But
> it seems like a good idea-  I'll look into adding it.
> 
> As for sf.net vs github, the project is in the process of changing 
> hosting.
> The old repo has commits disabled and all new development is being 
> done on
> github.  I expect the website links will be updated eventually.
> 
> Thanks again.
> 
> Bill
> 
> On Tue, Sep 22, 2015 at 10:45:35PM +0300, Eugene Zhukov wrote:
> > Hi,
> > I took a peek and didn't find get-orig-source in d/rules. d/watch 
> > has link to
> > github, while pwsafe.org links to sourceforge.
> > 
> 

Hi Bill,

- d/source/options: Why do you have the option diff-ignore?
- d/patches are marked as Forwarded: no and not-needed. Are they really
not upstreamable?
- please use wrap-and-sort; this will also remove those trailing
whitespaces I love to nitpick about...

- Well, README.LINUX does not really have information for the user
beside it's beta, so I'd not install it but explain in the package
description that not all features are implemented

- I would not install both the html and txt version of
docs/ReleaseNotes, they have identical content. Also, this seems to be
the project's changelog, so it should be installed with
dh_installchangelog and not via dh_installdocs. Therefore it should
also not be registered using doc-base

- d/menu should be depreciated in favour of .desktop files, so remove
this file. See also #741573

- the chm file you refer in your source override -- I guess  it is not
built at build time. We need to build everything from source... Can you
simply remove it? 

That's how far I come... Will continue as soon as possible

--
tobi

Bug#799900: RFS: node-cross-spawn-async/2.0.0-1 [ITP]

[Ross Gammon]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "node-cross-spawn-async"

* Package name: node-cross-spawn-async
  Version : 2.0.0-1
  Upstream Author : Nathan Rajlich  (http://n8.io/)
* URL : https://github.com/TooTallNate/util-deprecate
* License : Expat
  Section : web

It builds this binary package:

node-cross-spawn-async - Cross platform child_process#spawn

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

http://mentors.debian.net/package/node-cross-spawn-async


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

dget -x http://mentors.debian.net/debian/pool/main/n/node-cross-spawn-async
/node-cross-spawn-async_2.0.0-1.dsc

The packaging repository can be found here:
http://anonscm.debian.org/cgit/pkg-javascript/node-cross-spawn-async.git

Changes since the last upload:

  * Initial release (Closes: #796337)


Regards,
Ross Gammon



-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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

Re: Splitting a source package with a new upstream version

[Jakub Wilk]

* Christian Kastner , 2015-09-22, 11:08:
1. upload a 2.2.0 version of the library, with the Python bindings 
dropped. python-pyfann currently has a versioned dependency on a 
specific version of the library, libfann2 (=2.1.0~beta+dfsg-1). 
Therefore, The library itself will not be upgradeable without breaking 
or removing python-pyfann.
2. Upload the Python bindings from the new upstream source, built 
against the new version of the library
3. After the bindings have passed NEW, both library and bindings should 
be upgradeable smoothly.


Sounds good to me. Although to minimize time when python-pyfann is 
uninstallable, you might want to do it in a different order:

upload src:pyfann first,
wait until it's accepted,
then upload src:libfann that no longer builds python-pyfann.

--
Jakub Wilk

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1

[Bill Blough]

Thanks so much for all the feedback.

On Wed, Sep 23, 2015 at 11:03:01PM +0200, Tobias Frost wrote:
> 
> - d/source/options: Why do you have the option diff-ignore?

Issues with the translation files - When the .mo files get generated, the .po
files get updated with a new timestamp, causing repeat builds from the same
source to fail the dpkg-source check.  I did quite a bit of searching on how to
deal with it, but that was the only solution I found.  Is there a better way to
handle it?

> - d/patches are marked as Forwarded: no and not-needed. Are they really
> not upstreamable?

The pixmap patch I could forward, but with the menu/.desktop change, I think I
can go ahead and remove it since the pixmap won't be needed. (desktop can use
the existing png, whereas menu couldn't)

The path patch is for compliance with the FHS, so I think it's Debian-specific
since not all distributions follow the FHS.

The gcc5 fix is cherry picked from an upstream commit, so there's no need to
forward it.  When the next upstream release is made for Linux, I'll be able to
remove it.

> - please use wrap-and-sort; this will also remove those trailing
> whitespaces I love to nitpick about...

Done.

> 
> - Well, README.LINUX does not really have information for the user
> beside it's beta, so I'd not install it but explain in the package
> description that not all features are implemented

Done.

> 
> - I would not install both the html and txt version of
> docs/ReleaseNotes, they have identical content. Also, this seems to be
> the project's changelog, so it should be installed with
> dh_installchangelog and not via dh_installdocs. Therefore it should
> also not be registered using doc-base

Done.  Note, I created an override for dh_installchangelogs to keep (symlink)
the original name, since it's referred to by name in README.txt.
> 
> - d/menu should be depreciated in favour of .desktop files, so remove
> this file. See also #741573

Done. That was an interesting read, thanks :-) 
> 
> - the chm file you refer in your source override -- I guess  it is not
> built at build time. We need to build everything from source... Can you
> simply remove it? 

Upon further inspection, I don't think we actually need it.  Removed via
d/copyright Files-Excluded

> That's how far I come... Will continue as soon as possible

Really appreciated, thanks!