Bugzilla Bug 132213

Is it possible to stabilize Kde 3.5.2? I have it working perfectly and some
colleagues use it succesfully too.
If this is not possible could you use this bug as a metabug to help follow up
the bugs necessary for a stable Kde?

We'll stabilize it when ready. If you are asking when, then see the recent
thread on gentoo-dev mailing list.

Reopening to track KDE 3.5.2 stabilization.

If anyone on the KDE team has a bug that blocks this, please add it as a
blocker.  Otherwise, I'd like to request the x86 team to mark KDE stable in a
few days.

I will look at the qt stuff shortly, per Carlo's request on gentoo-dev.

I think this stabilization should be performed by the x86 team, as I've been
requested by the team lead to let them handle stabilizations for packages.

Hope the arch teams will read this, please consider marking stable umbrello
3.5.1-r1 instead of 3.5.2, as that is more stable (although 3.5.2 should work).

This will show my ignorance, but I assume there's a tool/script set for
stabilizing the KDE packages more easily than running repoman by hand?  If so,
can someone point to where it is so the arch teams can use it when it's time.

I've readded the important patches to qt-3.3.6-r1, and added another one that
fixes another bug from qt-copy.  Should be much better now for folks.

add gnupg-stabilization bug

Arch teams, this is a formal request for stablizing KDE 3.5 on your arch. 
There are a few blocker bugs with packages that also need to go stable before
the arch stabilization.  Namely:

#132887 - qt-3.3.6-r1
#132343 - crypto packages
#132349 - printing/pdf packages

The maintainers of each of those packages has given the okay to go ahead with
the stabilization of them as well.

Any chance we could get a list of what needs to go stable?  Leaving it up to us
to guess probably isn't the most effective way.

Thanks a ton... hugs and kisses... the x86 arch team.

Considering that last time we missed some packages, I agree that it would be
good to have a whole list.  I'll be marking for the ppc arch team again, and
would definitely like a list to check against since it's so many packages.

good idea.  stay tuned.

Created an attachment (id=86647) [details]
A list of kde 3.5 ebuilds and their dependants.

I'm not sure how the arch teams plan to attack this, so if you have nice ways
of handling it from previous attempts then please use your best way.  Here's my
proposal in case you find it of value:

* mark qt-3.3.6-r1
* mark packages at bug #132343 bug #132349

