Re: Re: RFS: bluemindo
Hi,
sorry for my late reply. Has been a bit busy these days.
On Sat, Jun 28, 2008 at 02:13:17PM +0200, Thibaut GIRKA wrote:
> > - Important: You install an extra-license file which causes a lintian
> > warning. Refer to Policy Manual, section 12.5 for details. Please
> > always check your package against a recent lintian from unstable.
>
> Hm. The fact is that bluemindo reads the file itself.
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.
> > - debian/rules:
> > Hm. You use CDBS, but you don't use python-distutils. You may want to
> > change that. Otherwise you need to handle some things yourself. See
> > [5] for some informations.
>
> Hm... Done (I think).
Hm. Why don't you use the way thats written down in the CDBS docs [1]?
Is there a special reason for your manual calling of dh_pysupport?
I also don't think that this is enough.
> > - debian/copyright:
> > - Please don't throw copyright and license informations together. If
> > you have parts in the source tarball that are not licensed the
> > same way as the main program itself, then I recommend you to open
> > another License block with an additional "(for ...)" that states
> > which file is meant. BTW. what do you think about this [1] format?
> > - (C) has no legal meaning. You have to replace it with ©.
>
> I changed it. I it better now?
I see that you adopted the machine-parseable copyright format. So do you
like it?
However it seems still a bit bogus to me:
Most files use the GPL-3 as license so citing parts of the license
explicit is not needed and imho makes no sense, too. Additional you have
a "License.." block at the end of the file, which is possibly un-needed
(because the machine-parseable part replaces it) but in my opinion a
good approach, because I really prefer to still have a human-readable
part as long as there is no parser that makes the file more
human-readable by people who are not so technical experienced.
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).
> As the package provides a png file in the good place, can I use it? or
> do I have to make a xmp file?
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.
>
> > - debian/README.source:
> > You should rename it to .source instead of .Source because thats its
> > filename according to policy. Otherwise its incomplete. It needs to
> > document at a bare minimum: 1) Creating a fully-patched source, 2)
> > Modifying the source and save those modifications to let them be
> > applied during building 3) Remove applied modifications. See [3]
> > for the mail originally sent by Russ.
>
> Er... I don't really understand how it works.
> Just use debian/rules patch to patch, debian/rules reverse-patches to
> remove the patches, and debian/rules binary to build?
Did you read the links I've posted? Its described in detail, there.
But to make it clear:
This file is for other people then you, so that they have a chance to
lookup how certain processes work with your package. E.g. for the
security team to read up, what they need to do, to get a fully patched
source, create new pages, remove patches. That is that people who
usually don't maintain your package and probably usually use other
methods (e.g. quilt and debhelper instead of CDBS and patchsys) have a
chance to update your package (for example due to a security issue).
Whats missing from your file is a documented way to create a new patch.
> I included the one you made, although upstream may change it at any
> time.
Well, thats true for most of the upstreams :-) Basically what you then
do is adapting the package. Hopefully watch files will at some point in
the future be cared for outside of the package at a central location
this will ease its maintainance.
> Compat is now 5.
Yeah right, but you missed the depend in debian/control.
> It may be a bit better, now.
It would be better to make two makefiles of the first one. So that
every patch is for exactly one change. BTW. please do not forget to
forward the patches upstream. The proposed seperating into two pages
also makes it easier for you if upstream integrates only one part of the
patch.
> I think Recommends are adequate. This packages aren't required to run
> bluemindo, but they are required to use several features.
That sounds reasonable. But there is still a question that you should
clear: Are those features really common to the usual user of the
software? Is it someone one usually would expect? If yes, then
Recommends is fine, otherwise you should move such things to Suggests.
> > - Description needs some overhaul. See [6] and [7]. Please also
> > check it for spelling or grammar errors.
> It should be a bit better, now.
Not enough :-):
- The "A" in the short description is useles
- The enumeration in the description is confusing.
Best Regards,
Patrick
[1] https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml#id2528674
Reply to: