Hi, On Thu, Jul 03, 2008 at 11:25:18AM +0200, Thibaut GIRKA wrote: > > Due to the fact that its a GPL license you have the possibility to > > create a symlink to the file in /u/s/common-licenes. > > Or patch bluemindo. First choice probably preferrable. > > Done, but not sure this is the cleanest way.
well, you've done it in an overcomplicated way. You call dh_link manually, but thats not neccessary as CDBS already calls it. You just have to add a file debian/links containing all the links that you need to create. This also saves some build-time (not that many, but consider 1000 packages calling a perl script like dh_link twice for no reason), what I consider quiet important, as some architectures are already overloaded. BTW. this is one of the biggest disadvantages I see with CDBS. It seems to call almost every dh_* script for no good reason, without having a clue if it needs to call it or not. This way a CDBS run takes almost always a bit longer, as if you had done it yourself. > Bluemindo does not provide a setup.py file, so I've done what the New > Policy says [2]. Okay. Good. > > So to make your copyright perfect: > > - Remove license excerpts for well known licenses > > - Include complete license information for the PSF, because it is not in > > /u/s/common-licenses > > - Make the human readable part complete (e.g. re-add a Copyright part). > > Hm... The resulting file will be pretty large if I do so. Only because of the PSF, but that is obligatory, because copyright is the single-place to find copyright and licensing information. You have no chance to link somewhere (like /u/s/common-licenses) so you need to include the license. Its as simple as that. > The human readable part... Hm... I switched to the machine-parseable one > because there weren't any 'official' way to do when there are multiple > copyrights/licenses... Well, its okay if you want to keep the machine-parseable part only. I just recommend you to keep a human-readable variant as well, because I think that people who are not technical experienced will have trouble to understand the format and a human-readable version would therefore be an advantage. But obvious you can decide that you don't want that. You can decide to only keep a machine-parseable version. But then do it consistent. Don't include human readable information (like the License block) if you don't intend to keep a human readable version of the copyright file. > I however made some modifications to debian/copyright. Hm. IMHO It looks a bit weird, now, but except the not needed empty lines between the machine parseable part and the human readable part it seems okay. However I have a suggestion for you how the human-readable part could look like. See [1] for it. > > Well, the most window managers probably don't understand the PNG format, > > so yes this is required. However you can do this automatically by > > converting the file with convert and build-depending on imagemagick. > > Done, but like the COPYING symlink, I don't know if I have done it in a > clean way. Given that it isn't a 'install' step you should move it to another target. The CDBS documentation has 'build/foo' for it. > Should be enough, now, provided that cdbs-edit-patch is available. Nearly. I still don't know how I could disable certain patches from beeing applied on build. For example: quilt has a file series which stores the list of patches that will be applied. Its possible to remove entries from there and the patches won't be applied. CDBS does not seem to have such a file, so I wonder how to do it there. You need to document that. Otherwise the fine is simple, but okay. > > Yeah right, but you missed the depend in debian/control. > > It should be ok now. Yeah, alright. > The first patch is now splitted into two patches: one for $DESTDIR and > one for permissions. Great. > However, I'm working with the upstream developer, and we'll apply the > patches as soon we are sure all is fine with the package. Perfect. > I've moved one of them to Suggests. Okay, good. > > - The enumeration in the description is confusing. I still think that this is true and I would also prefer a more terse description. Bluemindo is a really simple but powerful audio player in Python/PyGTK, using GStreamer. . Features include: * Download pictures for artists and album or lyrics of the current playing song * Different view modes (lightweight, basic, normal or full) * Plugin support * Desktop notifications * Change the status message of the Gajim Instant Messenger * Send music to your last.fm profile or your Jabber account I think its not adequate to over-detailled describe the feature (like the details of the view modes). Thats what documentation is for. The user just needs a chance to decide weither this player is worth beeing tried out. I'm open for discussion if the 3 items that are featured via plugins should be handled seperately, but I'm arguing that they are part of the package distribution so this is eventually not needed. About the code duplication thing: If I do search for example for audioscrobbler.py with apt-file, then I do find 4 or 5 different copies of this file. Even if upstream makes changes to this file (which is bad and you should teach him not to do so) it is still a code duplication and probably needs security support. So your best bet is to inform the security team, latest once the package gets accepted in the archive. Best Regards, Patrick [1] http://packages.debian.org/changelogs/pool/main/d/dnsproxy/dnsproxy_1.15-5/dnsproxy.copyright -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]