No talking here please. Open new bugs for new issues. Also see bug 313999.
Created attachment 234259 [details] package.keywords - dependencies
Created attachment 234263 [details] package.keywords - dependencies
Created attachment 234265 [details] package.keywords - KDE SC 4.4.4
Created attachment 234267 [details] package.keywords - dependencies
Created attachment 236177 [details] package.keywords - KDE SC 4.4.4 Removed kappfinder, updated package list (a few -r1)
Created attachment 236179 [details] package.keywords KDE SC 4.4.4 Remove mistakenly added scp-kde and printer applet
Created attachment 236355 [details] package.keywords-KDE SC 4.4.4 Update list
Created attachment 236357 [details] package.keywords-deps Update list
Please proceed.
and why shouldn't we wait the usual 30 days here?
(In reply to comment #10) > and why shouldn't we wait the usual 30 days here? > How about bug 323943 for a reason? Unresolvable blockers in stable. :-)
amd64 stable
(In reply to comment #10) > and why shouldn't we wait the usual 30 days here? > It took us quite time to stabilise that list and ensure that it all works at least a bit together :P 7 days here or there wont change the thing. Also i would like archies to consider if they want the stable or not. I myself consider kde tested and stable only on arm/amd64/x86, because upstream really don't test it on anything else. (currently amd64, x86 and ppc have stables)
And one more thing, if the list of stables differ against what amd64 stabilised rather pick those that were stabled on amd64. Not sure now if the list is updated to it or not.
(In reply to comment #11) > (In reply to comment #10) > > and why shouldn't we wait the usual 30 days here? > > > > How about bug 323943 for a reason? Unresolvable blockers in stable. :-) We will give it some days nonetheless to ripe on x86.
Also as a reason why fast-stable it not respecting 30 day period - it results from the way we create KDE ebuild. We bump them directly from stable SVN branch equvalents (4.4.9999 in kde overlay) and many of us test and use those live releases on daily basis. That being said 4.4.4 was in fact introduced the moment it was tagged in upstream SVN. package list is updated and you should stick to it - especially two packages are missing there: printer-applet and system-config-printer-kde - they (nor their dependencies) are not meant to be stabilized (someone unnecessarily stabilized hal-cups-utils and system-config-printer-common last time - it was not intended)
(In reply to comment #16) > Also as a reason why fast-stable it not respecting 30 day period - it results > from the way we create KDE ebuild. We bump them directly from stable SVN branch > equvalents (4.4.9999 in kde overlay) and many of us test and use those live > releases on daily basis. That being said 4.4.4 was in fact introduced the > moment it was tagged in upstream SVN. Fine, but I have some issues with the newer Hal, which I need to sort out and check if they can stop stabilisation. KDE is a big thing and I want it done properly apart from all your thorough testing...we will do it soon (TM). Compile test succeeded on x86, commits will take some hours, maybe I will come to it on the weekend.
Why stable kdeadmin-meta-4.4.4 before knetworkconf-4.4.4 (among others)? That requires users to keyword some or all of the required packages within the meta package. Why not stable the contents first?
Hi, Is there no possibility to update a lot of ebuilds in one commit? I performed sync about 4 hours ago, and now cannot upgrade whole system, because part of kde packages are can be upgraded, but not the kdelibs. And as I see from packages.gentoo.org, the update is still not finished yet.
(In reply to comment #18) > Why stable kdeadmin-meta-4.4.4 before knetworkconf-4.4.4 (among others)? That > requires users to keyword some or all of the required packages within the meta > package. Why not stable the contents first? Because I just work off the list as it was presented here. Maintaining the dep tree for a thing like KDE in between is near to impossible. Initially I requested a rsync block for the stabilisation time, but infra and I could not meet on common ground. Additionally the script which did the stabilisation hung itself because of a network problem while I was out of house. Sorry for the inconvenience, will be over soon, I hope. Yes, faster commits are possible, but I hoped I could do it without glitches in a row.
x86 stable, finally.
For strigi, please see bug 330357
Created attachment 240757 [details] list of kde-base/ packages with versions to stabilise >30 days passed. Moving to 4.4.5... For all the archies i would really like to know if you really want to have stable kde. We can gladly settle on having stable on x86 and amd64 if you really lack the powers to do this...
CCing back amd64 and x86 to recycle this bug rather than opening new stablereq. As per previous comment. @ppc team: guys we seriously need you to do this stable or drop stable support for your arch. 4.3 is now really deprecated and becaming broken in stable more than i would like.
amd64 done
*** Bug 330443 has been marked as a duplicate of this bug. ***
This bug is now blocking OpenSSL 1.x stabilization in near future because of fixes in kde-base/kopete and net-libs/libmsn (bug 330437 and bug 330443) Naturally only ppc and x86 are affected because of their stable keywords on 4.3.5/4.4.4 which are broken
Considering no feedback from archs and our plans to drop KDE SC 4.3.5 from tree, here it goes: A friendly announcement/reminder for ppc@, ppc64@ and sparc@: - from now on, ppc, ppc64 and sparc will not receive STABLEREQ for KDE SC releases nor any other KDE4 ebuilds. ~ppc, ~ppc64, ~sparc keywords will remain. - removal of KDE SC 4.3.5 from tree will result in dropping all said architectures from stable to testing from all KDE4 packages. A friendly announcement/reminder reminder for alpha@ and ia64@: - as alpha and ia64 keywords are already dropped from KDE SC 4.4.x, removal of KDE SC 4.3.5 from tree will result in dropping all said architectures from all KDE4 packages.
Why are these test failures being added to depends list? They don't block this bug. All tests are skipped by default (they only run if you have I_KNOW_WHAT_I_AM_DOING defined (kde4-meta.eclass)).
(In reply to comment #29) > Why are these test failures being added to depends list? > They don't block this bug. > All tests are skipped by default (they only run if you have > I_KNOW_WHAT_I_AM_DOING defined (kde4-meta.eclass)). Which is set in the developer profile. If the tests are broken, it's better to restrict them, or at least display why they are running. Anyway, it's a big stabilization so maybe we shouldn't be nitpicking too much.
I made a "Friendly" announcement in the KDE IRC channel yesterday that I'd begin marking kde-4.4.5, some dependencies needed to be met first, so I'm getting to it tonight. I never heard any response. Usually I only respond on the bug after things have been taken care of. Is there a preferred method of communication to ensure that we're still receiving stabilization notices? As for ppc64, I'm currently compiling, with the intention of stabling it in another week or two. I don't currently know if there are still Minimal-TOC issues remaining. Was that ever resolved?
PPC should be done, please re-add us if there are problems.
x86 stable
Removing archies that dont have kde
As i see nobody ever poked arm :/ Probably my bad...
I'm removing ppc64@ because the team has like 200+ open STABLEREQ bugs, including security, base-system/f.d.o (lvm2, udev, cryptsetup, hal, udisks, upower) and with it Gnome 2.30 and co. It's not realistic to stabilize KDE right now with current manpower.
arm will pass, closing