Hallo Antti, yes, I received your mail already, but I simply did not have time to take another look. Formally I have to state that I did not yet decide if I sponsor this package, but of course do the offered review.
Am Donnerstag, den 12.03.2015, 08:16 +0200 schrieb Antti Järvinen: > Tobias Frost writes: > > just re-upload to mentors, and reply to this RFS bug with the changes > > you did (basically quoting my mail and briefly say on every point what > > you did.) I'll pick up from there. Don't file another bug. > > Hello Tobias, > > I think I left you out of loop for my latest comments regarding my ITP > bug at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779377 ; do > you think there is still something to do regarding packaking/licensing > etc.? > > If this thing moves forward, maintenance within collab-maint is very > ok for me, especially if collaboration means also that that there is > someone who might help me when I'm about to commit potentially > disastrous actions..as said, I'm long-time debian user, have some > years behind in various sw development circles but I'm totally clueless > about ways of getting things done iwnside debian organization. > > -- > Antti Järvinen Ok, let's do another round of review. -> please use wrap-and-sort(1), this makes reviewing easier and looks nicer. d/changelog: -> Debian version part needs to be -1 (do not iterate it until uploaded the first time) -> As this is a new package, you can upload to unstable; one should only package refrain when there is already a package in testing -- to avoid disruption. (Sorry, I know you changed that before; but Riley was wrong here.) -> There are extra trailing spaces.. -> Do you know dch(1)? d/control: -> Why did you switch do cdbs? (I do not sponsor packages using cdbs) -> You have both B-Ds on cdbs and debhelper. The version >= on debhelper is not needed; its as already fulfilled by wheezy. Same for dpkg-dev. -> You MUST NOT specify libraries dependencies for your binary package -- this is what ${shlibs:Depends} is supposed to do for you. -> In the description, there is an extra space before a ";". It should be also written gender neutral. -> VCS-* fields are missing. -> You are aware that libgcrypt-dev | libgcrypt11-dev will always select libgcrypt-dev on the buildds? (That's ok, but you just need to be aware) -> Please do not use a pacakge-related email adress for Maintainer. You certainly can have something like deb...@katiska.org, but avoid having the package name in it. (see also the end of this mail for a rationale; Debian tools usually associate you by your mail, and if you have more than one package with different emails that won't work well) d/copyright: -> You do not need to repeat the License-Text for the same license. Just use Licene: <license> for the Files section and have a dedicated License: Paragraph with the actual License text e.g at the end of the file. Sketch: Files: a Copyright: 2015 foo bar License: LGPL-2.1 Files: b Copyright: 2014 joe doe License: LGPL-2.1 License: LGPL-2.1 GNU Lesser General (...) (PS: No need to repeat the Words "(C) Copyright" in the Copyright lines; Just the names are ok.) Nokia-Part: You need to have the _verbatim_ copy of the license grant. Yours is two paragaphs too short, and the License is actually "LGPL-2.1-with-Nokia-Exception or GPL-3.0 or Nokia-nonfree". You need then also to provide that file in your sources and also have this text in the License paragraph. "Nokia-nonfree" refers to the last paragraph starting with the headline "Other Usage" (I did not yet check remaining d/copyright for completeness and correctness) -> turt*.png (Upstream advice: There are many coppies of your turtle in the repository. You should only keep one. Do you really need also the gimp files for the "small" ones? I'd clean up a little; But this is not related to the Debian packaging) For Debian it is required that you build everything from source. Let's say that your turtle with the highest resolution is your source. You then need to regenerate all the small versions at build time. -> classified-ad.1 It is usual that user data is not removed from $HOME/ upon uninstall, but it is unusual to tell that the user in the manpage. So should rephrase that, maybe under a Files section in the manpage that user data is stored here and contains encryption keys. Some stupid question regarding this (I did not run your programm yet): Do they need to be safeguarded, btw? Is there a password on them? Are the access rights to the database set to sane values, so that only the user can access (e.g. 0600) -> d/rules Sorry, I do not sponsor cdbs based packages. Some lintian messages: I: classified-ads: spelling-error-in-binary usr/bin/classified-ads altough although P: classified-ads: no-upstream-changelog I: classified-ads: using-first-person-in-description line 5: me I: classified-ads: hyphen-used-as-minus-sign usr/share/man/man1/classified-ads.1.gz:11 I: classified-ads: desktop-entry-lacks-keywords-entry usr/share/applications/classified_ads.desktop I always worry a little when upstream is also the maintainer, that they only focus on their program. However, reviewing and educating how to package is lots of work (as you see from this review) and should help Debian in the end. Therefore I would really appreciate if you want to get a little more involved into Debian, not only maintaining your own package but also show that you want to contribute more, eventually maintaining more packages, do other Debian related stuff... And if it's fun to you, maybe even taking the next steps of involvement in the future. Hint: Check out how-can-i-help(1), or look at https://www.debian.org/devel/wnpp/. Let me know. If you want to give it a try, you'll secured your sponsor. -- tobi
signature.asc
Description: This is a digitally signed message part