Re: bitpim binary modules breaks Gentoo QA policies

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

> On the other hand, I am still waiting for a reply to my response to a
> Debian developer in 2004 :-)

Hi, everyone!  I'll take that as my cue to delurk (which I would have
done somewhat earlier if not for an unfortunate misunderstanding with
regard to moderation, but never mind that...).

Anyway, I can't speak to the earlier effort, as it predates my
interest in BitPim and I'm not personally acquainted with anyone
involved, but I'll be glad to comment on the current state of affairs.

I have prepared and uploaded packages of BitPim 0.8.08 for Debian
unstable (aka sid, and the usual entry point into our archive);
because they are completely new to the archive, they still need to
undergo formal ftpmaster approval, which probably ought to happen
before too much longer.  (Future uploads should experience no such
delay).

Of course, unstable is not for everybody, and a lot of users prefer to
run official stable releases or the intermediate testing distribution,
which aims to stay reasonably up to date while avoiding a lot of the
problems that can plague unstable, and from which stable releases are
cut every so often.

It should be possible to keep the version of BitPim in testing
reasonably current (generally no more than one upstream release
behind) without too much special effort, especially if I set higher
priorities for uploads with particularly important fixes.  Stable is
another matter, but there's an auxiliary archive at backports.org to
which newer versions could go.

The actual packages contain just BitPim, with dependencies on
everything else it needs (including DSV, which I had to upload
separately, but shouldn't need much subsequent attention.)  The only
drawback of this is getting a slightly older version of wxPython than
BitPim wants because Debian's wxWidgets maintainer considers 2.6.2's
Gtk+ port too buggy to upload; however, it wasn't too hard to adjust
brewcompressedimage.py accordingly, and other code seems unaffected.

Incidentally, ReleaseForge (releaseforge.sf.net) claims to make the
file release process a lot less painful; I've never had reason to try
it, though.

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642