Lintian error
I am getting this error from lintian N: This package contains an embedded copy of the JQuery, Prototype, N: Mochikit or "Cropper" JavaScript libraries that are now available in N: their own packages. Please depend on the appropriate package and N: symlink the library into the appropriate location. N: N: Refer to Policy Manual, section 4.13 for details. N: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. I have run a diff on prototype which is in the package and the version in debian and there are differences. Would Debian Policy 4.13 still apply? Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Ben Finney wrote: "Paul Wise" <[EMAIL PROTECTED]> writes: On Wed, Jul 30, 2008 at 3:52 PM, Charliej <[EMAIL PROTECTED]> wrote: I have contacted upstream about this error, and he states that he would not want to depend on the prototype package in debian because he has made changes to the version of prototype he is currently using. Please ask him to send his changes to the prototype upstream developers so they can be included in the next prototype release. Another option is for the person who wants the library to be different to fork it, maintain that fork, and work with someone to get it into Debian. This option is obviously more ongoing work, but may be preferable if (as sometimes happens) the author of the library won't accept the changes. Once that is in Debian, your package can depend on it. Same here. The main point is that a library that is *not* the same 'prototype' as upstream should either be merged with, or clearly (in name and in code access) differentiated from, the upstream 'prototype' library. Which is what you (Charliej) are already discussing with your upstream, so thank you. First let me apologize for a mistake in my first post. My upstream is actually using what is in the debian repos now. I had accidentally grabbed a later version to do my diff with. So actually there are no differences between upstream prototype and what is in the package now. With that said this is a quote from my upstream: "Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy" Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. I think one of the reasons he is hesitant is that the removal of "prototype" from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 "prototype" will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? This brings me to the next point what if upstream refuses to remove "prototype" from the .tar.gz? Thx Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Raphael Geissert wrote: Charliej wrote: With that said this is a quote from my upstream: "Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy" Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of "prototype" from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 "prototype" will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This I can do, but to clarify your above statement does that mean that I remove it from the .orig.tar.gz or do I adjust the rules and or postinst to insure that it does not get installed? hmm I think I may have answered my own question. Upstreams .tar.gz and the .orig.tar.gz must have the same md5sum correct? if so then that means the rules and or postinst have to be modified. Is my thinking here correct? This brings me to the next point what if upstream refuses to remove "prototype" from the .tar.gz? Thx Charlie Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian error
Raphael Geissert wrote: [Please respect the CoC[0] and avoid sending me copies of the message] [0]http://www.debian.org/MailingLists/#codeofconduct Charliej wrote: Raphael Geissert wrote: Charliej wrote: With that said this is a quote from my upstream: "Whee, is this something you could take care of at install, delete and then create a symlink. Or would this still violate this policy" Would this be a viable solution? (I told upstream I would ask) I don't think this is a viable solution because the lintian error would still remain. You should symlink the file provided by the other package, if lintian still complains it is a bug in lintian then. I think one of the reasons he is hesitant is that the removal of "prototype" from the .tar.gz that he hosts would severely impact his M$ Windows users (he has a rather large M$ Windows community). Actually I could care less about M$ Windows users, but he does. As I see it to comply with Policy 4.13 "prototype" will have to be removed from upstreams .tar.gz.. Am I correct in this assumption? No, he doesn't need to remove his copy of prototype, it is _you_ who needs to prevent it from being installed in the package you build. This I can do, but to clarify your above statement does that mean that I remove it from the .orig.tar.gz or do I adjust the rules and or postinst to insure that it does not get installed? The latter :) hmm I think I may have answered my own question. Upstreams .tar.gz and the .orig.tar.gz must have the same md5sum correct? if so then that s/must/should, there are situations where one must repackage the tarball, but I don't believe this is the case. means the rules and or postinst have to be modified. Is my thinking here correct? Besides what I just clarified, yes. This brings me to the next point what if upstream refuses to remove "prototype" from the .tar.gz? Thx Charlie Cheers, Cheers, To everyone who answered this post Thank You very much for your assistance. Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: quickplay
Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 0.1 Upstream Author : Kevin Purdy * URL : http://quickplay.isfound.at/ * License : GPLv2 Section : sound It builds these binary packages: quickplay - a light weight player/frontend for Ampache Quick play is a light weight mp3 player and simple front end for Amapche which is written in Python. Quickplay utilizes XML-RPC and ACL's to browse and play mp3's from Ampache. The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_0.1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
On Sat, 2008-09-20 at 13:51 +0200, Patrick Schoenfeld wrote: > Hi, > > before the review process starts, a question: > > On Fri, Sep 19, 2008 at 02:15:41PM -0500, Charliej wrote: > > Version : 0.1 > > * URL : http://quickplay.isfound.at/ > > Do you think this software is yet mature enough for inclusion into > Debian? I'm just wondering, because of the low version number and > what the homepage concerns... "work in progress" would be a > over-optimistic. > > Best Regards, > Patrick > > Hi Patrick, Thank you for taking the time to look at quickplay. That depends on what your definition of what "mature" is? If you mean "mature" as in will the software do what it's suppose to do then yes. If you mean "mature" as in time then probable not. Actually upstream was not using versioning until I requested that he do so. Hence the low version number, I thought 0.1 would be a good place to start. IMHO any package that introduces new features would be considered a "work in progress". I would consider Debian itself a "work in progress" in that it changes and evolves on a daily basis which is a good thing. With that said after talking extensively with upstream he does have plans for additional features and of course to squash any bugs that may arise. So my interpretation of this is that quickplay will be actively developed and not become static cruft laying around the archives. Thank you once again for looking at quickplay Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
On Sun, 2008-09-21 at 11:46 +0200, Patrick Schoenfeld wrote: > Hi, > > Charliej wrote: > > That depends on what your definition of what "mature" is? If you mean > > "mature" as in will the software do what it's suppose to do then yes. > > If you mean "mature" as in time then probable not. > > mature means for me that the package is somewhat ready for use by "end users". > That means that it works mostly stable, does what its expected to do and > does not make a half-baked impression on the user (we have such software > in the archive and I dislike it, so I won't help with getting such > software in) > > > Actually upstream was not using versioning until I requested that he do > > so. Hence the low version number, I thought 0.1 would be a good place > > to start. > > Ah, I see. Does that mean that the software already has some development > history behind it? I'm just asking out of curiousity, I didn't yet test the > software. > > > IMHO any package that introduces new features would be considered a > > "work in progress". I would consider Debian itself a "work in progress" > > in that it changes and evolves on a daily basis which is a good thing. > > My use of "work in progress" was about the homepage, which does not yet > contain any useful information. As I did not test the software yet, this > and the low version number is my only impression of the development. It > makes the impression that the development just started and that it might > be to early to be included into a distribution. If that impression is > wrong; good. Thats why I asked you. > > Best Regards, > Patrick > > Patrick I have been thinking about this quite a bit, and you are absolutely correct. Upstreams documentation is sourly lacking. I asked myself the question "If I was the end user would I use something so poorly documented" and of course the answer was no. So I have decided to take quickplay down from m.d.n for now. I will keep the ITP bug open as I will be working with upstream to improve on the short comings you have expressed above and resubmit at a later date. Once again thank you for taking the time to look a quickplay, your feedback was very much appreciated. =) Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quickplay
On Mon, 2008-09-22 at 17:20 +0200, Patrick Schoenfeld wrote: > Hi Charlie, > > On Mon, Sep 22, 2008 at 09:57:09AM -0500, Charliej wrote: > > I have been thinking about this quite a bit, and you are absolutely > > correct. Upstreams documentation is sourly lacking. I asked myself the > > question "If I was the end user would I use something so poorly > > documented" and of course the answer was no. So I have decided to take > > quickplay down from m.d.n for now. I will keep the ITP bug open as I > > will be working with upstream to improve on the short comings you have > > expressed above and resubmit at a later date. > > okay. I wouldn't say that I'm glad or that it was my intension to let > you choice your decision in this way, but I am happy that I brought you > to *think* about this point. > > Feel free to CC me, when you've got a package that you feel to be ready for > inclusion. I will gladly have a look at it then, if I find the time. > > Best Regards, > Patrick > > This is my first time to package a python app with cdbs, so yes I was focused on the technical aspects of the package and overlooked parts of the administrative aspect (informative documentation). The current state of quickplays documentation IMHO would not provide for an enjoyable end user experience and needs to be improved. So might as well correct it now before we get any further in the process =). Thank you for the offer. I will hopefully take you up on it in the near future =) Charlie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: quickplay
Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 1.2-1 Upstream Author : Kevin Purdy * URL : http://quickplay.isfound.at/ http://vollmer.kicks-ass.net * License : GPL-v2 Section : sound It builds these binary packages: quickplay - Is a light weight mp3 player and front end for Ampache The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
quickplay [2nd try]
Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 1.2-1 Upstream Author : Kevin Purdy <[EMAIL PROTECTED]> * URL : http://quickplay.isfound.at/ * License : GPLv2 or lesser Section : sound It builds these binary packages: quickplay - a light weight mp3 player/frontend for Ampache written in python. The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS quickplay [2nd try]
Sorry, forgot to put RFS in the subject line resending to m.d.n list Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 1.2-1 Upstream Author : Kevin Purdy <[EMAIL PROTECTED]> * URL : http://quickplay.isfound.at/ * License : GPLv2 or lesser Section : sound It builds these binary packages: quickplay - a light weight mp3 player/frontend for Ampache written in python. The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
License Question
Hello All, I am working on packaging a front end for MPD called Pitchfork. I was looking through the source gathering copyright information and noticed that some components are released under the: 1. Creative Commons License Attribution-Share Alike 2.0 Generic 2. PHP License Version 3.01 Will these licenses keep this package out of Debian? Regards Porthose -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: quickplay
Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 1.2-1 Upstream Author : Kevin Purdy * URL : http://vollmer.kicks-ass.net * License : GPLv2 Section : sound It builds these binary packages: Quickplay - Is a light weight mp3 player and front end for your Ampache server. Quickplay, like Amarok2 utilizes Ampache's XML API to send and receive metadata and stream information. Quickplay is written in Python and is very small, which makes it is great to use on older hardware where a minimal setup is the goal. Please comment on any packaging mistakes, even if you do not plan to sponsor Quickplay. The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman signature.asc Description: This is a digitally signed message part
RFS: quickplay
Dear mentors, I am looking for a sponsor for my package "quickplay". * Package name: quickplay Version : 1.2-1 Upstream Author : Kevin Purdy * URL : http://vollmer.kicks-ass.net * License : GPLv2 Section : sound It builds these binary packages: Quickplay - Is a light weight mp3 player and front end for your Ampache server. Quickplay, like amarok2 and python-coherence utilizes Ampache's XML API to send and receive metadata and stream information from your Ampache server. Quickplay is written in Python and is very small, which makes it great for minimalistic setups where a heavier, bloated player won't due. Please comment on the packaging, even if you do not plan to sponsor Quickplay. The package appears to be lintian clean. The upload would fix these bugs: 499485 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/quickplay - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/quickplay/quickplay_1.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Charlie Smotherman signature.asc Description: This is a digitally signed message part
