After installing both evolution and evolution-ews in a clean install of Mageia 7 the option to create accounts using Exchange Web Services does not appear in Evolution. Version-Release number of selected component (if applicable): evolution-3.32.2-1.mga7 evolution-ews-3.32.2-1.mga7 How reproducible: Install evolution and evolution-ews then attempt to create either a mail account or a collection account with the server type of Exchange Web Services. The error messages when Evolution is launched form the console are: (evolution:4656): e-data-server-WARNING **: 14:59:41.251: module_load: libcamelews-priv.so: cannot open shared object file: No such file or directory Failed to load module: /usr/lib64/evolution/modules/module-ews-configuration.so (evolution:4656): camel-CRITICAL **: 14:59:41.371: camel_provider_list: Could not load /usr/lib64/evolution-data-server/camel-providers/libcamelews.so: libcamelews-priv.so: cannot open shared object file: No such file or directory (evolution-alarm-notify:4683): camel-CRITICAL **: 14:59:41.592: camel_provider_list: Could not load /usr/lib64/evolution-data-server/camel-providers/libcamelews.so: libcamelews-priv.so: cannot open shared object file: No such file or directory The file libcamelews-priv.so does exist in /usr/lib64/evolution-ews/.
Assigning to you, Olav, rather than anybody, because you are the top Evolution committer! I will try this myself when I have a moment.
CC: (none) => lewyssmithAssignee: bugsquad => olav
In the forum thread linked doktor5000 was able to come up with a manual fix. Copying /usr/lib64/evolution-ews/libcamelews-priv.so, /usr/lib64/evolution-ews/libevolution-ews.so, and /usr/lib64/evolution-data-server/camel-providers/libcamelews.so to /usr/lib64 allowed Evolution to work correctly with Exchange Web Services.
Matt Farrell did you try creating a link in /usr/lib64 for each of the .so instead of copying them?
CC: (none) => rihoward1
No, I just copied them directly. I will remove the copies and try creating links instead. I will also try different combinations of the files to see if all three are needed.
CC: (none) => doktor5000
It appears that I was a little hasty in saying that the problem is fixed. While either linking or copying the files to /usr/lib64/ allows the option to select Exchange Web Services for a mailbox type it is still not fully functional. On my primary desktop the account settings were in place so it picked up as soon as the files were visible to the application. On my test machine while the option showed up it would not save the account settings.
I realized that the account that was not working was the one that I had been testing everything with. I created new test accounts and verified that the fixes are working. I tested with the three files copied into /usr/lib64/ and with both hard and symbolic links using three separate new test users. In all three cases Exchange Web Services was offered as a server type and was able to connect without any problems.
Thank you Matt for your exploration of this problem and its resolution. . The solution you found looks like a packaging issue. There are two developers seeing this bug; if you think it is not for you, please re-assign it to pkg-bugs or whoever you see as most appropriate. TIA.
I can confirm that the workaround of creating the symlinks make both the Exchange account selectable in the configuration wizard and working afterwards. I choose the symlink because in case of an update if the file is overwritten the link points to the new one. Maybe a workaround can be put in place in the package before the “right” solution can be implemented by making the post install of the rpm do the symlinks.
CC: (none) => g.merigo
Re-assigning to all packagers since the solution is identified, and nothing seems to be happening. Thanks to RH, Matt & Giuseppe for your contributions.
CC: lewyssmith => (none)Assignee: olav => pkg-bugs
I tried to understand which files are at the bad place, and could not : Failed to load /usr/lib64/evolution/modules/module-ews-configuration.so It does not fail when it is in /usr/lib64/module-ews-configuration.so ?
CC: (none) => lists.jjorge
Could you try with upcoming evolution-ews-3.32.2-1.1.mga7 in Core/Updates_testing repo, please?
CC: (none) => geiger.david68210
I could test it only this morning and - provided you remove the symlinks - it seems to work. I can download emails and see calendar entries, and a brief search for contacts worked.
Assigning to QA, Advisory: ======================== This update fixes load errors with evolution-ews's private shared libraries enabling rpath. For load errors reference: (evolution:4656): e-data-server-WARNING **: 14:59:41.251: module_load: libcamelews-priv.so: cannot open shared object file: No such file or directory Failed to load module: /usr/lib64/evolution/modules/module-ews-configuration.so. ======================== Packages in 7/core/updates_testing: ======================== evolution-ews-3.32.2-1.1.mga7.x86_64.rpm evolution-ews-3.32.2-1.1.mga7.i586.rpm Source RPM: ======================== evolution-ews-3.32.2-1.1.mga7.src.rpm
Assignee: pkg-bugs => qa-bugsSource RPM: (none) => evolution-ews-3.32.2-1.mga7.src.rpm
Not an Evolution user, but I installed it and the evolution-ews package on a 64-bit Plasma system. Ran the app, looked at this and that, and it looked like it would work if I followed through with the setup procedure. Backed out, and updated the -ews package. No installation issues. There is an evolution 3.32.2-1.1 package in the testing repo, but that is for Bug 25893, a different issue. I did not install that. Ran Evolution again, and again looked at this and that, with no obvious regressions noted. Since Giuseppe reports that the issue is fixed, and I had no install issues, I'm giving this an OK and validating. Advisory in Comment 13.
Whiteboard: (none) => MGA7-64-OKKeywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0002.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED