Sometimes an error pops up in evolution for a specific account. Situation: I’ve added 3 accounts to online accounts in Gnome online accounts, one of the accounts is a gsuite account. For some reason the authentication seems to fail sometimes for the gsuite account and throws an error: Data source <username>@<mymaildomain> does not support OAuth 2.0 authentication The other accounts work fine and sync the needed items.
Every time it happens and I get sufficiently annoyed and have some spare time I’ll do some research and find some reports 12 but no solution until I stumbled uppon a possible solution here with is a update in librest (0.8.1-11) for clearlinux. This seems to be a update for a Gnome library that does not appear with the same name in pamac.
Arch/Manjaro run rest 0.8.1-3.(there is no librest) and the depenency on gnome online accounts seem to me it is the same thing. I’m not sure how to proceed, on the gnome gitlab there is no version 0.8.1-11 so it does not seem the same package, it does seem to provide the same function according to the dependencies. So if my assumptions are correct (witch I doubt) there might be a release of librest/rest sometime in the future that might solve the symptom I have.
I must say that git and version release info is a mystery to me, am I looking at the wrong things making the wrong assumptions and interpreting wrongly?
(if there is a solution to the specific error, that would be great to)
The patch mentioned only seems to apply to their build and won’t help us, unfortunately.
The last number after the dash is the pkgrel. The Arch Extra package rest 0.8.1-3 has had two rebuilds since the first release. Apparently Clear Linux has done more fiddling with their librest 0.8.1-11.
Made some progress in setting up monitoring in a vm using the following versions (as reported in pamac)
evolution 3.38.2
gnome online accounts 3.38.0-1
glib-networking 2.66.0-1
Manjaro Gnome kernel 5.10.2-2 , stable dd 18-01-2021
Following the debugging pages (12) I’ve started the 2 processes in debug mode with stdout output to a logfile. (As a double test the same is run on my production machine and will verify if the seen behavior matches, no sense in finding something that does not match my production situation)
The ‘test’ consists of me running these 3 processes from a terminal and waiting / daily workflow and waiting for oauth/403 errors.
Results so far. Regrettably when the error did occur, the log was not running, as I was still setting up the terminals to run the commands, and from there on out it won’t show. I’m starting to suspect that the early start of the sub processes somehow do not trigger the error. Since I can somewhat reliably reproduce the error by having evolution autostart at login (using tweaks and rebooting)
All in all I conclude that reproducing the error reliably and having sufficient logging is going to be a lot more work. Let alone find the root cause and then fixing this. For my specific situation it is easier to have script run the sub processes once after login using autostart and see if this will prevent the error I experience. I’ll leave the VM running for a few more day’s and see if something interesting happens.