-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2010-09-25 15:28, David Steele wrote: > Dear mentors, > I am looking for a sponsor for my package "gnome-gmail". > > * Package name : gnome-gmail > Version : 1.6-3 > Upstream Author : David Steele <[email protected]> > * URL : http://gnome-gmail.sourceforge.net/ > * License : GPL > Section : gnome > Language : Python > > It builds these binary packages: > gnome-gmail - Add Gmail support to GNOME > > The package appears to be lintian clean. > > The upload would fix these bugs: 597903 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/g/gnome-gmail/ > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/g/gnome-gmail/gnome-gmail_1.6-3.dsc > > Gnome Gmail adds support for the Gmail web client as a GNOME Preferred > Application for email. Once selected, mailto links, Nautilus "Send > File" commands, Open Office "Send Document" commands, etc, will cause > an appropriate Gmail window to open in your default browser. > > You can read more about Gnome Gmail from the following Press coverage: > > Lifehacker - > http://lifehacker.com/5493654/gnome-gmail-tightly-integrates-gmail-into-linux-desktops > Linux Magazine Online - > http://www.linux-magazine.com/content/view/full/42375 > Sourceforge Blog - http://sourceforge.net/blog/gnome-gmail-made-simple/ > > Thanks for your assistance > > Hi (Sorry for the double mail - I forgot to send it to the mentor list as well so others could see it had been answered) Thanks for your interest in Debian. It looks like you have not received any feedback on nor found a sponsor for your package yet. I have spent some time reviewing your package and got a few comments for you, which I hope you find useful. Please note that I am not a Debian Developer (DD), so I cannot sponsor your package even if you address all my comments/remarks. Also neither python nor GNOME is my strong suit, so there are possibly some python/GNOME specific things that I have missed in my review. On a related note have you considered contacting/joining the Debian GNOME or the Debian Python Apps team? These teams may be a better source for help with your package and possibly also sponsors for your package. Also you may want to read [1] if you have not already done so; there are talks about how to improve the current RFS template and what some mentors look for/would like to see in an RFS. Anyhow; my review: d/watch: - Contains a lot of unused comments (left overs from dh_make) d/rules: - lots of unused comments (looks like left overs from dh_make) - Consider using either dh $@ (a.k.a. the dh7 method or "tiny rules") or cdbs. These tools can handle your entire build without any override targets/modification to their default setup/run. This would also remove a warning during the build [2]. - Even if you do not use dh7 or cdbs you should clean up your d/rules files. As an example, there is nothing to do in the binary-arch target. Note: if you are joining a team, the team may have a helper tool preference or a build style. In that case you probably want to stick with the build styles preferred by the team. d/control: - ${shlibs:Depends} does not make sense for arch: all packages. It finds "arch dependent" dependencies for native shared libraries. - The Description (and possibly the Synopsis) needs improvement. It might be a help to have a look at [3]. d/changelog: - You have multiple revisions in your changelog, but this package has not been released into Debian. Consider merging it into a single entry[4]. Note there is no reason to repeat the "closes" for the same bug (see man dpkg-buildpackage/dpkg-genchanges about the "-v" flag for more information). Though if you need the package built with the -v flag be sure to mention this in your RFS, so that your sponsor is aware of it. d/copyright: - Looks like a mix of "freestyle" and the DEP-5 machine readable format. Either of those formats are acceptable, but the mix appears a bit "weird" for me. I would recommend you choose either of the formats and stick to it. - You have claimed copyright for the year 2009, but there is no mention of copyright in the upstream files except for gnomemail.glade, which claims copyright for the year 2010 (about 200 lines into the file). I am not sure if that single copyright mention in gnomemail.glade is enough for the FTP-masters. Optimally you would write your copyright statement plus the "license header" in all your source files. - There is no explicit mention of allowing the GPLv2 or later in your upstream pacakge as far as I can tell. COPYING only contains GPLv2 and none of the source file seems to carry an explicit license. Note: The "How to apply GPL v2 to your program" example in COPYING is not a permission to use your program under GPL v2 or later. You have a "debian/debian/" dir in your source package. I skipped all files in that dir, because I assumed their inclusion to be a mistake. Lintian also has a few coments about your (binary) package: $ lintian -EvI --pedantic ../gnome-gmail_1.6-3_i386.changes [...] N: Processing binary package gnome-gmail (version 1.6-3) ... I: gnome-gmail: extended-description-is-probably-too-short P: gnome-gmail: no-upstream-changelog W: gnome-gmail: package-installs-into-etc-gconf-schemas etc/gconf/schemas/gnome-gmail.schemas The I tag I already mentioned in my comments about your d/control; it is usaully far from a requirement to fix the P tag - though you may still receive a comment on you (as an upstream) not maintaining an upstream changelog. Finally there is the warning (the W tag) which you ought to fix. If you do not know what the tag means you can use: $ lintian-info -t package-installs-into-etc-gconf-schemas and lintian will explain it to you. (lintian also has an argument which makes it print the explaination by default, so you do not have to use lintian-info afterwards). Note, I run lintian with more options than the default setting, since I tend to find the extra tags helpful. While you are not required to include all the tags like I do, most sponsors expect you to fix all E and W tags (and a lot also expect most of the I tags to be fixed) except when their happen to be "false-positives". If you have any questions, please do not hesitate to write back, ~Niels [1] http://lists.debian.org/debian-mentors/2010/10/msg00005.html [2] dh_install: You asked that all arch in(dep) packages be built, but there are none of that type. [3] http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-control Particularly section 6.2.1 - 6.2.3 (inclusive) [4] I know that some sponsors prefer you always increment the debian revision between their feedback. Personally I would keep only a single revision until I got a sponsor that preferred it that way; however, if you prefer this method, then by all means stick to it! Ref: http://people.debian.org/~codehelp/#sponsor (item 2) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkyqV2wACgkQVCqoiq1YlqwcGwCfXVn4I5JelWPjaRVs7/2YVmQ1 bNQAn3/D27mJnvdTeTdbcYjQDHPREPg1 =2gRH -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
