Hi Nick, this is a shallow review of your package. Unfortunately I am lacking experience with CDBS packages and your package is quite complex. Hence I am unsure if I will sponsor it eventually. That said, I'd love to see kismet in shape in Debian.
* Please clarify the license of these files in your debian/copyright file: + apple80211.h: the header states: "From MacStumbler, which is under GPL" + extra/*: Lacks copyright header. Given all other files do, I suspect this is by purpose which means it is not known whether these files are distributable. + Likewise for packaging/dpkg* (I would also hope, this script is burned with fire) + Likewise for ruby/*. No fire this time, though Consider repackaging the tarball if you cannot find any clarifcation regarding these files as they mostly seem irrelevant to me. Moreover, please note you are linking against OpenSSL but the package is licensed under the terms of the GPL-2. However, only a few files do have a OpenSSL linking exception. Note, the GPL is not compatible to the OpenSSL license [1]. Ask upstream for clarification on that matter. * Where does this package come from? Did you base your work upon the Ubuntu package? I'm asking because of "kismet (2008-05-R1-4.3build1) precise; urgency=low" for the previous upload. If the only difference to the Debian version is this Ubuntu binNMU, please remove this changelog stanza. * What is debian/kismet-plugins-restricted.install? These refer to a binary package you don't build. Were they split to a non-free package previously? If yes, what did change to make this split unnecessary? License of the plugin-ptw/* stuff seems DFSG free to me (but it is listed in kismet-plugins-restricted as debian/tmp/usr/lib/kismet/aircrack-kismet.so I think). * Please fill out copyright headers of debian/po/templates.pot properly. While you are it, the po translation files are not complete. Moreover, do not prompt in question style in debconf templates. Formulate the data you want to get from the user in an open way ("give me $foo:"). * You do not depend on adduser, but you use it in your postinst maintainer script. Same for libcap2-bin and setcap. Moreover, the maintainer script does not look very sane. See [2] and policy §6.5 [3] to see how maintainer scripts are invoked and change it to something properly. I am referring to the way you are determining whether you are upgrading. Do also set -e in your maintainer scripts. * Likewise you are blindly adding users provided by user input to usermod like this: for x in ${RET}; do usermod -a -G $GROUP $x done You should at least verify whether the supplied user(s) exists before passing random inputs to usermod. * The postrm script looks acceptable, but note it is consensus not to remove users anymore once created. There is no safe and sane way to determine whether the site administrator hijacked the created group on purpose. * Maybe you should bump the debhelper compatibility to v8. * Consider writing man pages for your binaries lacking these. * Lintian says: E: kismet: su-wrapper-without--c usr/share/applications/kismet.desktop su-to-root E: su-wrapper-without--c N: N: The menu item command or desktop file uses an su wrapper such as N: su-to-root without the -c flag. This is a syntax error. N: N: Refer to the su-to-root(1) manual page for details. N: N: Severity: important, Certainty: certain N: N: Check: menu-format, Type: binary [1] http://www.openssl.org/support/faq.html#LEGAL2 [2] http://wiki.debian.org/MaintainerScripts [3] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact -- mit freundlichen Grüßen, Arno Töll, BSc. GnuPG Key-ID: 0x9D80F36D Wavecon GmbH | Ludwigstrasse 2 | 90763 Fuerth Web: wavecon.de | Mail + Jabber a...@wavecon.de -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature