OK- the new patch worked for kdelibs, and my usual kde-live package list went OK, now at 4.5.75 (4.6 >= 20101105), except for three packages. (Finally realized I had to unmask upower-0.9.6, otherwise 0.9.5 wanted to downgrade polkit, and was causing a kdelibs confict).

I have had this problem in the past too. Have you guys tried recompiling? Usually when this happens to me with KDE, the cause is either a bad ebuild or a bug in portage. In the case of portage, compiling it again and then filing a bug report for zmedico describing the issue in as much detail as possible usually works. In the case of a bad ebuild, fixing it and then filing a bug report with information on how you fixed it usually works for me.

Thanks ComaWhite,
USE="-python" emerge marble worked fine. I'm wondering what Marble is losing by disabling python, or more specifically, what features are added or enhanced by having python support?

Shining Arcanine,
I did look on gentoo and kde bugzilla, but found no references to these errors. Seeing as how this is from the kde overlay, I'm unsure if these bugzillas are the correct places to file kde-live bugs. Did I just miss something in the overlay Documentation saying where to report problems other than this forum thread?_________________Main box- Gigabyte GIGABYTE GA-990FXA-UD3 AM3+ rev.-4.0
Amd FX 8320, 3.5 GHz, 16GB GSkill DDR3 1866mhz
Samsung SATA 1000GB, Radeon HD 6570 2GB DDR3
Gentoo ~x86, ~amd64, glibc-2.20-r1, gcc-4.9.2 kernel-3.19.0-gentoo (USE=experimental "native")

Thanks ComaWhite,
USE="-python" emerge marble worked fine. I'm wondering what Marble is losing by disabling python, or more specifically, what features are added or enhanced by having python support?

Shining Arcanine,
I did look on gentoo and kde bugzilla, but found no references to these errors. Seeing as how this is from the kde overlay, I'm unsure if these bugzillas are the correct places to file kde-live bugs. Did I just miss something in the overlay Documentation saying where to report problems other than this forum thread?

Gentoo's developers do not patrol the forums for reports regarding issues. The best way to notify them is to file a bug report at bugs.gentoo.org. Be sure to specify in the title that it is regarding the kde overlay and they will be happy to have your report.

EDIT: This crash now appears randomly when closing dolphin. Sometimes it closes normally, and i can't tie it to any specific action as of yet. Same thing happens with a completely new user and new ~/.kde4 directory.

Things generally seem more sluggish, but dolphin is the most serious example so far. Kde version 4.5.73 wasn't like this.
EDIT2: More info. When I open dolphin as user from CLI, it still takes 10 seconds, but gives no info output at all. When i close it, it gives this output:

I tried looking around, both in the plasma-workspace sources and in the various cmake modules installed by kdelibs, to find instances of kholidays, but changing what I found to point to the actual path of the file didn't change anything. It seems as if in some cmake file they forgot to enclose KDEPIMLibs__kholidays in braces, so that the makefile contains the name of the variable rather than the value it contains. Unfortunately, I have no idea of where to look for something like that.

@Stefano Crocco,
Yeah- I have the same error in my post above at 16%, except mine is an amd64 box.

I too looked around like you did, and tried commenting out the analog clock applet in a CMakeList.txt file, but it didn't help. As you tried a PATH adjustment and that too didn't help, I think you're right and it's got something to do with KDEPIMLibs__kholidays.

I don't really know much (if any) c++, so I'm pretty much limited in hacking on this stuff to editing in what somebody else has figured out . Strangely, my kde-live install seems to function OK even without updating plasma-workspace- guess it's still using the previous 9999 version. I still have the slow 10+ second Dolphin opening problem.

Stefano and wrc1944, I ran into the same problem and you'll be pleased to hear I've fixed it! I'm not sure it's the "correct" solution, but it works... After a lot of trial and error I worked out that plasma-workspace needs libplasmaclock to be built at the same time. And thanks to our wonderful ebuilds that's very easy to achieve: I removed the libplasmaclock references from the COMMONDEPEND and KMLOADLIBS sections of the plasma-workspace ebuild, and added the plasmaclock directory to the KMEXTRA section.

