Hi Paul, On Sat, Dec 24, 2005 at 08:21:30PM +0800, Paul Wise wrote: > On Thu, 2005-12-22 at 18:11 +0200, Simo Kauppi wrote: > > > I'm looking for a sponsor for swftools, a collection of utilities for > > manipulating and creating SWF (Flash) files. > > I'm not a DD, but I have some comments on the package and other things: > > * The ITP needs to be retitled from an RFP, as suggested by this: > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging Ah, of course. I thought it got somehow automatically changed when I sent my addition to the bug, but it is only in the header of my addition :) > * You might want to use dpatch/quilt/cdbs-simplepatchsys to > separate out the different patches (I see manual page changes > and build system changes) I need to learn how to use those tools, so I can do it properly... The changes to the man pages came from accidentaly running lintian -I instead of lintian -i. Besides the wrong indentation didn't look good IMHO. I'll ask those changes to be made in the upstream anyways. > * debian/rules: > * CFLAGS should include -g -Wall I thought it is enough that -Wall -g comes from the configure script when called with --enable-warnings --enable-debug. Do I need to add those flags to the debian/rules "just in case". > * some sponsors prefer that you remove commented out dh_* > lines OK, no problem. > * The FAQ should to have the compilation related questions > deleted. It is probably a god idea to get upstream to split it > out into FAQ.INSTALL and FAQ (or similar). I'll talk to the upstream... > * debian/watch: delete or (preferably) fix it I'm not sure if this file is generally used. I could probably remove it, but just for the future reference, how would one fix it? Removing the commented lines, or...? > * debian/control > * The bullet points need spaces after them OK. > * Please add a Homepage line like this: > http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-upstream-info Thanks for the link :) I was looking for this, as I have heard somebody talking about that field before. > * debian/copyright > * generally, copyright notices are like this: > Copyright 2004-2005 John Doe > Copyright 2005 Sam Samuelson > * You forgot to list other copyrights from these > dirs/files: pdf2swf/xpdf/ lib/MD5.c lib/action/ > lib/modules/swfrender.c src/gif2swf.c pdf2swf/fonts/ > swfs/ Yes I did. Grepping for Copyright in the files gives quite a list of years for different files. I guess I need to summarize those somehow into the debian/copyright. > * For the libart and other external non-modified libraries > embedded in the tarball, please make sure that the binaries link > to external debian packages for these, and do not compile the > embedded versions. Ah, I didn't notice we have libart in Debian. Good point. > * debian/README.Debian: You probably don't need the last 4 > paragraphs, the first sentence of the 3rd paragraph and the 1st > paragraph. OK. > * debian/links: any reason you disable the linking in > swfs/Makefile.in and use debian/links instead? The linking from the Makefile.in linked to /home/myhome/projects/..., which didn't feel good (eventhough it worked when installed). Building in two different machines gave two debs, which where different in that respect. So, it seemed like a good solution :) > * I'm confused as to why you would use --disable-lame and also > patch the build system. Also, wouldn't it be better to just let > the build system detect LAME and use it if possible? This way > users can easily rebuild the package with LAME support if they > wish. Disabling in both places is probably an overkill. The problem was actually with the avi2swf and wav2swf which compiled without the lame, but did not work. So, I wanted to make sure that the build doesn't produce any non-working binaries. I need to have another look what is the best way to build it. > * Also, I'm confused as to why you disable installing the header > and library. Because they didn't have any documentation and I wasn't sure if they can be used without the lame support. I was going to add them later. Then again, I guess development libraries don't necessarily need any documentation. So, I'll name it librfxswf-dev and the Python wrapper python2.x-rfxswf (and come up with another name for the library/Python wrapper w/lame). Is the libdevel the correct section for a static library/header files? > * Also, do you intend to enable the python extension? Yes. > * Please don't forget to send the manual page fixes and relevant > fixes to the m4 files and build system to upstream. Good > relationships with upstream projects are important. Sure, upstream seemed very happy about my intention to package it for Debian. > * You might want to upload a version with LAME support to > http://debian-unofficial.org OK, any suggestions about naming? swftools-nonfree, librfxswf-nonfree-dev and python2.x-rfxswf-nonfree? Thanks a lot for your comments. > I look forward to seeing swftools in debian! It might take a while but hopefully eventually :) > -- > bye, > pabs > http://wiki.debian.org/PaulWise Happy holidays, Simo -- :r ~/.signature
Attachment:
signature.asc
Description: Digital signature