(make the following changes, but don't commit to portage yet):

* mark arts and kdelibs
* mark monolithic packages (kdebase, kdeaddons, kdeaccessibility, kdeadmin,
kdeartwork, kdeedu, kdegames, kdegraphics, kdemultimedia, kdenetwork, kdepim,
kdesdk, kdetoys, kdeutils, kdewebdev )

repoman scan for any deps that need to be fixed

* mark split ebuilds and their -metas

repoman scan for any deps that need to be fixed

commit

Actually for the sake of simplicity the arches that are happy could just say
"we're go" and one of the arch commiters do the bunch for said arches and
duplicate work.

(In reply to comment #15)
> Actually for the sake of simplicity the arches that are happy could just say
> "we're go" and one of the arch commiters do the bunch for said arches and
> duplicate work.

alpha is "no go" for now. We just marked kde-3.5.2 ~alpha less than 2 weeks
ago. I'd like to wait until at least 30 days of testing on alpha before marking
it stable on alpha.

To follow up: I'm in no absolute hurry for this to be done - I simply wanted to
get the process started and get people thinking about it.

In bug #132349 you should CC arches :)
With respect to #132343, is it wise to stable a dev-branch gnupg?

(In reply to comment #18)
> In bug #132349 you should CC arches :)
> With respect to #132343, is it wise to stable a dev-branch gnupg?

#GnuPG 1.9 is the current development version of GnuPG.  Despite of
#that, most parts (in particular GPG-AGENT and GPGSM) are considered
#ready for production use. Please keep on using GnuPG 1.4.x for
#OpenPGP; 1.9 and 1.4 may - and actually should - be installed
#simultaneously.

http://lists.gnupg.org/pipermail/gnupg-announce/2005q2/000196.html


Without GnuPG 1.9 and friends there's no s/mime support, there's no cert
handling, so it's simply needed. I (and for sure many others) use it for months
and it works fine.

I appreciate the list of packages, but which versions of each?  Are they all
the same?

Looks like *most* are 3.5.2, but thre's a couple 3.5.0's in there.  Is that
correct?

Created an attachment (id=86669) [details]
files for kde-meta

Here's my list for kde-meta, after having removed the packages that don't
exist.  There's still no dependencies other than KDE components listed.  But
this might help somebody.

A few notes from the monolithic emerge -pv kde side of the house.

- Nothing in this ticket so far indicates akode needs to be stablized
- No packages appear to be depending on the versions of packages specified in
the "Stablizing of gnupg and friends" bug
- Nothing mentioning the stablization of meanwhile-0.4* (only applies to some
arches)

Also why does qt-3.3.6-r1 need to go stable, when kdelibs depend on >=3.3.3 ?

(In reply to comment #21)
> Looks like *most* are 3.5.2, but thre's a couple 3.5.0's in there.  Is that
> correct?

Yes, this needs some clarification as it came to misunderstandings the last
time we asked for stabilization of the split KDE 3.4.x packages. Basic rule is,
if a split ebuilds code did not change from 3.5.x to 3.5.y there's no need for
a version bump, having users to emerge an ebuild for nothing. Rule of thumb is:
Seach kde-base/ for the latest 3.5.X-rN ebuild and mark it stable(*).


(In reply to comment #23)
> - Nothing in this ticket so far indicates akode needs to be stablized

Well, we trust in you to detect that and as long as you use repoman, you will
stumble about it. :) The KDE herd is small, so please excuse that we're not
perfect. -> bug 133151

> - No packages appear to be depending on the versions of packages specified in
> the "Stablizing of gnupg and friends" bug

Have a look at kde-base/certmanager-3.5.2-r1 and its dependencies. KMail needs
(at least) gpg-agent (part of GnuPG 1.9) at runtime. The dependency should be
clarified.

> - Nothing mentioning the stablization of meanwhile-0.4* (only applies to some
> arches)

See above. -> bug 133152

(In reply to comment #24)
> Also why does qt-3.3.6-r1 need to go stable, when kdelibs depend on >=3.3.3 ?

Many, many bugs fixed and we don't want to maintain/support older versions.
Users who don't use the --deep emerge option will automatically update when the
older ebuilds will be removed.



*As a general remark: This stabilization request is for now preliminary, to let
you test, if KDE compiles/works fine on your arch (including all dependencies).
Very few ebuilds may change - e.g. KMail, kdepim will. Please don't mark KDE
stable on your arch immediatly after you are through it. It would be nice to
let it go stable coordinated (at least for the archs with the most users) and
have some GWN announcement in time. Thanks for your efforts.

Hey Carsten,

Sorry if my comment came across rough, wasn't intended that way :)

Also, while certmanager may have proper deps, that's part of modular KDE.  

Monolithic KDE (in particular, kdepim) does not appear to have the right
dependencies for the gpgme version and is lacking dependencies for dirmngr.

(In reply to comment #26)
> Sorry if my comment came across rough, wasn't intended that way :)

It didn't. I just wanted to carify.

> Also, while certmanager may have proper deps, that's part of modular KDE.  
> 
> Monolithic KDE (in particular, kdepim) does not appear to have the right
> dependencies for the gpgme version and is lacking dependencies for dirmngr.

As I wrote, there will be at least one revised kdepim ebuild, including all the
patches and other changes applied to the split packages. If I had done so for
every change, we'd be at kdepim-3.5.2-r10 or so.

bug 131876 might affect 3.4 --> 3.5 upgrades too, but haven't tested myself

RE: Comment #28 I have no clue.  I did a fresh install of KDE 3.5 on my x86
chroot.

So when do you want us to keyword this?  Will it be announced in this week's
GWN?  I've tested it on x86 and it seems to run fine.  Everything I tried
worked.

What is the current status of this bug? Which bugs are still real blockers and
not just dependencies?

Aside from the recent comments in 132343 and the pending kdepim revision, it's
ready in my opinion.  I would vote to mark stable and then when the kdepim
revision is ready, bump it to stable fairly quickly (it's just bugfix patches).
 My reasoning is that the kdepim bug fixes don't hit a majority of users.

Objections, Carlo?

I would support this. The major point of degradation for me is kmail, but that
should not hold up the stabilisation of the whole of KDE where many
improvements have been made. Most of my testing has been on amd64.

Also, if you have a specific time/day you want to say "okay, we're going to go
stable on yyy" then I can do my best to try and be ready to help check that
everything was covered and cover incoming bug reports for anything that was
missed or broke in the transition.

Do you have any schedule for this upgrade? More and more users are requesting
for this package. And it seems ready now??

There is not a schedule, currently.  If someone asks, point them here.  That's
all that you really can do.

as an fyi, I got a note from Stephan @ KDE that 3.5.3 has been packaged and
will be released soon ( a week maybe ).  Note sure how this will affect
stabilizing arches, but I wanted yall to know.

Caleb: So, can we mark the version stable that you guys asked for?

We're in little troubles, qt 3.3.6 marked stable clashes with kde 3.4 that is
not fixed for the stricter uic. Lots of bugs will have to be fixed now :|

(In reply to comment #39)
> We're in little troubles, qt 3.3.6 marked stable clashes with kde 3.4 that is
> not fixed for the stricter uic. Lots of bugs will have to be fixed now :|
> 

Um, so does that mean we should mark 3.5 stable as soon as possible?

Either that or I'll have to fix all the <includehints> stuff that someone
wanted to avoid to fix in the first place and for which masking qt was
preferred.

Hiding bugs is foolish, it will always bite you back.

(In reply to comment #41)
> Either that or I'll have to fix all the <includehints> stuff that someone
> wanted to avoid to fix in the first place and for which masking qt was
> preferred.
> 
> Hiding bugs is foolish, it will always bite you back.
> 

Well, I say we mark 3.5 stable as soon as possible so that we cut down on the
number of users bit by this problem.

yes, by all means.

I will be marking this today, then, for x86.

Please wait for kdelibs3.5.2-r6.

*sigh*

OK.  I didn't *test* with kdelibs-3.5.2-r6, which means it'll take some more
time before I'm going to be able to KEYWORD it.  Please do us a favor, and in
the future, make sure you have your ducks in a row before you come to the arch
teams.  I've wasted a lot of time with this already, as new revisions keep
getting put in and I haven't received an *actual* list of what needs to be
stabilized, just a vague "latest revision".  On a set of packages as large as
KDE< we need absolutely no ambiguity.  A list of exactly which packages,
versions, and revisions should be given for us to work from, especially if you
want us all to be on the same page.

Thanks... =]

I appreciate your frustration and your comments are well heeded, but please
note that I opened and assigned this bug merely to get the arch teams ready and
provide some notice.

The users are clamoring for a stable KDE 3.5.  I'd do the grunt work myself
but: I don't have any way that I know of to generate the list of packages and
the last time I stablized an x86 package myself I got an email from the x86
team lead asking me NOT to do it and to assign it to the arch team.

In my opinion, I'm leaving this up to the arch teams to decide when to
stabilize.  We will most likely be revbumping from here to eternity everything
else.  Might as well bite the bullet sometime and fix what breaks.

(In reply to comment #46)
> *sigh*

No "big" source changes. A few crash fixes (incl. bug 133394) and a closed
memleak. I had this sitting for a couple of days, but my box broke. Otherwise I
had committed it four days ago.

Caleb, thanks for the information.  I'll get on testing with the new kdelibs
and should be marking stable today for x86.

A suggestion for how to keep the list for the future:

When you add the packages, make your list.  It's much easier to keep track of
what you've changed then, as you at least have a list of all of the packages.

I'm going to post here the list that x86 will be using, along with a script for
doing the keywording.

> When you add the packages, make your list.  It's much easier to keep track of
> what you've changed then, as you at least have a list of all of the packages.

I think that's a great idea.  I just wanted to note that I haven't (personally)
done any of the bumps/stabilizations of the KDE meta packages since we went to
that scheme (3.4 timeframe).  So, despite being the "team lead" so to speak,
I'm not familiar with the scripts and such that are used for doing the massive
work.

I do appreciate your effort in helping to get this stabilized.

Created an attachment (id=87507) [details]
kde-meta-files

This is just for kde-meta.  It is fairly simple with cat/pkg version.  The
script below parses this file and does all of the keywording for you.  Nifty,
huh?

Created an attachment (id=87509) [details]
keyword

This is my "keyword" script.  It's pretty simple, as you can tell.  I hacked it
up in just a few minutes, so I'm sure it's just ugly as sin and could use some
work.  It's in CVS, too, under gentoo/users/wolf31o2.

Chris can you please stable umbrello 3.5.1-r1 rather than .2?

x86 should be done for both split (wolf) and meta (tsunam) if there's any
issues let us know.

Thank You, but kde-i18n ist still missing.

kdebindings-meta still needs to be done as well.

Regarding comment #56, in order to mark stable kdebindings-meta, we need also:
#KDE Bindings
kde-base/kjsembed
kde-base/smoke
kde-base/qtruby
kde-base/korundum
kde-base/dcopperl
kde-base/kalyptus
kde-base/qtjava
kde-base/dcoppython
kde-base/kdejava

And, by the way, is dev-util/kdevelop stabilisation traced by this bug?

From KDevelop developpers: "Version 3.3.0 has been released with KDE-3.5.0. 
KDevelop 3.3.x bugfix versions will be  released together with KDE-3.5.x" -
http://www.kdevelop.org/index.html?filename=3.3/kdevelop.html

2 things... #1, I'll be fixing the kdebindings stuff when I get to work in
about an hour.  #2, I'll upload my updated kde-meta-files input file.

Sorry about the problems.  As a non-KDE user, this has been exhausting, having
no real clue of everything that needs to be done.

No worries, Chris.  Even as a KDE user it's still exhausting and hard to
pinpoint everything.  Luckily, I don't see this happening too many more times.

Note that I didn't list kdebindings-meta because they're not grouped into the
kde-meta package, so keywording them separately from the rest of KDE seemed
logical.  I figured it would be slightly less of a burden to have a few
packages to not have to worry about during the stabilization.

the 3.5.* version of kde-i18n isn't marked stable yet, is this on purpose?

*sigh*

Thanks, it was already mentioned in comment #55 so I was getting to it.

Anyway, I've gotten kde-i18n and kdebindings-meta done now, so x86 *should* be
done now.  If you guys find anything missing, add x86 back to this bug and I'll
get on it.

Created an attachment (id=87551) [details]
kde-meta-files

This is the updated version of the kde-meta-files input file for the keyword
script.  It now includes the updated umbrello version, kde-i18n, and all of
kdebindings-meta.  Enjoy.

Created an attachment (id=87556) [details]
kde-meta-files

OK.  Here's the list of KDE minus kdebindings-meta, which I'll attach
separately.

Created an attachment (id=87557) [details]
kdebindings-meta-files

Here's the kdebindings-meta list, then.

This should make it easy for other architectures.

hrm... that keyword script does not check for updates before commiting. :-/

not a good thing.. many of my changes for ppc64 have just been taken back.

It isn't a worse as I thought. seems like only a few packages have been taken
back to ~ppc64. :-)

You'll notice that the script posted doesn't do any committing, so of course it
wouldn't check for updates before a commit.

I ran into quite a few conflicts during my keywording for amd64, but I manually
resolved them, as they were where ppc64 keywords had been adjusted.  Since both
would touch the same line, there's no way that it would have removed your
keywords.  Instead, it would have caused a cvs conflict.  Trust me, I just
resolved about 30 of them by hand.

Which packages were reverted?

I've gotten kde-meta on amd64.  Building and testing kde now.

I don't write those packages down. ;-) but for example
kde-base/kdesdk-kioslaves-3.5.2 got the ppc64 keyword revented.

I do commit with "repoman commit", so dependencies should be fine (if I'm not
doing anything wrong...)

finaly stable on ppc64 :-)

kdsdk-meta-3.5.2 upgrade dependency chain broken for x86 1GB low memory kernel

kde-base/kdesdk-meta-3.5.2
    $(deprange $PV $MAXKDEVER kde-base/kcachegrind)
        DEPEND="x86? ( dev-util/callgrind )"
        bug #110007
        callgrind won't compile, weird version thing?
            DEPEND=">=dev-util/valgrind-3.1
            bug #128684
            valgrind-3.1.1 fails to start: Killed

The attached ebuild with the patch for bug #128684 seems to solve the problem.

There are still some packages I ran from unstable that helped KDE run better:
app-text/aspell: solves using multiple languages for spelling, not really
necessary.
net-wireless/kdebluetooth: the current stable version does not work with KDE
3.5.2, it does not start. This one is more necessary.
I have tested both versions on my system and some other users did so too. 

The kdebluetooth patch for KDE 3.5.2 was introduced with Bug #129237 if anyone
wants to look at it.

Ive also noticed problems with aspell. I cannot select any dictionaries with
KDE 3.5.2 when using the current stable aspell and it defaults to US English.
Using the unstable aspell and aspell-en fixes this and I can correctly select
UK English.

Stable on SPARC.  I did not keyword kdesdk-meta stable yet as I was slow in
adding the testing keywords to it for SPARC.  I'll get it after its 30 day
limit assuming no users harass me about it before then.

Thanks for all of the filenames Chris! :)  I've marked ppc stable, feel free to
re-add us if I've missed anything.

I did monolithic KDE this morning on amd64... let me know if I missed
anything...

KDE team, please advise about comment #71 comment #72 and comment #73 and what
you would like us to do (if anything)

kde-base/kde-meta is finally stable on alpha.

I can't mark kde-base/kde stable due to a broken RDEPEND (repoman won't let me
commit)...

  RDEPEND.bad                    1
   kde-base/kde/kde-3.3.2.ebuild: mips(default-linux/mips/2006.0)
['~kde-base/kdeedu-3.3.2']

Once that's resolved I'll mark kde-base/kde stable on alpha.

Interesting that repoman complained for no one in the nine months in between...
Excluded kdeedu 3.3.2 on mips.

alpha done.

3.5.2 stable for some times already on hppa.

arm/s390 does not have KDE at all so no point in having us here

closing as we have a 3.5.5 bug now.

Errrr, the other arches, maybe.

methinks mips is cool. removing.

Marking as fixed - 3.5.2 is not in the tree any more and it is stable on all
archs. mips still needs to take care of qt but there is another bug open for
that and assigned to them anyway.