Thanks for a bug report. The cryptic error "The name is not activatable" is returned by glib2's GDBus and I agree it's not much helpful. This usually happens when a D-Bus service disappears unexpectedly. As some services are created as needed, without a well-known name, the D-Bus cannot start them automatically, which the error is basically about.

Did you restart the machine meanwhile? If not, try:

   $ evolution --force-shutdown

which will restart Evolution and all its background processes, thus it will also re-connect to the D-Bus services. I would guess something failed to (re-)connect to the libsecret service, which can work on the client side (in Evolution), but not necessarily on the background side, like in the evolution-source-registry process.

Ok, I've just restarted evolution and it started working (didn't even do the `evolution --force-shutdown`), which is weird, because besides the experiment with deleting the secret I didn't do anything else. Thanks for the quick answer and apologies for what seems to be a false alarm.

WRT the error message, would it be possible to print what D-Bus service it failed on? That would give a much better idea where to look.

No problem, the D-Bus is sometimes doing magic (here too, but very very very rarely, like couple times a year). I'll close this.

I opened a bug against glib2 some time ago:
https://gitlab.gnome.org/GNOME/glib/-/issues/2269

and they redirected my to the right place, but I do not have a new bug there. Thinking of it, such service names can look like ":1.234", which is similarly useless as not writing it there at all.

Something somewhere (if it's not directly evolution) has to know what it's connecting to, and I'd say that's the place where you can always add the name...

You are right. It could be done by prefixing the returned error with something like "Failed to connect to calendar factory:". One "problem" is that such changes might go to every dependency which call D-Bus directly or indirectly, because the D-Bus usage can be hidden under the hood (it's when providing high-level API on top of the GDBus proxy, which for example evolution-data-server does). I'll see what I can do on the evolution-data-server side.

Thinking of it, this is even more complicated. Prefixing the error message is fine, but it cannot be done only at the lowest place, it needs to be done in the caller too, thus one knows what the code was trying to do (and why). That might construct weird error messages like this one:

   Failed to XXXX: Failed to YYYY: Failed to ZZZZ: Some error text

While it would be nice to get detailed errors like this, it also can look odd to the users. I guess.

The "Failed to X/Y/Z" cascade seems perfectly fine to me as long as X, Y and Z don't repeat the same thing. Even if they did, though, are you worried that it would look weird, and prefer the current error message that doesn't give any hint at what's gone wrong?

I'd say any error message in Evolution looks weird, honestly, and I don't want to see them :). But if I have to, I'd very much prefer they look weird and actually help me find what's wrong.

(and I do understand very well it's often not easy to provide good error messages, believe me :))

I'm afraid that I'll:
a) miss some important parts;
b) add hundreds of translatable strings (the eds is a larger project)... which would be for good, I know.

The chaining of the error reminded me of a very old joke, an error message from I think the first Unreal Tournament, which consisted of more than 10 long lines of text describing the places the error was propagated thought. It was good for the developers, but useless for regular users.

Anyway, I opened an upstream bug [1], thus it doesn't get forgotten. I won't work on it myself at the moment, but maybe there will be someone willing to start on the eds code, whom can take it.

[1] https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/395

Well but that's for the most part the correct solution. The example you have in the upstream bug (sorry I don't have an account there):

Failed to open address book: Failed to create D-Bus proxy: The name is not activatable

Is actually how a proper error message should look like (possibly missing the D-Bus endpoint it failed to connect to).

And the fact that you have to add it to so many places just speaks to the amount of ambiguity the generic error message represents. If there are 83 possible places the error can occur and there's no way to distinguish which which of them the user is dealing with, it's quite a bummer (I understand some of them may give different messages, most of which will likely by similarly useless without the context).

> I'm afraid that I'll:
> a) miss some important parts;

You shouldn't worry about that. Do your best effort and if some errors are left unhandled, you can add the handling when a bug report comes.

> The chaining of the error reminded me of a very old joke, an error message from I think the first Unreal Tournament, which consisted of more than 10 long lines of text describing the places the error was propagated thought. It was good for the developers, but useless for regular users.

That seems like a stack traceback. That's a different thing, yes, often very useful for developers. Not really what we're discussing here.

Anyways, this is what I leave you with :) And sorry if I'm too persistent already. I hope it'll get done eventually. This wasn't the first time I was struggling with this process in Evolution and likely not the last...

That's okay, I agree the errors with context are better. There are places where the context is added already.