Bug#747169: RFS: socksjs-twisted/1.2.1-1 [ITP]
Hi Alexandre,
Sorry for my delay. I was traveling.
2014-09-11 18:09 GMT-03:00 Alexandre Rossi <alexandre.rossi@gmail.com>:
> Thanks for your time.
>
>>>> - Please, create a VCS to control your debian/ versions. You can
>>>> use github or other. So, add the Vcs-Browser and Vcs-{Git|Svn|Cvs} to
>>>> d/control. You can see an example here[1].
>>>
>>> Done.
>>
>> You need use 'git://' to Vcs-Git, intead of 'https://'.
>
> That's not what recommended by github and https:// works as a git
> clone url. I'm not against changing this though.
Ok. I didn't know it. I tested, using a clone procedure, and it
worked. Thank you for showing me.
>>>> 2. d/copyright:
>> Please, I found new names as Ariel Flesler and The Dojo Foundation
>> (from your patch).
>
> Okay, I added those names. But doesn't the header of the file give the license?
All relevant license notices must to be put in d/copyright.
>> How you concluded that txsockjs/websockets.py is under MIT license? Do
>> you checked this information at this site[1]?
>>
>> [1] http://twistedmatrix.com/trac/browser/branches/websocket-4173-2?rev=29073
>
> Yes.
>
>> If yes, the license must be put inside the source code. From MIT
>> license: "The above copyright notice and this permission notice shall
>> be included in all copies or substantial portions of the Software.".
>> So, if no have references in source code (about the license and
>> origin), the upstream didn't can distribute this code without break
>> the licensing rules.
>>
>> I am very concerned because I think that the upstream source code has
>> several files or extracts of codes from other upstreams without
>> licenses. If yes, the socksjs-twisted upstream needs to fix this
>> issue.
>
> You are right. But as upstream does not seem responsive, I cannot do
> much more than patching the files to fix those issues.
The problem, IMHO, is that the software is hurting copyright rights
and can't be distributed. So, I think the upstream must fix it. Other
alternative is you to fork the project and fix all issues. But it is a
bit hard to life.
>>>> 3. What makes your patch? My impression is that you are "injecting" a
>>>> third-part code in upstream. Is this? If yes, you must add it as an
>>>> dependency of the package. If not packaged, you need package it.
>>>
>>> The patch adds the missing source for minified js files. See
>>> https://lintian.debian.org/tags/source-is-missing.html
>>
>> Ok. But the lintian says: "add it to "debian/missing-sources"
>> directory". And as I said, this code must be referenced in
>> d/copyright.
>
> My idea was to have a patch ready for inclusion by upstream, easier
> than picking up the pieces in debian/missing-sources.
Ok, but it is an third-party code injected yet. The better procedure
is put it as a dependency.
>> What is the origin of this code? (you must add it to the patch header)
>
> This code was taken from the history of jquery.
>
>> There is this code packaged in Debian?
>
> Yes but not the same version as the minified source.
Do you tested to see if works? For me, this inclusion, in a first
view, is undesirable. I will baulk to accept it...
> This files are not even part of the binary package, the idea is just
> to fix the source package.
Ok, I understood it. But consider my previous opinion.
>>>> 6. Do you see these lintian messages?
>>>>
>>>> P: sockjs-twisted source: source-contains-prebuilt-javascript-object
>>>> qunit/html/static/jquery.min.js
>>>> P: sockjs-twisted source: source-contains-prebuilt-javascript-object
>>>> qunit/html/static/qunit.min.js
>>>
>>> Those are fixed by the patch and are false positives, see above and a
>>> lintian bug :
>>> https://bugs.debian.org/744972
>>
>> I can be wrong. But the pointed site is about missing sources. Please see it[2].
>>
>> [2] https://lintian.debian.org/tags/source-contains-prebuilt-javascript-object.html
>
> From some other discussion, I had understood that including the
> missing source was enough. What is your advice here : should I add a
> Makefile to regenerate those files that don't even get in the binary
> package? Should I repack the source to get rid of those (which would
> be a pity : the archived source package would be stripped of its test
> suite) ?
>
> Alex
Well, Paul Wise answered. Other solution is a fork project.
I think that is important say you that I want help. However, the
source code is very strange because the upstream is ignoring the basic
rules.
Cheers,
Eriberto
Reply to: