[SOLVED] Gnome-calendar flatpak vs. gnome online accounts

Hi all,

this is most probably not specific to RL, however I hope someone here has a better understanding of gnome and packages and can point me to right direction.

Gnome-calendar is repeatedly unable to use the calendars set up in gnome’s own “online accounts”.
This is an error which is well-known, although it seems not affect every distro. From what I believe/suspect it’s the flatpak’ed flavour that shows this behaviour.

Looking at repos, I didn’t find anything that appears to be suitable to work in RL. Our current version of the gnome “stack” is 3.32.2 whereas the current stream is at 42.something. (Which isn’t a bad thing when looking at all the extensions the gnome folks regularly leave behind broken with their pace of throwing updates at people - one of the reasons I quit using Fedora)

Long story short:
Does anyone can tell me how/where to get a 3.32-comaptible version of gnome-calendar that (preferrably) isn’t a sandboxed version but a “native” package? I’d even be willing to try to get my hands dirty with trying to build/make that from source, albeit a little stretch looking at my skills… :wink:

TIA, Cheers, Thomas

But you havn’t explained what “Gnome calendar” is or how you installed it or in what you online accouts interacts with it and what exact errors it’s showing…

@gerry666uk he installed using flatpak.

You could try getting the code from here: GNOME / gnome-calendar · GitLab

It would mean registering on their Gitlab instance, and you could possibly then pull the code and compile and install it.

1 Like

Hi @gerry666uk and thanks for coming back.

Yeah, you’re right. So there you go:
“Gnome Calendar” is gnome’s default, built-in calendar app.
Gnome is one of the supported desktop enviroments for RL (usually, the default one - so when you just download a workstation edition of RL, this is the dekstop you will see)

Install is done by launching the “Software” app and typing “calendar” which will give you a couple of hits from repos and then you just click the one in question (here: it’s a flatpak version)

The online account in question is, of course, MSO365.
Now, before everyone comes up to tell me the nuts and bolts why that possibly doesn’t work, here’s the thing;

I have evolution anlong with evolution-ews up and running fine.
It shows (amongst other) all calendar entries from that MSO365 account perfectly.
Also, gnome’s “clock widget” calendar shows the dots for days with calendar events. That’s pretty much self-explaining because the widget shares the same stuff with evolution.
So, basically - everything works.

Except for gnone-calendar. It is unable to display anything from the “online accounts” (whilst evolution and the gnome clock/calendar widget does!). That drives me nuts. All I need/want is a nice-looking, big and undistracting overview of my upcoming calendar events.
I don’t want to have to launch/switch-to evolution or the reduced representation of the clock’s cal for a focused glimpse at my calendar.

That’s it. Cheers, Thomas

NOTICE: UPDATED - SEE BELOW

Thanks @iwalker - thanks for pointing out.

I’ll give it a try but am sure to have to deal with quite a lot of dependent D/L and installs, so it will surely take some time. :slight_smile:

BTW I fired up Manjaro in VirtualBox to see whether THEY have implemented something that works better in these regards (placing bets on AUR) but it’s exactly the same like on RL, which means that even with all of gnome’s most recent libs and software stack, the issue persists.
Reminds me, I read somewhere that evolution started breaking the API some versions ago, leaving the gnome-calendar unable to interface it in order to fetch data. That would mean that compiling gnome-calendar from source wouldn’t fix anything as the root cause is evolution! Useless work. Well, let’s see.

Cheers, Thomas

UPDATE:
Like always, I wasn’t patient enough to allow stuff to initialize and settle.
After a couple of minutes down the road, gnome-calendar on Manjaro shows everything correct.
Well, that could mean that I’ll just have to wait until RL bumps into the upstream fixes for the gnome stuff. Unfortunately, as I don’t know at which revision they introduced the fix (and where exactly), it leaves me with no idea how long I’ll have to wait. :slight_smile:
I am rather willing to wait for a long time than having to move away from RockyLinux.

OK, that’s the info I was looking for; so I could clarify whether it was available as an rpm in the rocky repos. But you already have Evolution and Office 365, so can’t you just use the EWS calendar?

In general, the Rocky supplied Gnome apps like Evolution and it’s calendars log a lot of info into ‘/var/log/messages’, so it’s worth checking, but I don’t know if the non-Rocky Gnome calendar would do the same.

Something related is that Microsoft say they’re going to turn off basic auth, so EWS would stop working, but do you have something like Oath2 set up?

I probably could, but basically I’m not demanding more than just gnome-calendar to actually do what it claims to be capable of doing. Show my calendars which are already present in evolution. I don’t want to run a browser window or webview-based “app” to access the calendar online despite it having been synch’ed to my machine already. That doesn’t really make sense.
So, in a nutshell, I just expect gnome-calendar it to do its job.

Right now, I leave all the dirty stuff and nasty details with gnome (through it’s “online accounts” handling) and that appears to work just fine. FWIW, here’s some detail about that:
https://wiki.gnome.org/Apps/Evolution/EWS/OAuth2

KDE apparently as well seem to support Exchange OAuth2 with their kontact/korganizer suite. But then, KDE isn’t really my kinda look and feel. Anyways, as mentioned in the other response, Manjaro has a more recent flavour of the GNOME stack and its gnome-calendar works just fine. So it’s all a matter of having to wait for the fix to arrive on RL.

Cheers, Thomas

SOLVED.

Easy(*) as duck soup:
Just install the matching version of gnome-calendar from flathub instead of the most current one.

* It involves a bit of fiddling though, by having to first install the latest version and then “downgrade” it to the commit that matches the desired gnome version. And then, of course, freezing that downgraded version from being almost instantly auto-updated to the recent version using flatpak mask.

A bit more info on downgrading here:

And here for flatpak’s mask command:
https://man7.org/linux/man-pages/man1/flatpak-mask.1.html

Cheers, Thomas

2 Likes

But Evolution already has a Calendar inside it; you don’t need a web browser.

Hi there,
I know. And I’m using it on a daily basis.
But with a total of 4 calendars joint into a single view (work, private, family shared, holidays), evolution isn’t the best suited way of having a good overview and gnome-calendar is by far superior and pleasant to use in that regard.

Oh, and yes, I know I don’t need a browser. I only mentioned it because I (mistakenly) assumed you suggested that.

Cheers, Thomas

In Evolution, you can toggle each calendar on/off, so you can hide e.g. the holidays.
Nothing wrong with haveing Gnome calendar as well.

Yup. But having to toggle calendars on/off in order to have a better overview doesn’t really help when what I need is to see ALL calendars to have, well, that overview. :slight_smile:

As soon as I’m back home and have some sparetime, I’ll make comparison screenshots of how evolution shows it and how gnome-calendar shows it and you’ll probably get the issue.

Then again, to get back to the topic, my issue isn’t about evolution vs. gnome-calendar or any other app or workaround, not about evolution features… it is simply about the fact that gnome-calendar, in its current, default, setting on RockyLinux, doesn’t do what it’s supposed to do.

Cheers, Thomas

Wait; did you add the Flatpak repo yourself after installing Rocky, or was it magically there after the install? Can you try:
dnf repolist all

Nor perfectly sure if that will yield meaningful results. Flatpak is a package manager totally separate from dnf/yum and therefore dnf repolist all will not know neither tell anything about flatpaks.

Anyway, as this topic is solved, I don’t think it is worth people’s time to go on discussing the pro and cons of flatpak here. Feel free to open a new thread for it if you want me to dig out something for you.

Cheers, Thomas