Bugzilla Bug 112842

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.