I think KDE 3.4.3 is ready to go stable now. I don't think there are open problems at the moment that can hold it back, can you think of any? If not, we can start adding arches to CC.
it's been running quite well here on a few machines (x86)
I would agree with you - it is ready for stable on amd64 AFAIK. Running great here on a few systems.
Adding arches to CC to mark KDE 3.4.3 stable. Notes: the release includes - kde-base/kde and its dependencies - kde-base/kde-meta and its dependencies - kde-base/kdesdk, kde-base/kdesdk-meta and deps - kde-base/kdebindings-meta and deps - kde-base/kde-i18n if possible, they should be marked stable at the same time. kdeedu-3.4.3-r10 and kig-3.4.3-r10 have a dep on dev-libs/boost, if it's not available you can mark stable kdeedu-3.4.3 and kig-3.4.3 instead not all split ebuilds were bumped to 3.4.3, clearly if there isn't an ebuild for 3.4.3, 3.4.2 should be marked stable. Thanks!
As a note to arches: The Finnish translation in the current stable version is broken, see bug #94836 for details. The sooner we get this stable, the sooner Finnish users are happy.
I agree here, there seem to be some problems with the IMAP filters support which are resolved in 3.4.3.
sparc done, i think ;)
I used 3.4.3 over month on x86, and is stable work
amd64 marked all stable now...
kde-base/kde-meta, kde-base/kdesdk-meta, kde-base/kde-i18n are stable on ppc64 now. but what is kde-base/kdebindings-meta good for? This one was never marked ~ppc64. I'll add it to the ebuilds when I've tested them, but that's is my problem: What are those ebuilds good for and how to test them?
It's ok to avoid kde-base/kdebindings-meta if it didn't have the ~arch keyword in the first place (personally I cannot say how much testing is reasonable for them, programming something in each of those languages goes beyond good sense...). But you may want to mark kde-base/kjsembed (javascript bindings), it is ~ppc64 as it is used as dependency of something else.
kde-base/kdeaccessibility-meta has issues with ksayit (bug #91004, I'm still trying the revdep-rebuild solution to see iff it works). ksttd won't speak text at all, I compiled everything with arts support, arts works, festival is installed, still no go. khotkeys crashes on startup. It appears to be linked to: http://bugs.kde.org/show_bug.cgi?id=108712 This leaves kdeaccessibility fully tested otherwise, and kdebase about 75% tested.
nope, bug #91004 is still a showstopper. It appears to be fixed in 3.5, but the changes involve somewhat unique code changes, nothing I think that's backportable. They use something else instead of macros to get around the whole invalid pointer deal. Mask it maybe? kmouth seems like a better alternative and it works for me.
mhh... kjsembed is stable on ppc64 now.
(In reply to comment #11) > kde-base/kdeaccessibility-meta has issues with ksayit (bug #91004, I'm still > trying the revdep-rebuild solution to see iff it works). ksttd won't speak text > at all, I compiled everything with arts support, arts works, festival is > installed, still no go. khotkeys crashes on startup. It appears to be linked > to: > So are these new problems that have been introduced since 3.4.1? I am not seeing anything in that bug preventing going stable. The comments so far indicate the problem would be in gcc/glibc. Please comment on the bug if have more accurate information.
ksayit-3.4.3 works fine here, bug #91004 definitely looks like a local problem, anyone can confirm?
Bug #91004 seems to be fixed?
Ok, pretty much all of my previous issues are resolved, except for kimagemapeditor, which has some interesting bugs: http://bugs.kde.org/show_bug.cgi?id=93351 which also has a patch and http://bugs.kde.org/show_bug.cgi?id=60978 which I'm still waiting on. This I need to mark the webdev stuff. Also, kcron needs to depend on virtual/cron for crontab, otherwise it plain doesn't meet its purpose. I need this to mark kdeadmin. I'm going to have a talk with compnerd because the java tests that come with kdebindings aren't quite working because of class import errors. I don't use java so I have no clue how to handle it :P. Everything else is ok, and there were a couple of packages that I simple couldn't test because either a) I had no clue how to or b) I didn't have the hardware/setup to test it. For b) I simply made sure the package at least ran and the properties seemed somewhat sane.
Added dependency on virtual/cron. For some problems, like the kimagemapeditor ones, I guess we just have to live with them (consider that KDE has more than 10.000 open bugs, and a few applications are definitely not in good shape, kimagemapeditor is one of them). Thanks a lot for taking the burden on yourself to test all of KDE, it is really appreciated!
There was an issue with ksayit and our glibc, thanks to a patch supplied by Chris White that is now resolved. Could all archs please make sure they stabilise the versions below with the patch included. ksayit-3.4.3-r1 kdeaccessibility-3.4.3-r1 Adding archs that have already stabled back in to stabilise these two packages.
Do you know what versions of glibc are affected? SPARC is quite behind the curve here, using sys-libs/glibc-2.3.3.20040420-r2.
ksayit-3.4.3-r1 stable on ppc64
hi guys from x86-team, sorry to ask this question, but are there any plans to mark 3.4.3 stable soon? I'm asking this because I want to upgrade gcc on my system with revdep-rebuild -X --library libstdc++.so.5 -- -v It would be nice if 3.4.3 is build with the same action or else I need to wait a long time for a compile twice in a short period. If nothing is planned or it's already known that stabilization will take a fair amount of time, please let us know so we don't have to wait with the gcc-upgrade. Thanks!
I have the same question: is there any estimation for x86? Thanks
Some time between now and March of 2006... remember that "KDE" is now a huge collection of packages to test. It isn't something that can even be done overnight. Asking when it will be done over and over again isn't productive for anyone.
ppc should be complete now, please re-add us if I missed something.
x86 is now done save kdebindings, which have issues with the java bindings, and I think Diego mentioned something about ruby bindings being odd too.
Ruby bindings are now fixed, Caleb patched them :) They still miss one function, but that would remain till 3.5.1 anyway.
Stable on alpha.
Chris, can you mark kdeutils-3.4.3-r1/klaptopdaemon-3.4.3-r1 stable on x86 to stay in line with other arches? Thanks!
On x86 kjsembed-3.4.3 is still marked ~x86 which causes an upgrade/downgrade circle if koffice is installed. (kjsembed-3.4.1 depends on =kwin-3.4.1) kjsembed installed fine after putting =kde-base/kjsembed-3.4.3 ~x86 into /etc/portage/package.keywords. But without you either cannot install koffice (cleanly) or you get above mentioned problem.
Chris, can you mark kde-base/kdebindings-meta-3.4.3 stable on x86? It seems to me that its dependencies are all stable now. Thanks!
sparc done.
Hmm.. I did about 2 days ago.
http://packages.gentoo.org/search/?sstring=kdebindings
This was done some time ago.
closing, as 3.5.2 is now already stable as well.