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 debian@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
Attachment:
signature.asc
Description: This is a digitally signed message part