On Fri, Jan 09, 2004 at 11:27:44AM -0600, Colin Watson wrote: > On Mon, Jan 05, 2004 at 03:26:27PM -0600, Chris Cheney wrote: > > On Mon, Jan 05, 2004 at 09:55:49PM +0100, Dominique Devriese wrote: > > > I think we all would very much like KDE 3.2 in sarge. I have a newly > > > added application in there e.g., that deserves more attention. > > > However, we have to make a concession at some point, and we have to > > > keep Debian's interests in mind. If other Debian devs see that KDE > > > gets to upload a brand new version, they'll want to do the same, and > > > we can write off all chances to a quick Debian release. > > I fully agree with Nathanael's position here. Uploading KDE 3.2 at this > point will probably kill your chances of getting a working KDE in sarge, > or else delay sarge radically, since the version of KDE in testing is > not currently releaseable. (An installable kdemultimedia would have got > into testing tonight if it weren't for the recent upload; fortunately it > narrowly escaped screwing over newer versions of > jack-audio-connection-kit and alsa-lib, which are needed for GNOME. > There are a lot of interdependencies which still need to be resolved.) People have been asking me for a while to upload a new kdemultimedia so I finally did (after determining how to patch it). I will be doing another final upload of it today since lamont was able to verify how to fix the FTBFS on alpha/ia64. Notice the buildds are still so fscking lagged they haven't even attempted to build several of the kde packages (eg kdebase uploaded Jan 5). Also, I have been sending daily updates of how KDE 3.1.4 is doing in sid. > I'd suggest that KDE ought to be in mini-freeze (bug fixes, no new major > upstreams) until no KDE packages are listed in > http://ftp-master.debian.org/testing/testing_probs.html and in > particular until a modern version of meta-kde is in testing. I'm giving > the GNOME people essentially the same advice. We *really* need to have > stable, working, installable (!) versions of the desktop environments in > testing, and we need them there as soon as possible. The way to do that > is to fix, stabilize, and freeze, not introduce lots of new code. Even when KDE didn't have any open RC bugs it didn't migrate to sarge on its own since it had too many interdependencies... BTW I can't even upload updated versions of KDE 3.1.4 to sid right now since g++-3.3, linux-kernel-headers, and libglut3-dev have bugs causing KDE to FTBFS. > > Another thing to note was that the toolchain was supposed to have been > > frozen in September but there was a new gcc upload just last week on > > 29 Dec 2003... As long as even the toolchain isn't frozen freezing > > other things aren't going to work very well either, for example see the > > kdebase breakage wrt SYS_sysinfo. AFAICT that was broken by new glibc > > with 2.6 headers. Yes, using syscalls the way KDE did was not a good > > idea, but if the toolchain is going to continue to rev exposing more > > bugs in applications what is the point in the freeze? I don't know if > > anyone with power is reading this, but freezing the toolchain at some > > point would be a good idea. > > I don't think there are going to be any more major toolchain changes > from now until release. However there does still have to be *some* work > done on gcc to fix compiler bugs exposed by builds. As far as I know, > this has been the driver for virtually all Debian gcc package work over > the last few months. There don't have to be no changes at all to the > toolchain: common sense applies, and "no major destabilizing changes, > but bug-fixes allowed" is the sense we're looking for. With g++-3.3 still having ~ 65 open regressions it may be a while before it works good enough. The Debian gcc team should have probably stuck with gcc 3.2.3 as being default. I don't recall it having any major problems, however I recall many for the 3.3 series. And 3.4 will be similiar since it enforces strict ansi rules for c++, besides any other real bugs it will have. > The linux-kernel-headers change was *months* ago, hitting unstable at > the end of October; I think, frankly, that now is long past the time > when it's legitimate to still be worrying about that. No offence > intended, but how long did it take to get kdebase fixed for that change? > A month and a half or so? linux-kernel-headers went into sid on Oct 27. The last set of KDE debs uploaded was Oct 18. The Debian infrastructure was shutdown on Nov 20, although accounts were unlocked on Dec 8 the buildds didn't all come back online until this past week. I know how to fix the syscall breakage but linux-kernel-headers has other RC bugs as well see #223846. Chris
Attachment:
signature.asc
Description: Digital signature