[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: gvb

Hash: SHA1

Holger Levsen ha scritto:
> Hi Pietro,
> Unfortunatly I dont have time to sponsor it (as this also needs
> continous involvement),

You mean "every package does" or "this package particularly does"? (If
it's the second: why?)

> but I had time to briefly look at it and here are some comments:
> On Sunday 22 June 2008 10:31, Pietro Battiston wrote:
>> This seems to me the right place to look if there is someone
>> interested in sponsoring a package I made.
> still, you should probably crosspost to debian-mentors, too...

Posting do debian-mentors is the first thing I did, some days ago...
Anyway, I'm cross-posting this reply too.

>> The package is gvb
>> (http://mentors.debian.net/debian/pool/main/g/gvb/gvb_1.1.2-1.dsc)
>> It is completely GPL v.3. I am the upstream developer.
> in debian/copyright you say it's GPL2+, while the file COPYING says
> GPL3+ - please make up your mind ;)
> (And then debian/copyrights refers to
> /usr/share/common-licences/GPL, which is the GPL3, so that's
> another (normal) bug.)
> Another minor bug in debian/copyright: "The icons of the program
> are screenshots of the program itself and also are covered by GLP
> license." - GLP? :)
> Please also remove the word "nice" from the short description
> (debian/control), all software is nice, isn't it? :)

No, I think Linux Kernel is a "nice" piece piece of software in a geek
gvb is (I hope) in a more literal sense. I just wanted to spot the fact
that some attention is given to aestethical appearance of the GUI.
Anyway, I understand there is risk of misunderstanding, so I removed it.

> Also I think you can completly drop the last paragraph of the
> description: "It is written in Python and based on Pygtk and Cairo
> for the interface. It relies on scipy for calculations." - this
> information is provided by the (build-)depends and can also be
> represented with debtags.

Thank you for spotting those errors. Actually, I did remove references to
Python, Pygtk and Cairo because they are indeed informations targeted
basically to developers, but I think it is better to keep the one to
scipy, because it is a library targeted even to non developers (e.g.
as replacement for matlab), and for instance someone using Synaptic
(where you don't see immediately dependences) could find it interesting.

Obviously, all this has been fixed in version 1.1.2-2:

Thank you for your attention

Pietro Battiston
Version: GnuPG v1.4.6 (GNU/Linux)


Reply to: