On Tue, Sep 13, 2005 at 06:11:09AM -0400, Nathanael Nerode wrote: > It appears that the KDE transition is totally tied up to the jack transition, > via arts. I see no plausible way to break this linkage. I agree, and don't see any value in trying to find one, since there don't seem to be any significant package clusters waiting on jack other than KDE itself. > The JACK transition is currently waiting for fltk1.1, thanks to zynaddsubfx > and spiralsynthmodular. But there's little point in breaking that link, > because... > The FLTK C++ transition is tied up with the KDE transition thanks to openexr > (kdelibs depends on libopenexr2c2, and openexr depends on libfltk1.1). <nod> > We should probably request that no uploads be made on anything depending on > any of these, except to transition, fix RC bugs, or fix FTBFSes. At this stage, I don't see that this would do us much good; there are still several hundred packages that need to be updated for the KDE transition, AFAICT, so the only thing it buys us to say "no other uploads" is less load on the autobuilders, and there's no particular reason to prohibit uploads on this particular set of packages in that case. > The FLTK linkage could be broken, and the FLTK transition put through first, > by deliberately breaking the openexr program in 'testing' (leaving libopenexr > working), as well as removing spiralsynthmodular and zynaddsubfx. The FLTK > transition isn't ready to go through yet even with this, unfortunately; quite > a few depending packages still need to be transitioned. If this seems like > a good idea, I can work out what needs to be done for FLTK and file bugs etc. cinepaint also depends on both fltk1.1 and openexr, and would have to be broken or removed to allow fltk1.1 in without openexr/kdelibs. I actually don't see that there are too many depending packages that still need to be transitioned in order to let the fltk1.1 update in. There are a few missing binary packages (ax25-tools, htmldoc, stripclub, xpp), and there are the packages which depend on both fltk1.1 and either jack or openexr, but otherwise there seem to be only four packages not yet uploaded for the fltk transition. I think it would be fine if you would file bugs for those now. > At the moment, the biggest holdup for the KDE/JACK transition is packages > which have ICEs on m68k. On the JACK end of things, these include > flac, stk, and spiralsynthmodular (all unreported). These packages all seem to be using steroidal optimization flags and probably build fine on m68k if those are turned off. > ecasound2.2 is suffering from a segfault (in dvips, I believe) > building the docs on powerpc and s390. Hmm. Issue with char signedness? > Here are some hints which might help this and other things slightly. > # Wine still hasn't been updated to new JACK, despite an RC bug (#321222) > # open for 40 days. > remove wine/0.0.20050628-2 Why remove instead of NMUing? > # Galan hasn't been updated to new JACK, despite an RC bug (#317196) > # open for 68 days > remove galan/0.3.0+beta4-1 Seems to only recommend libjack rather than depend, though? > # seq24 ties libsigc++-1.2, a complex transition, to the JACK transition. > remove seq24/0.6.3-1 Does the libsigc++-1.2 transition become substantially simpler if we selectively transition other packages to gtkmm2.4/libsigc++-2.0? > # Separate gtkmm2.4 transition from gtkmm2.0 transition (yeech) > remove gtkglextmm/1.0.1-3 Again, why would we keep gtkmm2.0 around instead of transitioning everything to gtkmm2.4? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature