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 <t...@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, 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 > >
