Bug#476384: Reverting the libmpc 0.1~r435-1 upload

[Adeodato Simó]

+ Sebastian Dröge (Sat, 21 Mar 2009 09:26:20 +0100):

Hello,

> > > I'll take a look at some packages in the next days and send an status
> > > update to those bugs, maybe raising the severity to important now...
> > Sure, important sounds fine to me, thanks.

> Ok, done... the affected packages are:

> cmus                   ---- Bug #476382
> cynthiune.app          ---- Bug #476381
> gst-plugins-bad0.10    ---- Ported
> k3b                    ---- Bug #476379
> libtunepimp            ---- Bug #476378
> moc                    ---- Ported (FTBFS atm because of other issues)
> mpc123                 ---- Bug #476372
> mpd                    ---- Bug #476377
> mplayer                ---- Bug #476384
> qmmp                   ---- Bug #520596
> quodlibet              ---- Unnecessary dependency, bug #476376
> vlc                    ---- Bug #476375
> xine-lib               ---- Bug #476374
> xine-lib-1.2           ---- Bug #520600
> xmms2                  ---- Bug #476373

> Some of them might actually be ported already but they don't
> build their musepack support with the experimental package right
> now. This might be because the header location has changed
> after I've filed those bugs, now it's final though :)

Well, none of those bugs has been fixed in experimental by now (nor have
a patch), and the one marked as pending (the one that is not quodlibet),
has a comment by the maintainer stating that he intends to disable
musepack support while upstream gets around to fixing the issue. The
picture doesn’t look very promising:

    http://bit.ly/libmpcdec6-transition

I’m all for getting this transition done without leaving the old API
around, but at the same time I don’t want packages unbuildable in
unstable, with failures that are not straightforward to fix, for a long
period of time.

As I said in one of my earlier mails, I won’t feel comfortable with
going forward with this transition until all (or most) of the packages
have tested patches. The thing is that for this to happen, we’re going
to need either time, quite a lot of it, or for somebody to step up and
start “driving” the transition, filling the gaps the maintainers may
leave.

So the question is whether you have the time and inclination to do the
latter yourself, if you want the transition done sooner rather than
later, working with maintainers on a solution for each particular
package (a solution that does not entail, preferably, dropping Musepack
support from the application). For example, Rafael Laboissiere, the
maintainer of libmtp, did exactly this for the recent libmtp7 -> libmtp8
transition: he filed bugs, provided patches, and did a bunch of NMUs,
which allowed us to do the transition in a timely manner.

So, do we have a plan, or do we just opt for waiting? I’m Bcc'ing all of
the involved bugs so that maintainers can send an update on the status
of their bug (to the debian-release mailing list and *your* bug,
please). If a fix exists, please send it to the BTS with an appropriate
“patch” tag or, preferably, make an upload to experimental.

Thanks,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai