Re: bitpim binary modules breaks Gentoo QA policies

"Roger Binns" <[email protected]> writes:

> Note that ffmpeg needs to be built with mp3 support.  Also I

Due to patent concerns, no official Debian package may support mp3
encoding. :-/  However, there are unofficial LAME packages against
which certain official packages (ffmpeg included) can be rebuilt, with
the user assuming any liability.  Also, some official packages (again
including ffmpeg) support encoding mp2s, which a lot of mp3 decoders
can handle; would that be an option here, or do phones specifically
require mp3s?  (I can't readily test on mine [a VX5200] at the moment,
and don't know how typical it is anyway.)

> believe that netpbm command line options and binary names
> kept changing.

AFAICT, Debian's current netpbm binaries should support BitPim's
usage, so that at least is not a problem.

>> - Official man pages, in either roff or DocBook format.  It's okay if
>>  these defer to the existing HTML documentation for most details, but
>>  there should still be *something*. 
>
> Please send me what you have, and I'll add it to the help
> directory.

Attached; thanks!

> However it is pretty much going to point to the gui help.

As I said, that's sufficient, and by no means unheard of.

> Once we have a command line version of BitPim then
> this becomes more important.

*nod*

> Can you send me the script have already and I will add that as
> a Makefile.  It won't do any dependency checking, just always
> build everything on invocation.

Also attached (as "rules").  The first and last few lines are
essentially Debian-specific boilerplate, but most of the stuff in the
middle could probably stand to be factored out.  Anyway, a
"brute-force" approach is fine by me.

> BTW is there a need for it to be a Makefile, or is a shell script
> ok?

Either is okay, but casting it as a makefile may be more convenient
for everyone, as I'd like it to support build, clean, and install
modes, with user-specified target directories.

Thanks!

> We are currently tied to 2.3 anyway.  2.4 on Windows uses a newer
> version of Microsoft's compiler which requires new C library DLLs
> which aren't redistributable with GPL applications.

Fun.

> I didn't look.  But given I asked the author and he wasn't interested
> in a command line version, I'd expect that the code isn't remotely
> structured in a useful way to make command line work.

Ah, well.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [email protected] (NOT a valid e-mail address) for more info.