Re: Re: RFS: bluemindo
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
Reply to: