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 <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 > > > -- tobi
Attachment:
signature.asc
Description: This is a digitally signed message part