Comment 5 for bug 2018435

On 5/25/23 6:33 AM, Sebastien Bacher wrote:
> Did you have a chance to try it?
>
Yes, and unfortunately it wasn't successful. According to the debug log
for the addon, it's not able find libecal-1.2 or libecal-2.0.

It's seems to be the same issue that the Thunderbird flatpak version has
with the EDS addon as described here:
https://github.com/balbusm/xul-ext-eds-calendar/issues/50

Even with installing the beta version in developer mode, it's still not
able to find libecal-2.0 on the host. I thought it was odd that running
ldconfig -p |grep libecal in a shell within the thunderbird snap will
list libecal-2.0.so.1 in /lib/x86_64-linux-gnu/, but ls
/lib/x86_64-linux-gnu/libecal* shows no such file.

I did install the test-snapd-eds snap as a way to test the calendar
service interface outside of thunderbird, but ran into the same issue
where the snap tried to load an older libecal-1.2.so.19 (I think that
was the version) library, but couldn't find it.

I think the issue most likely lies with the addon, but without a way to
test whether the calendar service interface first works correctly with a
snap, I wouldn't be able to provide the addon developer any useful
information on how it should work as that's getting well above my level
of expertise.

So reverted back to the stable release as I don't dig the interface
changes to the beta version and will wait to see if the developer can
get the addon to work with the flatpak without breaking its confinement
policy.