There's no announcement yet, but sources are available for a few days already. http://www.kde.org/announcements/changelogs/changelog3_5_9to3_5_10.php
The official release announcement should come today. I worked over the weekend on it and have to go through bugzilla, tracking and ironing out open issues, this evening, before committing. Were the files on the ftp really available for everyone or is this just your guess from the file date?
My guess. It's been released now: http://kde.org/announcements/announce-3.5.10.php
Open issues https://bugs.kde.org/show_bug.cgi?id=169991 https://bugs.kde.org/show_bug.cgi?id=169954
And another open issue: https://bugs.kde.org/show_bug.cgi?id=170603
I doubt that many users are affected by the issues listed above. Especially flash is known to crash everything using it, even firefox, so I would suggest to send that bugreport to adobe instead of kde. Besides kde 3.5.9 has issues, too. Like kded crashing all the time, blocking apps using kioslaves... So as long as there are no major security issues, please release new versions and mark them 'testing'/'unstable' if you are concerned about quality and stability. It's not the gentoo-way to have someone decide for you whether a pice of software sucks or not. I as a user would like to make that decision that on my own.
I was told to "ping" this bug, mentioning that bug 228839 has not been resolved months after being reported with a patch floating around in the wild. Will that bug be fixed as a dependency of this one, or independently, or what?
I'm getting digest failures on all of the KDE 3.5.10 packages. * Reason: Failed on RMD160 verification
actually, all the sums are bad (not only RMD, but SHA also). so it looks like, there were some changes made to the ebuilds, after the digests were computed.
(In reply to comment #4) > And another open issue: > https://bugs.kde.org/show_bug.cgi?id=170603 There are lots of open bugs, all the time. Not only that this isn't special, but more or lesss irrelevant wrt. KDE 3.5.10. It's pretty unlikely that kde.org will work around these proprietary blob issues in the KDE 3.5 branch. See also bug 234350. (In reply to comment #8) > actually, all the sums are bad (not only RMD, but SHA also). so it looks like, > there were some changes made to the ebuilds, after the digests were computed. See bug 237610.
monolithic kde ebuilds are blocked now (e.g. kde-base/kdebase)? will there be no monolithic ebuilds for 3.5.10?
As stated on https://bugs.gentoo.org/show_bug.cgi?id=237685#c6 there will be no monolithic ebuilds for 3.5.10. Please update to split ebuilds.
So to get 3.5.10 I MUST upgrade to the ebuilds? For what? KDE only provides monobuilds from there FTP. Also the improvements between the mono and the split builds are minimum. This line from the HOWTO: "Most KDE packages aren't changed at all between minor KDE releases. For example, the update from 3.3.1 to 3.3.2 changed fewer than 100 packages out of 320. Split packages allow us to create new ebuilds only for the packages that are actually changed, saving (in this example) more than two-thirds of the compilation time on an upgrade." This is nonsense!!! I've got a KDE 4.1.1 installation (kubuntu) and ALL the packages installed are 4.1.1!! So instead of downloading 15 packages, I've to download 250-300 packages after each minor release. So please think not only for you self, but also for the large community who still is using mono builds and get this fixed. If you guys are so keen on split builds then we will have that discussion with 4.1.1.
(In reply to comment #12) > Also the improvements between the mono and the split builds are minimum. I guess it requires a lot more time to maintain ~230 split ebuilds instead of only a couple of monolithic ebuilds. And it's even more work to maintain both types of ebuilds (... and dependencies, make sure users don't install both/mix them and so on...) From a users point of view, split ebuilds bring you a lot more freedom like fine-grained control over which kde-apps you install and faster reaction to security updates. Also, if one tiny application like kuickshow or kteatime failes to compile you don't end up with a broken kde-desktop because you can still emerge the important parts of kde separately. The only drawback I can image is a slight increase in installation-time due to the overhead caused by configure. But with Qt4/KDE4 that won't be any issue any longer. Imho, the kde-team took the right descision going for the spit ebuilds.
And you can use kde-meta that "emulate" the monolithic build.
Now that 3.5.10 was put in the tree almost 1 month ago, I'm closing this. Any issues regarding 3.5.10 can be reported on a new bug.
