Bug#757442: RFS: polyphone/1.4 [RFP]

[Tobias Frost]

Control: tags -1 wontfix

Marking wontfix according to http://mentors.debian.net/sponsor/rfs-howto
(cannot be uploaded without fix for the copyright of the icons)

--
tobi


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#757442: RFS: polyphone/1.4 [RFP]

[Tobias Frost]

Hi Davy,

nice to hear from you again..

Sorry, its already late today, so I won't complete review now...

I need some clarifcation regarding the images in resources/:
Where are those images from? Please dokument every image with its
license.

What me worries: At least csv.png seems non-DFSG-free (license Creative
Commons Attribution-NoDerivs 3.0;
http://www.iconsdb.com/black-icons/csv-icon.html;
http://icons8.com/license/).


d/copyright misses at least a Files: * rule and you need to update the
years on debian/*

Please check every file. E.g. one says:
 2014,  Davy Triponney 
 2014,  Andrea Celani  
but there is no Andrea Celani in d/copyright!

Thanks!

Please understand as the licenses of the images are show-stoppers, I
will wait for your response before looking to the rest.  

Am Mittwoch, den 22.10.2014, 18:58 +0200 schrieb Davy Triponney:
> Dear Tobi, dear maintainers,
> 
> 
> I uploaded another version of Polyphone (1.5).
> 
> 
> Sources have been modified so that the following libraries are not
> included anymore:
> 
>  - qcustomplot,
> 
>  - stk,
> 
>  - rtmidi.
> 
> 
> Regarding the sfArk parser, I fulfilled in using only one library
> instead of two to read sfArk files. However Qt variables are still
> used (qint16, quint16, ...) and one small class heavily rely on Qt
> libraries (QMap, QFile, QByteArray...). So I didn't fill an ITP bug
> for this parser.
> 
> Copyrights should be ok.
> 
> 
> Regarding my application to be a maintainer... I have other projects
> in mind and won't have time for this unfortunately. But I can of
> course continue to evolve my package to fix bugs or discrepancies with
> Debian QA.
> 
> 
> Regards,
> Davy
> 



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

Bug#757442: RFS: polyphone/1.4 [RFP]

[Davy Triponney]

Dear Tobi, dear maintainers,

I uploaded another version of Polyphone (1.5).

Sources have been modified so that the following libraries are not included
anymore:
 - qcustomplot,
 - stk,
 - rtmidi.

Regarding the sfArk parser, I fulfilled in using only one library instead
of two to read sfArk files. However Qt variables are still used (qint16,
quint16, ...) and one small class heavily rely on Qt libraries (QMap,
QFile, QByteArray...). So I didn't fill an ITP bug for this parser.

Copyrights should be ok.

Regarding my application to be a maintainer... I have other projects in
mind and won't have time for this unfortunately. But I can of course
continue to evolve my package to fix bugs or discrepancies with Debian QA.

Regards,
Davy

Bug#757442: RFS: polyphone/1.4 [RFP]

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

(Please do not top-post)

On Tue, 2014-08-19 at 10:19 +0200, Davy Triponney wrote:
> Regarding the libraries, I can adapt the sources so that I can use the
> packaged versions of qcustomplot, rtmidi and stk.

Very good :)

> 
> A lot of changes has been made in vmpk. The author contacted me a few
> months ago to try a merge of the added features but some has not been
> accepted (incompatibilities with future features). I could try to find
> a compromise and propose another version of the keyboard, before
> packaging it. This process needs time: I'll keep my version of the
> keyboard for now.

With that explanation this is ok for me. (However, I'd suggest to try to
evolve your software in the direction that you can use the standard
software in the future. In the long it will be simpler and less work, as
you constantly have to monitor the library.) However, please send a mail
to the security testing team as described in
https://wiki.debian.org/EmbeddedCodeCopies.

> 
> Regarding sfarklib there are some problems here. First, this library
> can open sfArk version 2 only.


>  I found another library (whose author seems to be unknown) that can
> open the version 1 and maybe the version 2 as well but I wasn't able
> to build it correctly for this version. Then, both libraries take as
> input a file, and create another file as output. I adapted them to
> work with a stream of byte, the object being provided by Qt. My
> questions are:
> 
>  - should I merge both libraries so that it can fully support the 2
> versions of the sfArk format?

As above, for now this should be ok. 

However, please sync your version with the one from upstream... I saw at
least a few lines which are in the original and not in yours
(You do not need to comment out the msg lines -- just define your
callback or as an empty define; this will allow to spot upstream changes
more easily; I'd also put your use for your customized versions of the
functions own names, and keep the old functions, again for improved
readability of the changes. The commented out sprintf could be replaced
with a snprintf... Maybe you can send a patch upstream? I'd ignore the
extra cycles by snprintf, my priority is readability here.)

>  - what is the good practice regarding the inputs and outputs? I can't
> use this library if it deals with files, but I understand that a
> dependancy to Qt libraries is too cumbersome.

Yes, when providing patches back to upstream, introducing QT as
dependency is not the way to go. 
I don't now about the file format, but if the size is deterministic,
just an array of memory could do it, or maybe callbacks getting data
from/to the app instead of using WriteOutputFile() and
ReadInputFile()... 

>  - what happens if an author is unknown?

Depends on the license... If it is a free license and there are no
reasons to believe that this is true, this shouldn't be a problem.

> 
> Regards,
> Davy
> 
> 
> 
> 
> 2014-08-13 21:07 GMT+02:00 Tobias Frost :
> On Wed, 2014-08-13 at 17:46 +0200, Davy Triponney wrote:
> > Thank a lot for the report.
> >
> >
> > - polyphone_1.4.orig.tar.gz is now present in SourceForge
> > (https://sourceforge.net/projects/polyphone/files/polyphone%
> > 20releases/1.4/)
> > Regarding get-orig-source, I read this page:
> > https://wiki.debian.org/onlyjob/get-orig-source
> >
> > My watch file is correct since the last version is
> recognized and
> > downloaded by uscan. But I don't know how to integrate this
> nice
> > feature by modifying the file "rules" even with the
> explanations. And
> > I don't know what result I would get. A self-updating
> package creator?
> 
> 
> get-orig-source is needed if you don't cant get the orig.tar.
> One
> example us, if there isn't one and you pull directly from a
> repository.
> A example for this would be my package gmrender-resurrect.
> 
> Or, if you had to remove files for DFSG freeness (which
> nowerdays uscan
> can do for you via ExcludeFiles in d/copyright).
> 
> So if uscan won't work for you, you need the target...
> Otherwise not.
> 
> > - copyright file is fixed, copyright headers added in some
> source
> > files,
> > - debian/share directory has been removed
> > - the icon resolution is now 512*512, it doesn't come from a
> vector
> > file,
> 
> 
> ok, I just saw that my comment regarding the icon was
> incomplete... srry
> about that. The intention is that every file needs its source
> and
> regenerated at build time -- the resolution is not a concern,
> but we
> need "the preferred form for modiciations" here. So it would
> be great

Bug#757442: RFS: polyphone/1.4 [RFP]

[Davy Triponney]

Regarding the libraries, I can adapt the sources so that I can use the
packaged versions of qcustomplot, rtmidi and stk.

A lot of changes has been made in vmpk. The author contacted me a few
months ago to try a merge of the added features but some has not been
accepted (incompatibilities with future features). I could try to find a
compromise and propose another version of the keyboard, before packaging
it. This process needs time: I'll keep my version of the keyboard for now.

Regarding sfarklib there are some problems here. First, this library can
open sfArk version 2 only. I found another library (whose author seems to
be unknown) that can open the version 1 and maybe the version 2 as well but
I wasn't able to build it correctly for this version. Then, both libraries
take as input a file, and create another file as output. I adapted them to
work with a stream of byte, the object being provided by Qt. My questions
are:
 - should I merge both libraries so that it can fully support the 2
versions of the sfArk format?
 - what is the good practice regarding the inputs and outputs? I can't use
this library if it deals with files, but I understand that a dependancy to
Qt libraries is too cumbersome.
 - what happens if an author is unknown?

Regards,
Davy



2014-08-13 21:07 GMT+02:00 Tobias Frost :

> On Wed, 2014-08-13 at 17:46 +0200, Davy Triponney wrote:
> > Thank a lot for the report.
> >
> >
> > - polyphone_1.4.orig.tar.gz is now present in SourceForge
> > (https://sourceforge.net/projects/polyphone/files/polyphone%
> > 20releases/1.4/)
> > Regarding get-orig-source, I read this page:
> > https://wiki.debian.org/onlyjob/get-orig-source
> >
> > My watch file is correct since the last version is recognized and
> > downloaded by uscan. But I don't know how to integrate this nice
> > feature by modifying the file "rules" even with the explanations. And
> > I don't know what result I would get. A self-updating package creator?
>
> get-orig-source is needed if you don't cant get the orig.tar. One
> example us, if there isn't one and you pull directly from a repository.
> A example for this would be my package gmrender-resurrect.
>
> Or, if you had to remove files for DFSG freeness (which nowerdays uscan
> can do for you via ExcludeFiles in d/copyright).
>
> So if uscan won't work for you, you need the target... Otherwise not.
>
> > - copyright file is fixed, copyright headers added in some source
> > files,
> > - debian/share directory has been removed
> > - the icon resolution is now 512*512, it doesn't come from a vector
> > file,
>
> ok, I just saw that my comment regarding the icon was incomplete... srry
> about that. The intention is that every file needs its source and
> regenerated at build time -- the resolution is not a concern, but we
> need "the preferred form for modiciations" here. So it would be great if
> you could publish the source for the icon and -- if possible --
> regenerate it at build time to the desired sizes...
>
> > - debian/polyphone.1 has been completed,
> >
> > - ITP bug retitled,
> > - pdebuilder now can build the package. I'm sorry for
> > the dependency mistakes.
> >
> >
> > The new package has been uploaded
> > https://mentors.debian.net/package/polyphone
> >
>
> The above reads very good :)
>
> Taking a look now...
>
> -> clavier/RT*.cpp seems like an embedded code copy, fortunately its
> already packaged in Debian is rtmidi, but unfortunatly the package in
> Debian is much newer than the code in polyphone, so some additional
> porting beside patching the build system to use the packaged one might
> be necessary. (Embedded code copies are very discouraged -- refer to the
> Policy §4.13)
>
> (But patching this will help you on another possible issue: The license
> on RTMidi. It says:
>  Any person wishing to distribute modifications to
>  the Software is *requested* to send the modifications to the original
>  developer
>
> Update: I just see that this is a widget, probably from the package
> vmpk)... It seems is possible to package the QT Widget on its own...)
> However, for this widget I'd ignore that one for the moment...
>
> In the packaged version "request" has been replaced with "ask" and a
> sentence added that this is not a requirements. I discussed this on
> d-mentors: there were concerns about DFSG compliance, but the concerns
> are void when only "ask"ing. (I'm not saying that the "request" isn't
> ok, but this can cause questions at ftp-masters later on)
>
> Another embedded library seems to be the The Synthesis ToolKit
> in synthetiseur/elements/* (also packaged in Debian)
>
> Another one: qcustomplot
>
> Another one: sfarklib.
> (However, this one needs to be packaged)
>
> lib/portaudio.h shouldn't be there... :-P
> For the moment please remove the file with a patch -- to show that it is
> not used.
> (If possible, drop that file in your next release)
>
>
> -> d/copyright:
> It probably misses a Files:* rule with
> Copyright Davy Triponney  and
> License: GPL-3+
>

Bug#757442: RFS: polyphone/1.4 [RFP]

[Tobias Frost]

On Wed, 2014-08-13 at 17:46 +0200, Davy Triponney wrote:
> Thank a lot for the report.
> 
> 
> - polyphone_1.4.orig.tar.gz is now present in SourceForge
> (https://sourceforge.net/projects/polyphone/files/polyphone%
> 20releases/1.4/)
> Regarding get-orig-source, I read this page:
> https://wiki.debian.org/onlyjob/get-orig-source
> 
> My watch file is correct since the last version is recognized and
> downloaded by uscan. But I don't know how to integrate this nice
> feature by modifying the file "rules" even with the explanations. And
> I don't know what result I would get. A self-updating package creator?

get-orig-source is needed if you don't cant get the orig.tar. One
example us, if there isn't one and you pull directly from a repository.
A example for this would be my package gmrender-resurrect. 

Or, if you had to remove files for DFSG freeness (which nowerdays uscan
can do for you via ExcludeFiles in d/copyright).

So if uscan won't work for you, you need the target... Otherwise not.

> - copyright file is fixed, copyright headers added in some source
> files,
> - debian/share directory has been removed
> - the icon resolution is now 512*512, it doesn't come from a vector
> file,

ok, I just saw that my comment regarding the icon was incomplete... srry
about that. The intention is that every file needs its source and
regenerated at build time -- the resolution is not a concern, but we
need "the preferred form for modiciations" here. So it would be great if
you could publish the source for the icon and -- if possible --
regenerate it at build time to the desired sizes...

> - debian/polyphone.1 has been completed,
> 
> - ITP bug retitled,
> - pdebuilder now can build the package. I'm sorry for
> the dependency mistakes.
> 
> 
> The new package has been uploaded
> https://mentors.debian.net/package/polyphone
> 

The above reads very good :)

Taking a look now...

-> clavier/RT*.cpp seems like an embedded code copy, fortunately its
already packaged in Debian is rtmidi, but unfortunatly the package in
Debian is much newer than the code in polyphone, so some additional
porting beside patching the build system to use the packaged one might
be necessary. (Embedded code copies are very discouraged -- refer to the
Policy §4.13)

(But patching this will help you on another possible issue: The license
on RTMidi. It says:
 Any person wishing to distribute modifications to 
 the Software is *requested* to send the modifications to the original  
 developer 

Update: I just see that this is a widget, probably from the package
vmpk)... It seems is possible to package the QT Widget on its own...)
However, for this widget I'd ignore that one for the moment...  

In the packaged version "request" has been replaced with "ask" and a
sentence added that this is not a requirements. I discussed this on
d-mentors: there were concerns about DFSG compliance, but the concerns
are void when only "ask"ing. (I'm not saying that the "request" isn't
ok, but this can cause questions at ftp-masters later on)

Another embedded library seems to be the The Synthesis ToolKit 
in synthetiseur/elements/* (also packaged in Debian)

Another one: qcustomplot

Another one: sfarklib.
(However, this one needs to be packaged)

lib/portaudio.h shouldn't be there... :-P
For the moment please remove the file with a patch -- to show that it is
not used.
(If possible, drop that file in your next release)


-> d/copyright:
It probably misses a Files:* rule with 
Copyright Davy Triponney  and 
License: GPL-3+

Files: clavier/*
Copyright: 2008-2014 Pedro Lopez-Cabanillas, p...@users.sf.net
License: GPL-3+

Your name is missing here as copyright holder


Three files without copyright:
./clavier/RtError.h UNKNOWN *No copyright*
./sfark/sfarkglobal.cpp UNKNOWN *No copyright*
./sfark/sfarkglobal.h UNKNOWN *No copyright*

ressources/* are missing in d/copyright.
Is the manual hand written or generated?
(However, as not installed, this is OK)   

Just a question (to avoid a typo)
You license debian/* with GPL-2+ while the rest is GPL-3+
(different version). As you have the "or later" this is ok, but its
easier if license of the packaging is exactly same.
No need to change, though.

Ok so please check the remaining d/copyright issues, and please check if
it is feasible to use the packaged libraries instead of your embedded
copies.
Could you (if feasible to be used) already file an ITP for sfArkLib? 

Cheer up, we're getting closer :)

> Regards,
> Davy

-- 
tobi



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

Bug#757442: RFS: polyphone/1.4 [RFP]

[Davy Triponney]

Thank a lot for the report.

- polyphone_1.4.orig.tar.gz

is
now present in SourceForge
(https://sourceforge.net/projects/polyphone/files/polyphone%20releases/1.4/)
Regarding get-orig-source, I read this page:
https://wiki.debian.org/onlyjob/get-orig-source
My watch file is correct since the last version is recognized and
downloaded by uscan. But I don't know how to integrate this nice feature by
modifying the file "rules" even with the explanations. And I don't know
what result I would get. A self-updating package creator?
- copyright file is fixed, copyright headers added in some source files,
- debian/share directory has been removed
- the icon resolution is now 512*512, it doesn't come from a vector file,
- debian/polyphone.1 has been completed,
- ITP bug retitled,
- pdebuilder now can build the package. I'm sorry for
the dependency mistakes.

The new package has been uploaded
https://mentors.debian.net/package/polyphone

Regards,
Davy

Bug#757442: RFS: polyphone/1.4 [RFP]

[Tobias Frost]

Hi Davy,

You're also upstream, aren't you? 
(Then I'd recommend reading https://wiki.debian.org/UpstreamGuide )

(I assume you are upstream for the review below...)

Let's go:

- You probably missed pushing the 1.4 tar.gz to sf.net, because I uscan
doesn't find it. If you plan to package from (upstream) git repository,
you need to have a get-orig-source target in debian/rules.

d/copyright: 
- Please recheck liceneses, it contains errors.  For example: lib/* is
not LGPL but MIT/X11 (use licensecheck). Section License: LGPL is not
LGPL-text.
- this is not the only error -- I recommend to use 
licensecheck -r -m --copyright *
- there are a few files without copyright information.

d/share/*
This looks weird... What's your intention here by pre-packaging all that
stuff. 
As you are upstream, you maybe want to include those file in your
tarball and install from there.

For this, please use standard debhelper mechanisms for installing stuff,
for example dh_installchangelogs, dh_installmime ... (see debhelper(7)) 

Upstream-Changelogs do not belong into the debian-directory, they should
be also in the upstream tarball. 

For your nice icon -- is there "source" (e.g a bigger vector file)?
If so, it would be best if it could be 

d/polyhone.1 -> this file is basically empty. Please rewrite. (And
include in your upstream tarball

(BTW, you still need to retitle your ITP bug... How to was already
written already in that bug)

The package does not build in an pdebuilder enviroment:

 Project ERROR: Package portaudio-2.0 not found
dh_auto_configure: qmake -makefile -nocache QMAKE_CFLAGS_RELEASE=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 QMAKE_CFLAGS_DEBUG=-g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
QMAKE_CXXFLAGS_RELEASE=-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 QMAKE_CXXFLAGS_DEBUG=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 QMAKE_LFLAGS_RELEASE=-Wl,-z,relro
QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: PREFIX=/usr returned exit
code 2
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
E: Failed autobuilding of package
W: no hooks of type C found -- ignoring
I: unmounting /var/cache/pbuilder/ccache filesystem
I: unmounting /home/tobi/pbuilder_repo/deps filesystem
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
I: cleaning the build env 
I: removing directory /var/cache/pbuilder/build//7284 and its
subdirectories

Stopping here...

-- 
tobi



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

Bug#757442: RFS: polyphone/1.4 [RFP]

[Davy Triponney]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: polyphone
   Version : 1.4-1
   Upstream Author : Davy Triponney (davy.tripon...@gmail.com)
 * URL : www.polyphone.fr
 * License : GPL v3

It builds this binary package:

polyphone

To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/polyphone


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

dget -x 
http://mentors.debian.net/debian/pool/main/p/polyphone/polyphone_1.4-1.dsc

More information about Polyphone can be obtained from http://www.polyphone.fr.


Regards,
Davy Triponney