Code:

KMEXTRA="
statusnotifierwatcher/
libs/plasmaclock/
"

I then unmerged liblpasmaclock (and removed it from kdebase-meta and whichever set it was in) and emerged plasma-workspace. Happy days.

laughinggnome,
Thanks for posting.
Next time I'll check to see if it's fixed in either svn or the overlay, but if not I'll definitely give this a try.

Seems like it's probably an overlay problem, but if we edit the overlay ebuild I guess it will be over-written on the next sync. In fact, IIRC editing an overlay ebuild causes the layman -s kde command not to work.

However, I don't think I want to get into putting kde-live stuff in another "local" overlay.

For such cases I've always got my bugfix overlay ready. Someone should report this btw via bugzilla [kde] _________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

USE="-python" emerge marble worked fine. I'm wondering what Marble is losing by disabling python, or more specifically, what features are added or enhanced by having python support?

The python bindings are needed to use the Marble widget (~ the Marble library) from python programs. In examples/python there's a sample python program where you can see that in action.

The python bindings are synced around the beta / release candidates with the Marble API. Before that, compilation errors are to be expected. Simon Edwards (the maintainer of the bindings) recently synced them, so chances are good Marble compiles fine now.

From a user's point of view, the python bindings are very likely not needed since they do not affect the Marble application in any way. Therefore I'd recommend to compile Marble with a deactivated python use flag unless you plan to write or execute python programs embedding a Marble widget._________________KDE 4.14 - Get It While It's Hot!

No, simply the repo currently broken at that package. Either re-sync and see if it's been solved (could have been you syncing in the middle of an update before or indeed overlooked by the overlay guys), or do the following:

Ah, I've seen it now. It's nothing unusual that kde beta ebuilds arrive in kde overlay days before actual source tarball availability._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Does anyone know what's the current status of KMail 2? Is it supposed to be usable? Will it be included in KDE 4.6?

The reason I'm asking is that since I switched from KDE 4.5 to the svn version little more than one week ago, I've spent large amounts of my free time fighting against KMail 2 to have it work like KMail it used to. However, I found out some issues I couldn't solve. Here they are:

KMail has huge trouble in dealing with folders containing thousands of e-mails. Every time I selected one such folder, it took a very long time "syncing" the folder, whatever that means. "Very long time" means something from half a minute for folders with about two thousand e-mails to five or ten minutes for folders with thirty thousands e-mails to some hours for a folder with something like 100,000 messages in it. Besides, while doing so, it eats a large amount of resources, sometimes completely freezing the system.

It treats ignored messages as unread. I'm subscribed to several mailing lists, and it often happens that I see from the beginning that a particular thread doesn't interest me. With KMail 1, in this situation, I marked the whole thread as Ignored and it wouldn't appear anymore either in the list of unread messages or while cycling among unread e-mails using the + key. Now, instead, they still appear in the list of unread messages, and there's no way to make them disappear from there. Even selecting them in the message list marks them as read only temporarily: the next time the foder is synced, they're again marked as unread. At least, they're not taken into account when using the + key to go to the next unread message.

In my attempts to migrate my old mail folders to KMail 2, I tried removing the old KMail configuration so that KMail 2 would start with default settings. I then manually added a resource pointing to the old mail directory, which was correctly imported. Then, I tried moving the old messages from the original folders to the new ones. And here, things become strange: if I tried to move a single message, it worked. As soon as I tried to move more than one message, nothing happened. Sometimes, after waiting for about a hour, the messages were finally moved. The problem is that all the time KMail stated it was "ready".

KMail doesn't always keep up to date with itself. For example, I had a folder containing two messages, both unread. I selected one, read it then deleted it. Yet, KMail still showed two unread messages in that folder
[item] KMail 2 doesn't show the number of unread messages in the system tray icon like KMail 1 did.

I'm not sure whether the issues above are true bugs, known problems which will be resolved before KDE 4.6 is released or are caused by an incorrect configuration. Does anyone has any advice?