Bug#538144: I'm sorry KDE maintainers are not responsible people.
I am sorry that the KDE maintainers are incapable of forwarding bugs upstream. One would assume that they, unlike me, have accounts on KDE's Bugzilla. GNOME has its problems, but its maintainers are actually making some effort to maintain it, so I guess I'll switch to it. Bye-bye now. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538144: Option Open folders in new windows is BROKEN, rendering konqueror unsuitable for purpose
Package: konqueror Version: 4:4.2.4-1 Severity: important Under Settings/Configure Konqueror..., under File Management, there is an option called Open folders in separate windows. I have had this option on since day one. It is absolutely essential -- I cannot comfortably browse files without it. It just broke. Now folders open in the same window despite the option being set. What's worse, dolphin doesn't even have this option. Although someone lied to me about that -- see bug 532883. Please fix this promptly. I will have to switch to another desktop environment if this is not fixed very, very soon. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (499, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages konqueror depends on: ii kdebase-bin4:4.2.4-1 core binaries for the KDE 4 base m ii kdebase-data 4:4.2.4-1 shared data files for the KDE 4 ba ii kdebase-runtime4:4.2.4-2 runtime components from the offici ii kdelibs5 4:4.2.4-1 core libraries for all KDE 4 appli ii libc6 2.9-12GNU C Library: Shared libraries ii libkonq5 4:4.2.4-1 core libraries for Konqueror ii libkonqsidebarplugin4 4:4.2.4-1 Konqueror sidebar plugin library ii libqt4-dbus4.5.1-2 Qt 4 D-Bus module ii libqt4-qt3support 4.5.1-2 Qt 3 compatibility library for Qt ii libqt4-xml 4.5.1-2 Qt 4 XML module ii libqtcore4 4.5.1-2 Qt 4 core module ii libqtgui4 4.5.1-2 Qt 4 GUI module ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3 ii libx11-6 2:1.2.1-1 X11 client-side library ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime Versions of packages konqueror recommends: ii dolphin 4:4.2.4-1 file manager for KDE 4 ii konqueror-nsplugins 4:4.2.4-1 Netscape plugin support for Konque Versions of packages konqueror suggests: pn konq-plugins none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532883: dolphin does NOT have an open folders in new windows option
(OK, bug unarchived, now the message should get through...) Just installed KDE 4.2.4. NO, dolphin does NOT have an option to open every folder in a new window automatically when you double-click. (Macintosh c. 1984 style.) The equivalent of Konqueror's Open folders in separate windows option. I went through every single option under Settings. This makes dolphin UNUSABLE as a file browser for me. And I don't appreciate being lied to about features, either, like the people who claimed that dolphin already has this feature did. ...But what is MUCH MUCH WORSE, Konqueror's Open folders in separate windows option just BROKE with KDE 4.2.4. I reported this as a separate bug, though I suspect it may be related. This means KDE has *NO USABLE FILE MANAGER*. I will have to switch to another desktop environment if this is not fixed very very soon. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532883: dolphin: seriously needs 'open folders in new windows' option
Package: dolphin Version: 4:4.2.2-1 Severity: wishlist This is a wishlist. I found dolphin completely unusable because of only one missing option. I prefer to do my file browsing old MacOS-style, one window per folder, where opening a folder opens a new window. Konqueror has an configuration option which allows it to work this way. Dolphin doesn't, making it completely nonfunctional as a file browser for me. I'm just glad Konqueror is still present; but with rumours that Dolphin is the wave of the future, I hope this gross oversight, which should be pretty trivial to fix, might get fixed. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (499, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dolphin depends on: ii kdebase-runtime 4:4.2.2-1 runtime components from the offici ii kdelibs5 4:4.2.2-2 core libraries for all KDE 4 appli ii libc6 2.9-12 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-5 GCC support library ii libkonq5 4:4.2.2-1 core libraries for Konqueror ii libqt4-dbus 4.5.1-2Qt 4 D-Bus module ii libqtcore44.5.1-2Qt 4 core module ii libqtgui4 4.5.1-2Qt 4 GUI module ii libsoprano4 2.2.2+dfsg.1-1 libraries for the Soprano RDF fram ii libstdc++64.4.0-5The GNU Standard C++ Library v3 ii libx11-6 2:1.2.1-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxrender1 1:0.9.4-2 X Rendering Extension client libra Versions of packages dolphin recommends: ii kfind 4:4.2.2-1 file search utility for KDE 4 dolphin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#366171: kscd: Won't release CD drive
Package: kscd Version: 4:3.5.1-1 Severity: important This is a recurring and infuriating problem -- or actually, family of problems. I'm not sure if they're related, so I'm filing bugs for each one. Here's a reproduction recipe. (1) Insert an audio CD. Open it in kscd. Stop it. (2) Attempt to mount it (mount /dev/hdc) This fails. (3) Attempt to eject it. Either with kscd, or with the button on the tray, or with the 'eject' command. Failure. lsof will identify the program holding the device open, which is kscd. Killing kscd, or quitting it, will release the CD drive. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kscd depends on: ii kdelibs4c2a 4:3.5.2-2+b1 core libraries for all KDE applica ii libartsc0 1.5.2-1 aRts sound system C support librar ii libasound2 1.0.10-2 ALSA library ii libc6 2.3.6-7 GNU C Library: Shared libraries ii libgcc1 1:4.1.0-1+b1 GCC support library ii libglib2.0-02.10.2-1 The GLib library of C routines ii libkcddb1 4:3.5.1-1CDDB library for KDE ii libqt3-mt 3:3.3.6-1Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.0-1+b1 The GNU Standard C++ Library v3 kscd recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341666: arts: FTBFS on hppa
Package: arts Version: 1.4.2-5 Severity: important Justification: fails to build from source From the log at http://buildd.debian.org/fetch.php?pkg=artsver=1.4.3-3arch=hppastamp=1133415424file=logas=raw we see: checking for Qt... configure: error: Qt (= Qt 3.3 and 4.0) (library qt-mt) not found. Please check your installation! Yeech! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340704: unrar-nonfree exists
FYI, there is in fact an 'unrar' package in non-free for unstable, testing, and stable (source package unrar-nonfree). It is separate from 'rar' because the rar package is even less free than the unrar package. So ark should certainly Suggests: unrar, whether or not it Suggests: rar. I think unrar will be a better choice for most people. -- Nathanael Nerode [EMAIL PROTECTED] (Instead, we front-load the flamewars and grudges in the interest of efficiency.) --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335285: kicker: uninstallable on ia64
Package: kicker Version: 4:3.4.2-3.0.1 Severity: serious On ia64, kicker has a binNMU, with an unsatisfiable exact same-version dependency on the architecture: all package kdebase-data. This prevents various packages like amarok from being built, since the buildds can't install stuff. The version dependency needs to be weakened/corrected. I'm not sure what the best way to do that is, since rebuilding all of kdebase on all architectures is kind of annoying. You might ask debian-release whether a sourceful binNMU should be done, or a total upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327948: kdebindings ready to transition
I'm pleased to discover that as of today's kdelibs upload, all of kdebindings's dependencies are transitioned on all arches so it's safe to upload a transitioned kdebindings. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
qt-x11-free on hppa
I notice that qt-x11-free looks in fairly good shape in unstable, except that it's not building on hppa -- with the rather frightening error message: /build/buildd/qt-x11-free-3.3.5/bin/uic -L /build/buildd/qt-x11-free-3.3.5/plugins pixmapfunction.ui -o pixmapfunction.h make[4]: *** [pixmapfunction.h] Bus error Anyone know what's going on there? Replies to lists please. -- Nathanael Nerode neroden at gcc.gnu.org Doom! Doom! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kdemultimedia vs. m68k
Looks like gcc-3.4 *and* gcc-4.0 ICE on m68k. Time to restrict the architecture list? :-P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OK to reenable lm-sensors support in ksysguard now
The lm-sensors mess has been solved by Aurelien Jarno. (Hooray!) The new version has been arranged to work with both 2.4 and 2.6 kernels, with no crashes or anything. You can now reenable lm-sensors support if you do it carefully. The source package must build-depend on libsensors-dev (= 2.8.4-1). Then the binary package must be linked against (and depend on) libsensors3. (Yes, I know, another ABI change. This one is supposed to remain stable for a while though!) -- Make sure your vote will count. http://www.verifiedvoting.org/
Re: KDE 3.1.5 Status Update - 20040209
Colin Watson wrote: There's going to be one problem with these two, namely that they both need newer alsa-lib which needs newer jack-audio-connection-kit than what's in testing, and some things still need to be rebuilt for that. Having anticipated that, I worked out an extensive list of the issues currently holding up jack-audio-connection-kit and sent it to -release. :-) I figured, worry about that first, *then* look at the KDE packages with remaining problems. The good news is that gst-plugins is the only package in the jack dependency web with a known RC bug at the moment. (Spiralsynthmodular was fixed almost as soon as I reported the problem.) I'm inclined to remove some packages from testing to speed the way, but one of the affected packages is gst-plugins and that's a dependency of meta-gnome2, so that can't be so easily swept aside ... Heh -- I guess it's unfortunate that gst-plugins is the one with the known RC bug The other bad news is the nasty state of the buildds, about which I have made a big, loud ruckus. Maybe things will be better when I get back from vacation in a week -- I can dream, can't I? :-)
Re: KDE 3.1.5 Status Update - 20040129
Chris Cheney wrote: And at the current rate that the buildds are retrying KDE 3.1.5 it will be months before it goes into sarge as well. The undeniable fact that other parts of the project are making it harder for sarge to be release-ready is no reason for you to make it harder for sarge to be release-ready. If KDE was actually ready to go into sarge except for buildds (which it isn't), I would happily and loudly nag the buildd maintainers on the grounds that they were the last people holding up an important release goal. I don't feel I can legitimately do that yet. :-(
Bug#227839: kde-extras (main) Recommends ksetisaver (contrib)
Package: kde-extras Version: 4:3.1.2 Severity: serious Tags: patch Justification: Policy 2.2.1 Change the Recommends to a Suggests in order to comply with policy.
Re: KDE 3.1.5 Status Update - 20040114
Chris Cheney wrote: There are currently two known bugs that will block KDE 3.1.5 from going into sarge #226727 and #226738. It seems the GCC people don't think their bug is important enough to fix... More, that it wasn't diagnosed enough to fix in a reasonable amount of time. :-( But kdelibs seems to have built on mips now, according to Riku Voipio. (http://lists.debian.org/debian-qt-kde/2004/debian-qt-kde-200401/ msg00344.html)Who knows what was going on with GCC. :-( So much for #226727. As for #226738, it looks like it will be fixed soon by a rebuild. Don't forget the lm-sensors dependency in kdebase. That will keep kde 3.1.5 out of testing until lm-sensors is fixed, unless it's manually forced in. I'm really not sure what to do about that, but I've discussed the lm-sensors issues on debian-devel.
Re: KDE 3.1.5 Status Update -- 20040113
Chris Cheney wrote: kdelibs --- m68k- failed - needs retry (waiting on qt-x11-free) mips- failed - ICE #226727 Please try to find a workaround for this ICE (or help find fix it). The GCC developers haven't tracked it down yet, which means it may well not be fixed by sarge release time. (Unless of course it's already fixed, which can be tested by trying a newer gcc-3.3 package). It's also not top priority for GCC since gcc-3.3 is still producing silently wrong code in some situations (which comes first, of course). Possible workarounds include compiling with less optimization. Finding it, since it's a segfault, probably means running gdb on the cc1plus process. :-P
Re: KDE 3.1.4 Status Update - 20040106
kdeutils mips- failed - needs the SYS_sysinfo fix [1] ... [1] - Was broken after supposed toolchain freeze by f*cking wonderful toolchain changes. Yeah, that one sucks a lot; I've noted some other packages it bites in the appropriate bug trail. That one showed up in a supposed bug-fix-only release of glibc, which is especially galling. glibc has been the most troublesome package for a very long time now. I've been meaning to try to work on that bug myself,and not having a MIPS, it seemed it might not be the best use of my time, so I've been fighting with (upstream) GCC 3.4 configury issues instead. [0] - The failure above seem to be caused by: mpeglib/lib/input/cdromAccess_Linux.cpp:13 typedef unsigned long long __u64; Anyone happen to know if its safe to remove that or some other easy way to work around it? The 'conflicting' definition is typedef long unsigned int __u64 from /usr/ include/asm/types.h (included via linux/cdrom.h). Obviously __u64 is meant to be an unsigned 64-bit integer in both cases. It looks like the 'other' (asm/types.h) definition is included in the same way from the same place on all arches. If this is in fact the case, then it should be safe to remove the cdromAccess_Linux.cpp definition.
Re: KDE 3.1.4 Status Update - 20040106
kdegraphics --- mips- failed - this one is odd I believe that this is a bug with XFree86 vs. FreeType2 which was fixed very recently. So it just needs to be retried. :-/
Re: Re: kdebase, kdemultimedia ETAs?
http://bugs.debian.org/release-critical/ http://buildd.debian.org/stats/ 553 RC bugs are still open combined with the fact that the s390 buildd still isn't online and how far behind the other buildds are, leads me to believe sarge won't be releasing anytime soon. It certainly looks like it will be longer than a month from release. Stuff's getting built for s390; since s390 is a *very* fast architecture, it will catch up quickly. Look at the bugs which are applicable to packages in sarge (an awful lot of packages are getting removed from sarge): http://bts.turmzimmer.net/list.html That's 303. Of those, a large number are: * already patched * glibc or linux-kernel-headers issues (doing well, as I mentioned) * latex2html moved to non-free (straightfoward to fix) * unmaintained packages which are probably going to be dropped * long-standing X-Windows issues which are probably going to be ignored Sarge is closer than you might think. :-/ kde 3.1.5 releases next week and KDE 3.2 RC1 the week after that. I currently think it might be a good idea to just upload 3.2 to sid and get it into sarge. Unless anyone knows of some serious issues with 3.2? Don't do it. :-( That's a *very* bad idea. If it takes even half as long to get 3.2 into sid in good shape as it has taken to get 3.1.4 in, you'll NEVER make sarge, no matter when sarge releases. Please, please don't do it. If you want to upload KDE 3.2 to experimental and see how it goes. But DON'T upload it to sid until you have 3.1.4 in sarge and working. Parts of KDE are still at version 2 in sarge, and uploading KDE 3.2 to sid will just make it impossible to ever get KDE 3 into sarge.
kdebase, kdemultimedia ETAs?
Believe it or not, sarge is getting close. debian-installer is going into Beta 2 in close-to-ready shape for i386. I'm guessing beta 3 will be the final version. Glibc is finally getting on top of its bugs. The various transitions have mostly made it into testing, with the jack transition likely to go in in the next week. And we still don't have kdemultimedia 3.1.4; and kdm still needs its collection of fixes. I'm beginning to worry that they will miss the sarge release. Do we have estimated times of arrival for these? Should I work on kdemultimedia 3.1.4, or is someone actually working on it already? Replies to the list please. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
kdemultimedia 3.1.4?
This appears to be the last core KDE package *not* to be at version 3.1.4 in unstable. (While it won't go into testing until the jack-audio-connection-kit dependency chain is unclogged, that will probably be unclogged in the next couple of weeks.) Is someone interested in making the upload? Chris, do you already have a half-done package for this (in which case I guess we should wait for you), or not (in which case I guess anyone on the maintenance team can build and upload)? Whoever uploads it, remember not to lose the fixes from the four NMUs.
Re: Processing of kdebase_3.1.4-1_i386.changes
kdebase_3.1.4-1_i386.changes uploaded successfully to localhost along with the files: snip Hooray! Good work, Chris! :-) (I criticize often enough, so I try to give praise where praise is due as well.)
So what's kdebase waiting for now?
...taps fingers ASAP as of two days ago. Any chance this will happen this year?!? -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Where's kdebase 3.1.4?
OK. So the buildds are back, the upload queue is working, and the testing scripts are running. Supposedly all the kdebase RC and Important bugs except the kdm install bugs (218731, 222192, I suppose?) were fixed a while ago. Chris, how're those bugs going? One of them has a patch. So we should get kdebase today or tomorrow, then, right? If not, what the hell is going on and how can we help? -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
ETA on kdebase 3.1.4?
Several estimates have come and gone, but could we have a new estimate anyway? ;-)
Please upload fixed kdelibs ASAP?
There are now patches (!) for both bugs. The sooner kdelibs gets fixed, the sooner the whole of kde can get into testing. (The kdebase bug should be downgraded or closed.) (There is also still the kdemultimedia/glibc issue, but that should eventually be resolved without anything but a rebuild on the kde end, though the glibc people have their work cut out for them, of course.) -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Orphaning packages
On Wed, Oct 22, 2003 at 01:10:02PM -0500, Chris Cheney wrote: I have orphaned the following packages for anyone interested in adopting them: arts kdeadmin kdebase kdegraphics kdelibs kdenetwork kdepim kdeutils meta-kde Thanks, Chris Cheney Martin Loschwitz wrote: If nobody objects, I can take over resposibility for these packages and do my best to get them ready for release. I, however, will also try to establish the maintainer group in order to avoid events like the one described above in the future. * Please * do. I believe that the kdelibs upload to fix RC bugs is very high priority. It also should be pretty easy! 1. kdelibs-data requires a Conflicts: k3b (= 0.9-3), arson (= 0.9.7-1) line (see #214534, #214535). 2. Apparently meinproc needs to go into kdelibs-bin in kdelibs4-dev (bug 214815). 3. kdelibs needs to be built. (#216336 is probably bogus, but you'll find out as soon as you build a new version.) That will take care of all the RC bugs. -- After that, kdebase needs a 3.1.4 upload. Bug #214475 should be downgraded or closed, and the other two are woody-only. Once those two are in, it's just a matter of getting all the buildds to do their jobs, and everything except kdemultimedia (glibc bug), kdebindings (unpackaged), and meta-kde (who cares?) should go into 'testing' pretty quickly. Frankly, I wouldn't worry about those at all until the others are ready. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Attempted 'status of meta-kde'
So this is my impression of the current status of KDE 3 for sid/sarge -- tell me if I'm wrong. In the order in which it would need to be done. :-/ The ones with letters can be done in parallel presumably. 0. The arts build failure on ia64 needs to be diagnosed. Hopefully it's nothing serious. 1. qt-x11-free may need to be rebuilt because Xrender moved to /usr/lib. (Does it, or doesn't it?) [madkiss] 2. kdelibs must be rebuilt because Xrender moved to /usr/lib, and kdelibs-data needs some sort of Conflicts or something for the k3b issue (bug 214534). [Chris Cheney] 3. kdebase needs something done about bug 214475 (possibly just downgrading it), and version 3.1.4 needs to be build uploaded. [Chris Cheney] 4a. kdetoys probably needs to be rebuilt because Xrender moved to /usr/lib. [Ben Burton] 4b. kdegames probably needs to be rebuilt because Xrender moved to /usr/lib. [Daniel Schepler] 4c. kdeutils needs version 3.1.4 built uploaded. [Chris Cheney] 4d. kdeadmin needs version 3.1.4 built uploaded. [Chris Cheney] 4e. kdeartwork needs version 3.1.4 built uploaded. [Ben Burton] 4f. kdeedu needs version 3.1.4 built uploaded, hopefully with backported license changes for kstars. [Ben Burton] 4g. kdegraphics needs version 3.1.4 built uploaded (although it will still be caught in a messy libexif dependency chain) [Chris Cheney] 4h. kdepim needs version 3.1.4 built uploaded (although it will still be caught in the pilot-link dependency nightmare) [Chris Cheney] 4i. kdenetwork needs version 3.1.4 built uploaded, and needs something done about the two RC bugs. [Chris Cheney] 4j. kdemultimedia needs version 3.1.4 built uploaded -- after the glibc people fix bug #203303 [Chris Cheney] 5. kdeaddons 3.1.4 needs to be built uploaded after kdegames and kdemultimedia are. [Chris Cheney] 6. meta-kde 3.1.4 needs to be uploaded. So, did I miss anything? -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Status report for qt/mips?
Anyone have a clue what's going on there? It looks like a timeout, but I heard rumors it was a toolchain problem. How soon can this get fixed? -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
KDE status report (again)?
Hate to ask again, but what's currently holding up KDE? I don't know of any Qt/KDE-affecting bugs in gcc or binutils. Is it the remaining glibc bugs? (203303, for instance. Or the hppa breakage.) Is it just that Madkiss hasn't fixed the Qt bugs yet? (And if so, is there an ETA for when they'll be fixed?) Is it an unreported bug? I ask partly because I'm really eager to get KDE 3 into testing, and partly cause I can sometimes do something about gcc bugs. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
KDE 3 in testing status report?
The GCC bug has been fixed in the latest upload, today. XFree86 4.2.1-11 seems to be new enough to handle everything. Bug 203303 is still out there. However, losing kdemultimedia for a while sounds acceptable to me if the rest of it can get in. Though a workaround is better. It looks, unfortunately, as though the current version of QT is a mess (qt-x11-free has 5 RC bugs).I hope that isn't a problem. :-/ So what's the status of KDE 3 for sid and sarge now? And what can we do to force it in, bugs or no bugs? ;-) -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: KDE 3 in testing status report?
Since gcc is finally fixed Madkiss can upload a Qt 3.2.1-5 to fix his remaining RC bugs once gcc has built on all archs. Whee. However: GCC isn't going to build on HPPA because glibc is still screwed on HPPA. Hopefully that won't hold anything up any more than it has to GCC didn't build on arm apparently because doxygen couldn't be installed (which doesn't make any sense)... hopefully that will be resolved very soon though.
Re: KDE 3.1.3 - Sid Status Update
arts ia64* failed - need new gcc 3.3 snapshot (newer than 20030731) New GCC is in. :-) kdebase === arm * failed - needs retry m68k* failed - needs retry mips* failed - needs xfree86 4.2.1-10 (xkbfile_pic) mipsel * failed - needs xfree86 4.2.1-10 (xkbfile_pic) So there's going to be an xfree86 4.2.1-10? ;-) XFree86 4.3.0 is in experimental. Is it anticipated to introduce any new (or old) problems when it hits unstable? (If so, can arrangements be made to delay that until KDE 3 finally gets into testing? I'd hate for KDE to be kept out of testing for yet *another* dependency reason) s390* failed - ISO C issue #203949 I don't know the glibc maintainers' schedules, but they seem to have an evil amount of stuff on their plates at the moment. Fixing the accidental sparc upload problem, making hppa build properly with 2.3.2, fixing this bug, fixing #203303 (the architecture-independent bad headers), and #202969 (the GTK crasher). So where possible, I'm guessing workarounds for glibc bugs (as long as they don't cause future problems) would probably be worthwhile. :-/ Anyway, the status of KDE seems very good! -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: KDE 3.1.3 status
I am currently working on the debs for KDE 3.1.3. This is actually slightly disappointing to me given that 3.1.2 seemed very close to ready to go into testing. (I'm sure you won't lose any of the fixes applied to it, of course, but a new upstream version usually means new bugs found.) GCC 3.3.x seems to continue to have ICE bugs (already ia64 failed on arts 1.1.3) Are you refering to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11641 perhaps? This appears to be ia64-specific. It works on mainline (3.4). Hopefully someone will regression-hunt it soon. Please make sure to report all GCC bugs which cause KDE builds to fail. But you knew that. :-) so when KDE 3 will go into sarge is anyone's guess. This is the buggiest I can recall GCC ever being. Well, I'll make no great claims for 3.3, except that it's a lot less buggy than 3.0. :-/ 3.4 really should be a great improvement. The new C++ parser helps a lot with C++ stuff, and quite a lot of us have made large infrastructure improvements and code cleanups. Apart from bugs fixed by that process, it's now a lot easier to track down many types of bugs in 3.4 (there's a lot less cruft to look through). Of course, this probably discourages people from looking for bugs in 3.3. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: KDE 3.1.3 Status
GCC 3.3.x seems to continue to have ICE bugs (already ia64 failed on arts 1.1.3) This is GCC PR target/11641, which I'm pretty sure is a dupe of PR target/10681, which was *just* fixed on gcc 3.3 branch. If I'm correct, you should ask the Debian GCC maintainers to update their version of GCC 3.3 (again). Can't ask for much faster reponse in GCC than that, really
KDE status for progression into testing...
I was poking around looking for the current holdups for getting KDE into sarge. There's openldap2, of course, but the OpenLDAP maintainers are preparing a new release of OpenLDAP fixing all the RC bugs as we speak, and it will probably be in unstable in the next couple of days, and testing 10 days after that. A nice goal would be to have most of kde go in at approximately the same time... kdelibs has * one sarge-only bug * one unreproducible bug -- hopefully this won't affect progression into testing * one other serious bug, which is actually two issues: kdelibs4-dev (meinproc) needs to depend on libxml2-utils -- this should hopefully be fixed with the next upload of kdelibs (maybe someone should upload...) meinproc fails mysteriously on m68k -- I hope the whole of KDE is not held up for this, even if it would be an architecture breakage. Anyway, it seems to be the last open 'real' bug, so fixing it would be a very good thing to do. Unfortunately, that can only be done by m68k people. kdebase has: * a dependency bug: ksysguard needs to depend on libsensors-1debian rather than libsensors1 -- will hopefully be fixed with the next upload (maybe someone should upload...) * a FTBFS with a patch which fixes it -- should hopefully be fixed in the next upload (maybe someone should upload...) * a wontfix upstream bug -- hopefully this won't affect progression into testing * three woody-only bugs kdegraphics has one RC bug * another obsolete dependency (imlib2 instead of libimlib2) -- will presumably be fixed with the next upload (maybe someone should upload...) Of the remaining packages depended on by meta-kde, none have RC bugs, and it doesn't look like there are any serious dependency problems. (kdepim is waiting (indirectly) for gdbm, which sounds bad. But apparently (http://lists.debian.org/debian-release/2003/debian-release-200306/msg00026.html) most of the 'breakage' for gdbm is spurious, and simply means that gdbm and gdbm173 must be pushed in together. It needs a new apache2, but that's only waiting for openldap2.) There's a fair number of packages which are out-of-date on various architectures, but there's probably no point worrying about that until the known bugs above are fixed. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
KDE 3 in sarge ? ? ?
Any clue on when kde3 might make it into sarge? It looks like it's being held up by cupsys (bugs) and openldap2 (lotsa bugs). I don't even understand what those packages do, or I'd help fix them. :-( --Nathanael
