[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: swftools - a collection of tools for SWF file manipulation

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


>               * 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.


>       * 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?


>       * 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

>       * 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,
:r ~/.signature

Attachment: signature.asc
Description: Digital signature

Reply to: