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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 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 attachment 87556 [details] kde-meta-files OK. Here's the list of KDE minus kdebindings-meta, which I'll attach separately.
Created attachment 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.
