Am Dienstag, den 07.04.2009, 20:27 +0200 schrieb 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. Ok, we've waited some months now and according to your bug list only 5 packages are missing. xine-lib, xine-lib-1.2 are ported already IIRC, mpc123 was ported upstream already so that makes 2 packages (k3b and libtunepimp). Do you think now is a good time for an upload or shall we really wait until the last package is ported?
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil