On Sunday, 2013-08-04, James Tyrer wrote: > However, not to go over the same thing again, but I do have this > puzzling error message: > > rekonq(13587)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned > initialize() D-Bus call failed: "The name org.kde.kded was not provided > by any .service files" > > clearly indicating a missing: "org.kde.kded.services" file.
No, this is a misleading false positive. The problem is a call to an unregistered name, resulting in a fallback like situation. > Since you understand D-Bus better than I do, perhaps you can explain > what you think happened that resulted in the above error message. From > your previous explanation, it is my understanding that some KDE code > used D-Bus to send a message to Kded which D-Bus didn't find so it tried > to: initialize() Kded but didn't find the Service file to do so and the > error message was issued. initialize is probably the method that the sender would like to call or it is the method were the D-Bus call originates from. The sender program most likely handles the case of the failed call anyhow, so it just sends the messsage without checking for the presence of the name first. Unfortunately this triggers D-Bus code which attempts activation, something that is neither the intent of the caller nor supported by the receiver. The reported error is the result of some automagic kicking in that is not applicable to the situation at hand. > Has the code base become so large and complex that we really don't > understand how it works in _all_cases_? I emphasize the _all_cases_ > because it is important to consider all possible cases, not just the > normal ones, when designing code. It appears obvious that I (as well as > some other users I found with a Google search) somehow generated a > non-nominal case where the code would not work without this file. To > say that it is non-nominal cases that cause bugs to appear is to merely > restate the obvious. We unfortunately don't have enough information to conclude whether the code works or not. Since there seems to be no obvious error reported for the actual call failure I would lean towards "works". The seen error message is a result of some D-Bus code being overly helpful, not necessarily an indication of an unexpected situation on the side of the actual client code. > Since I can not reproduce the problem, I can only suggest that KDELibs > should install the file based on the established fact that it is > possible for code to call the file in some circumstances and there > appears to be no easy way for a user to fix whatever problem that caused > a call to the file. Adding a second activation path is not something one should do lightly. There could be unwanted side effects, e.g. kded then running in a different environment (being a chilld of D-Bus daemon instead of kdeinit), etc. Assuming you are not seeing any actual error from the application itself I would assume that it handled the call failure as one of the possible consequences of a remote method call. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
