After updating to the following packages: timezone-java-2020d-1.mga8.noarch timezone-2020d-1.mga8.x86_64 Evolution fails to display any tasks or appointments, either showing errors saying that the backends for notes, appointments and tasks shutdown unexpectedly or, reporting no errors but not displaying any appointments or tasks. (Notes can still be accessed.) I am not sure if the problem is with the packages themselves or a need to rebuild Evolution.
Source RPM: (none) => evolution-3.38.1-1.mga8.src.rpmAssignee: bugsquad => gnome
Thanks to David's comments on the dev mailing list, I have also filed a bug upstream: https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/267
@aguador, a comment has been made on upstream BR. https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/267
CC: (none) => ouaurelien
@Aurellen_Oudelet, I just ran gdb and responded. As noted in the gitlab link Fedora apparently has committed a patch. Milan, the evo dev, is tops. Let's see what he says.
After viewing backtraces, upstream suggested rebuilding libical with a patch. I downloaded the patch and eliminated superfluous lines, installed packages needed to build libical (no-recommends), and added the patch to the spec file. Everything built fine, and I installed only the new lib64ical3 file. However, the error remains. Given my limits (only the vaguest idea of what I'm doing!), I will attach the patch and modified spec file (bumped build for my purposes) and ask if someone can take a look to assure that I did not make an error in rebuilding.
Created attachment 11974 [details] Patch file as tested
Created attachment 11975 [details] Modified spec file tested
Wow, the upstream guy seems really nice. Since you added it as Patch0 I think the %patch line should be %patch0 -p1, but I've added Fedora's patches to our libical package anyway (in libical-3.0.8-4.mga8).
I knew there was something wrong -- but not so stupid! Just installed the updated packages (including # urpmi --replacepkgs lib64ical3-3.0.8-4.mga8.x86_64 to fix what I had done), but the problem continues. Sending the backtrace to Milan -- and, yes, I have been on the Evo ML for years and he is a gem.
Here are the conclusions from upstream (copy of https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/267#note_952898): It seems to me that Mageia has "incorrectly" generated files with respective time zones. If I'm not mistaken, those are provided by timezone-2020d-1.mga8 package. I think so, because for example /usr/share/zoneinfo/America/New_York (and yours /usr/share/zoneinfo/Europe/Madrid too) has included TZif2 file format header multiple times in the file. The libical fails to read it and eventually crashes. Interestingly, Fedora's tzdata-2020d-1.fc33.noarch provides the New_York file with two TZif2 headers as well, but the first occurrence is not empty. Maybe that's the reason, the empty part confuses libical, which "rejects" to read the next part. In any case, when I run libical's make test internal tests using the Mageia tzdata, some of them fail. Thus this is a libical issue, not evolution-data-server's. It would be good to pass it to them [1], but I do not have an account there, thus I cannot do it myself. It can be the [2] is related. [1] https://github.com/libical/libical/issues [2] https://github.com/libical/libical/issues/449 ------------------------------------------------------------ @David_Walser, do you agree this is an libical issue and not a Mageia 8 issue? If so I can report this on libical. (Note it is not clear that this is related to libical issue 449.) Thanks.
Yes, please report to libical. Thank you!
CC: (none) => luigiwalser
Done: https://github.com/libical/libical/issues/454
Note that, under M7 Gnome with Evolution in Central Europe Timezone Europe/Paris (Same as Europe/Madrid), creating appointment is OK with this java and timezone updates. Subsequent Closing/Reopening Evolution is OK under M7. No crashes. Testing under Cauldron with Gnome and Evolution: Same behavior. Updated: timezone-java-2020d-1.mga8.noarch timezone-2020d-1.mga8.x86_64 Evolution is 3.38.1-1.mga8 Switching to TZ to Europe/Madrid and rebooting with drakclock. $ timedatectl Local time: mar. 2020-11-10 10:42:10 CET Universal time: mar. 2020-11-10 09:42:10 UTC RTC time: mar. 2020-11-10 09:42:10 Time zone: Europe/Madrid (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no Same behavior. Can view in Evolution existing appointments and creating new ones. But that is "strange" is that UI does not seem to remember TZ in appointment UI. But, under Evolution Preferences, Europe/Madrid is correctly selected. Also, lib64ical3-3.0.8-4.mga8 is installed. No errors about that in system journal.
Have not checked Mga, but on Cauldron: Ran timedatectl and saw that RTC was in local TZ. Changed to UTC. Restarted, Evo still not working. System clock is not synchronized. Is chrony needed to do so? It is not installed on my system.
You can simply enter this # timedatectl set-ntp true It will be systemd-timedated which will act as a ntp client. RTC should always be in UTC if Windows is not installed.
Ah, I had forgotten why I set it up that way. This is a dual boot machine, but no matter. A couple of odd things. Here is what I just did: [aguador@localhost ~]$ sudo timedatectl set-ntp true [sudo] password for aguador: [aguador@localhost ~]$ timedatectl Local time: mar 2020-11-10 15:43:34 CET Universal time: mar 2020-11-10 14:43:34 UTC RTC time: mar 2020-11-10 14:43:34 Time zone: Europe/Madrid (CET, +0100) System clock synchronized: no NTP service: active RTC in local TZ: no So NTP shows as active here, but no sync. The oddity is that in MCC NTP does not show as being set -- and when I tried setting if from there before, it still did show as being set. I had wanted to get sync in order to have the same config you used in the tests, but so far no luck - and Evo calendar and tasks are still not working.
(In reply to aguador from comment #15) > Ah, I had forgotten why I set it up that way. This is a dual boot machine, > but no matter. > > A couple of odd things. Here is what I just did: > > [aguador@localhost ~]$ sudo timedatectl set-ntp true > [sudo] password for aguador: > [aguador@localhost ~]$ timedatectl > Local time: mar 2020-11-10 15:43:34 CET > Universal time: mar 2020-11-10 14:43:34 UTC > RTC time: mar 2020-11-10 14:43:34 > Time zone: Europe/Madrid (CET, +0100) > System clock synchronized: no > NTP service: active > RTC in local TZ: no > > So NTP shows as active here, but no sync. The oddity is that in MCC NTP does > not show as being set -- and when I tried setting if from there before, it > still did show as being set. System must be restarted for systemd-timedated to correctly set this or do # systemctl daemon-reload > I had wanted to get sync in order to have the same config you used in the > tests, but so far no luck - and Evo calendar and tasks are still not working. MCC only configures a NTP client with chrony package. It does not configure systemd-timedated. But, I do think it is not mandatory all of this to get Evolution to work as expected.
(In reply to Aurelien Oudelet from comment #16) > > System must be restarted for systemd-timedated to correctly set this or do > # systemctl daemon-reload > Of course, I'm doing too many things at once! > > But, I do think it is not mandatory all of this to get Evolution to work as > expected. Precisely, now synced, but still not working. I see that I have timezone-2020c on my Mageia 7 system -- which is working. Strange because the only real code and build changes I saw for tzdb came in 2020b, so there should be no great difference. HOWEVER, looking at /usr/share/zoneinfo/Madrid in the DoubleCommander viewer, 2020c on Mageia 7 has only one TZif2 header, not 2 -- and it is substantially larger: 2.6k v 897 bytes.
Oops, the size may be a function of encoding: the 2020c file is ISO-8859-1, the 2020d file CP1253.
An upstream fix is in the works for libical. For those interested in the details: https://github.com/libical/libical/issues/454#issuecomment-724914741
@Aurelien_Oudelet I needed to followup more here as libical crashes on my Cauldron system, even with the configuration settings the same as yours. I have not installed 2020d on Mga7 given that the problem in Cauldron persists. However, the question remains as to how it is that you experienced no problems in testing when my system and that of the Evo maintainer both failed. I am running Enlightenment 1.24.2 and assume the Red Hat maintainer is running Gnome. It does not seem likely, but could there be some difference related to the DE?
Upstream issue has been closed in libical after commit on 13-10-2020: https://github.com/libical/libical/issues/454#issuecomment-728991756 No new release yet.
Source RPM: evolution-3.38.1-1.mga8.src.rpm => libical-3.0.8-3.mga8.src.rpmSummary: Evolution fails to display appointments, tasks after timezone update => Timezone-2020d update causes libical to crash making it impossible for Evolution to handle appointments, tasks
Patch included in libical-3.0.8-5.mga8.
(In reply to David Walser from comment #22) > Patch included in libical-3.0.8-5.mga8. Fantastic. Thank you David. Evo seems back to normal in Cauldron. Curiously, I updated timezone in Mageia 7 with libical-3.0.4 and Evo 3.32.2 and, indeed, as Aurelien found it was unaffected by the problem, so all is well. Closing bug report.
Status: NEW => RESOLVEDResolution: (none) => FIXED