José Luis Segura Lucas wrote: > El 26/06/12 17:36, Benoît Knecht wrote: > > I took a look at your package: > First of all, thanks for your quick answer :-)
You're welcome :) > > - Since you're packaging a snapshot version, you should adjust your > > watch file accordingly: > > > > Processing watchfile line for package grive... > > Newest version on remote site is 0.1.1, local version is > > 0.1.1+20120619git27g55c0f4e > > grive: remote site does not even have current version > The upstream authors doesn't have this version available as tarball for > download, I had to create the tarball myself. The main differences > between the 0.1.1 stable version and this git commit is only about the > construct system: I have made some suggestions and they included it in > the repository after the 0.1.1 release. I don't know how to write a > watch file for downloading a specific commit from a git repository. Is > it possible? I just meant that you should use something like opts=dversionmangle (see uscan(1)) so that uscan would remove the "+20120619git27g55c0f4e" part before comparing the debian version with the upstream one. But if you're not going to package snapshot versions on a regular basis, maybe that's not necessary. > > - It seems like all the source files of Grive are released under the > > GPL-2, and not GPL-2+ (according to the license headers in those > > files). You should correct that in debian/copyright, and using the > > same formulation as in the license headers seems like a good idea. > > > > The license for the debian/* files is said to be GPL-2+, but in the > > license paragraph it refers to the GPL-3. > > > > I couldn't find Matchman Green's name in any of the source files; > > are you sure they're one of the copyright holders? > Corrected the license issues (upstream to GPL-2, debian/* to GPL-3). > Matchman Green was the original upstream author when I began to follow > this project, but my e-mails and "real" contact with the project was > made through the other author: Nestal Wan. I will contact upstream again > and ask about this. Yeah, it seems best to discuss it with upstream. Regarding the GPL-3 for the packaging, since it's incompatible with the GPL-2, it would be much better if you agreed to GPL-2+ for debian/*; that way, the source package as a whole can be considered GPL-2. > > - debian/README.Debian should be debian/README.source, although I > > would argue it doesn't contain any useful information at the moment. > You are right: it doesn't contain any useful information. I think it is > a "legacy" file from the templates that I have written at the beginning > of the times :-) > > - In debian/control, the Vcs-Git field is intended for the packaging, > > not the upstream repository; if you don't have a public git > > repository for the Debian packaging, remove that line. > Ok, I have it on github, modified. > > The long description could be improved; please have a look at [1]. > > > > [1] > > http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc > > > > Please run wrap-and-sort from the devscripts package to have the > > Build-Depends field wrapped and sorted (and use ">= 9" for > > debhelper). > Do you mean ">=9" instead ">=9.0.0"? If it is, modified in that way. That's what I meant, yes. > > - Why do you override the hardening-no-fortify-functions lintian > > warning? If you have a good reason to do so, you should explain it > > in a comment in debian/grive.lintian-overrides. > I asked in debian-devel and in hardening-wrapper mailing lists about > that. I had this warning and, after checking with hardeining-check I saw > a possible problematic "read" unsafe call. I find it on the upstream > sources and see that it is safe to link against read instead read_chk, > because the always read the "sizeof" the reserved buffer. I will add a > comment about that. Perfect. > > - Grive includes a test suite, but it isn't built nor run. > I used their CMakeLists.txt without any patch or hack. I will ask them > about it and study the viability of adding to the Debian package > generation script and the way to do so. >From a quick look at the CMakeLists.txt, it seems that cppunit needs to be installed in order for the test suite to be built (so I guess you should Build-Depend on libcppunit-dev). Not sure if it means a simple "make test" would run the test suite then; looks like you'd have to run "./unittest" by hand. > > - In the grive(1) man page, you should end each item in the > > DESCRIPTION with punctuation. > > > > Mentioning that Grive is "for GNU/Linux systems" doesn't seem very > > useful; the person reading the man page is most likely doing so from > > such a system already. > > > > Grive shouldn't be italicized (.I) in the DESCRIPTION. > > > > Please consider removing the AUTHOR section (see man-pages(7) for > > details). Also, the REPORT BUGS section should be called BUGS, but I > > think it should be removed too, as Debian users should use the > > Debian BTS anyway. > > > > Cheers, > The man page will be replaced as soon as upstream release their new > version, because they added this manpage as pull request on their > repository. I will try to convince them to change again the manpage. I > think they probably will want to keep the AUTHORS and REPORT BUG > sections (my fault), but it can be removed as quilt parch when they > release the new version. > > I have seen man-pages(7) and I will remove from the package the AUTHORS > and REPORT BUG sections. I will study the new circumstances with their > man page when it arrives. Sounds good, thanks. > Only a question: do I need to update the debian-version number for each > revision or I only have to update it when it is at debian archives? You don't have to increase the debian version until it actually gets into the archive. Some people prefer to do so anyway, but that's essentially a matter of taste (just provide a link to the .dsc file every time you update the package). Seems to me that the common practice is to keep the same debian version throughout the RFS process though. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120627104726.ga20...@marvin.lan
