I confirm this.

One is from GOA (Gnome Online Account), the other is from Evolution and it has an URL similar to https://www.google.com/calendar/dav/name%40domain.com/events/

If you're seeing it in Evolution as well, it's not a Calendar-specific bug.

You are right, I hadn't checked Evolution: calendars are duplicated in Evolution as well.

I've searched through the bug list in evolution data server and gnome-online-accounts but couldn't find any relevant bug.
Isn't it a bug? Where should it be reported?

I'm changing the product to Evolution-Data-Server. Milan, can you please confirm the issue?

Thanks for a bug report. I think I saw something similar in the past, it could be in time of 3.18 or even earlier. I do not have any bug link for it, unfortunately. The current stable is 3.24.5 currently, where I do not see this issue myself, thus maybe it's gone.

Just a guess, could you provide a list of running evolution processes in the time when you've been adding the GOA account, please? I'm wondering whether there are multiple evolution-source-registry processes, because that's the one which is responsible to make the connection between GNOME Online Accounts and eds.

It would be good if you could retest with 3.24.x or any later version, because it happens often that even I cannot reproduce it locally the users on their machines can. Thanks in advance.

I'm now on Fedora 26 (Gnome 3.24.2).
I still have duplicates.

Milan, how can I list running evolution processes *while* adding the GOA account?
(the while is the problem)

(In reply to Federico Bruni from comment #6)
> I'm now on Fedora 26 (Gnome 3.24.2).
> I still have duplicates.

Did you update existing machine or started from scratch. Aka will duplicates be added for a new user, whom didn't have configured Evolution or any GOA account yet?

> Milan, how can I list running evolution processes *while* adding the GOA
> account?
> (the while is the problem)

The evolution-data-server gets in action only after you confirm the account creation in GOA. I do not think getting exact time of the confirmation would do any difference, thus it can be `ps ax | grep evolution` before and after you confirm the account in GOA and then compare process IDs and such.

A bit easier would be to run the source registry from a terminal with its debugging on and add the GOA account there. That means:

a) figure out what processes are running: ps ax | grep evolution
b) run the source registry form a terminal:
   $ ESR_DEBUG=1 /usr/libexec/evolution-source-registry
c) wait a bit and then kill all but this process from b), as listed by a),
   but stop evolution-calendar-factory as the last, because, if you run GNOME
   Shell, it'll restart it on its own
d) add the account into GOA. The terminal with evolution-source-registry
   will print what sources had been added and with what content

Yes, I updated existing machine.

Now I've removed the account from GOA.
I opened Evolution and I see that there's still one calendar from that account. After removing the Evolution email account, Evolution calendars list zero calendars.

So I'm kind of starting from scratch. I've followed the second approach you are suggesting.
gnome-control-center crashed after I've added the account: Process 15678 (gnome-control-center) crashed in update_buffers()
Anyway, now I see only one calendar in either Evolution and GNOME Calendar.

Let me know if you'd like to see the logs from command b) or need other tests from me (e.g. I wonder if adding back the email account to Evolution would add a second calendar).

Thanks

Ah, I see, I'm sorry I didn't get it from the very beginning, even it's written in comment #0. You have configured one account in GOA and another account in Evolution, independent from the GOA, both accessing Google servers.

Whether Evolution configures also calendars/tasks/address books depends on the last page of the new Mail Account wizard, where can be chosen whether to add also calendars/tasks and address books. Not having Evolution doing that will not cause the duplicated sources. Similarly, if you enable also Mail part in GOA, then you get configured a mail account in Evolution related to that GOA account. Advantage is that the same OAuth token will be used, instead of having two independent tokens.

From that I'd say it's not a bug, it's expected behaviour.

Please, correct me if I'm wrong or if I misunderstood anything. I would eventually reopen this bug report. Thanks in advance.

I forgot to add:

(In reply to Federico Bruni from comment #8)
> gnome-control-center crashed after I've added the account: Process 15678
> (gnome-control-center) crashed in update_buffers()

It would worth have it filled, especially if it's reproducible, against
gnome-control-center with attached backtrace of the crash, thus the developers
of gnome-control-center can investigate the crash further.

(In reply to Milan Crha from comment #10)
> I forgot to add:
> 
> (In reply to Federico Bruni from comment #8)
> > gnome-control-center crashed after I've added the account: Process 15678
> > (gnome-control-center) crashed in update_buffers()
> 
> It would worth have it filled, especially if it's reproducible, against
> gnome-control-center with attached backtrace of the crash, thus the
> developers
> of gnome-control-center can investigate the crash further.

I've sent the bug report for this

(In reply to Federico Bruni from comment #11)
> I've sent the bug report for this

Thanks. Do you have a link for it, for a cross-reference, in case some bugzilla/archive reader would like to follow it, please?

Yes, but I've used gnome-abrt in Fedora for the first time and I've sent the report to bugzilla red hat. Perhaps not everyone is allowed to see it at the moment, as it said that it may contain personal data (probably wrong assumption, if I checked correctly the report):

https://bugzilla.redhat.com/show_bug.cgi?id=1497952

You have to know that the above report is restricted to RedHat employees only.

You are right, but it seems I cannot uncheck "Fedora Contrib Private (Bug is private to Fedora contributors)".

I made it public. The backtrace doesn't seem to reveal any password and Fedrico seems to be fine to make it public too.

Okay, thanks ;)