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

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 <tobi@debian.org>:

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, plcl@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