On Wed, 2008-01-02 at 23:25 +0000, David Newgas wrote: > On Wed, 2008-01-02 at 13:14 +0000, Neil Williams wrote: > > On Wed, 02 Jan 2008 12:46:11 +0000 > > David Newgas <david@newgas.net> wrote: 1. I cannot check your GnuPG signature on the .dsc because you do not appear to have sent your public key to a keyserver. $ gpg --keyserver subkeys.pgp.net --send-key 0xC23D7A8B http://www.dcglug.org.uk/linux_adm/gnupg.html You must upload your public key to a keyserver before anyone can sponsor you. 2. Too many executable files: $ find . -perm "0755" -a -type f Please ask upstream to make a sane tarball or ask upstream to simply use: find . -perm "0755" -a -type f | xargs chmod 644 before making a fresh tarball. (You'll need chmod 755 debian/rules if you do that yourself). 3. Inaccurate debian/copyright. $ licensecheck -r . Many files are listed as free but not GPL, these need to be detailed in debian/copyright. Use the machine intepretable format: http://wiki.debian.org/Proposals/CopyrightFormat 4. Depends: > > > Ok, how about this: > > > > Umm, I meant programming language: C, C++, Python, Perl, etc. > > Hehe. The program itself is Perl, but it has plugins written from C, > perl and python. All those plugins appear to be packaged as a single binary package. I can't see any point in that. Either they are plugins (in which case users get to choose which ones to install and use) or they are core to the program. What is the point of forcing all users to have all the code for all plugins even if they have disabled Recommends and don't have the packages to run the full code? Package the plugins separately with genuine Depends: and then recommend the plugins only. This should leave the main package with very few dependencies. 5. The manpage is awful - probably the worst I've seen. For a command-line tool (curses mode) the manpage should detail and expand on most of what is in doc/README in a usable, verbose format. Every single command, option, use case and hint needs to be in the manpage. If you don't fancy editing groff, use doclifter to convert to xml and xsltproc back to groff prior to packaging (so that you don't need to build depend on xsltproc). You have a commented out rule using docbook-to-man and an sgml file already - have you kept that sgml file? The manpage needs to be easily ten times longer than it is now, if not more. > > > Plugins are implemented for existing common tools, and new > > > plugins can be written in any language. Wicrawl is able to use multiple > > > cards, and eventually will be able to use multiple computers. Remove the bit about "eventually" from the long description - put that in README.Debian if necessary. > > Thanks for the long description, it answers a lot of questions. If you > > can answer the other questions above, I'd be willing to review it in > > more detail (subject to the programming language not being python). > > > > That would be fantastic. Only one portion of it (the "apwebcrack" > plugin) is written in python, so I don't know if you still feel like it. > 6. I'm not convinced that the python dependency is correct and I'm no expert on python. If you packaged the plugins separately, this would be easier to solve. 7. The menu file tries to run: /usr/sbin/wicrawl This won't work - it is pointless having a menu command if the user cannot run it from the menu and in this case, the user would need a method of entering a sudo password, yet you don't give that opportunity. Investigate either having no menu file or using something like sudo-to-root -X 8. README.Debian is empty - either put something in it or remove the file. 9. debian/watch contains lots and lots of junk. Watch files rarely need to be more than 3 lines. Pick the lines you need and delete the rest. Plus, the watch file does not work: $ uscan -dehs --no-download <dehs> <package>wicrawl</package> <debian-uversion>0.4a</debian-uversion> <debian-mangled-uversion>0.4a</debian-mangled-uversion> <upstream-version>cvs</upstream-version> <upstream-url>http://midnightresearch.com/local/packages/wicrawl/wicrawl-cvs.tgz</upstream-url> <status>Newer version available</status> </dehs> status should be Up to date. 10. debian/rules doesn't call dh_python or any other python-related rules. You need to check this with someone more familiar with python packaging. 11. I'm not sure why, but the .diff.gz I get is far too big: 1192244 net optional wicrawl_0.4a-2.diff.gz 12. The package itself is easily big enough to split into lots of packages - at least 4 IMHO, possibly 6 or more. The examples should go into a -doc package and be mentioned in the manpage. The /usr/share/wicrawl/ui/themes should be in a -data or -common package. 13. What's this ./usr/share/wicrawl/include/perl/ ? /usr/lib/perl5/Module/Name/ or /usr/share/perl5/Module/Name/ /usr/lib/ if the perl module links directly against an architecture-specific binary (like a shared library), /usr/share/ if the dependencies are all perl. 14. The package includes .c and .o files! No,no,no. No C files and the .o files need to be a proper static or shared library. ./usr/lib/wicrawl/plugins/cowpatty-wpa-psk-bruteforce/cowpatty/cowpatty.o ./usr/lib/wicrawl/plugins/cowpatty-wpa-psk-bruteforce/cowpatty/cowpatty.c 15. What are these .dump files??? $ find . -name *dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/eap-test.dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/wpa2psk-linksys.dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/wpapsk-linksys.dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty-fpga/eap-test.dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty-fpga/wpapsk-linksys.dump These exist in the upstream source. $ file ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/eap-test.dump ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/eap-test.dump: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535) d29636d7a240b51b7c6c840084f65eea ./plugins/cowpatty-wpa-psk-bruteforce/cowpatty/eap-test.dump d29636d7a240b51b7c6c840084f65eea ./debian/wicrawl/usr/lib/wicrawl/plugins/cowpatty-wpa-psk-bruteforce/cowpatty/eap-test.dump Binary files, copied, unchanged, into the package. No. Sorry, I'm not going to sponsor this one. It simply is not in good enough condition and would take *far* too much of my time to take you through each stage, plus you'll need the input of a different sponsor for the python stuff anyway. Retitling back to RFS. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part