Package Details: sogo 5.0.1-1

Git Clone URL: (read-only, click to copy)
Package Base: sogo
Description: groupware server built around (OGo) and the SOPE application server
Upstream URL:
Licenses: GPL
Replaces: sogo2
Submitter: DJ_L
Maintainer: deons
Last Packager: deons
Votes: 11
Popularity: 0.124410
First Submitted: 2016-05-05 01:05
Last Updated: 2020-10-22 16:05

Dependencies (20)

Required by (0)

Sources (4)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 Next › Last »

a_manthey commented on 2018-12-15 21:26

DJ_L -sorry, i saw your comment just now. Since 4 months i run it without any problems on rpi3 armv7 for my family network.

DJ_L commented on 2018-11-18 21:14

a_manthey - you stated specifically that it builds. Let us know if it runs acceptably and it can be added. A bit busy now, but I'll get to work on a Pi build in a couple of weeks. I've got a handful of them sitting around doing nothing ATM.

a_manthey commented on 2018-11-17 10:34

builds on raspberry pi3 too if armv7h is added to arch in PKGBUILD

deons commented on 2018-10-11 07:40

Hi DJ_L,

Thanks for your patches on the bug report, I have now included them in the arch packages.

deons commented on 2018-10-10 05:57

Hi DJ_L,

Some info that might be useful to you. SSL_load_error_strings(); was introduced in 4.0.2 via the following commit

to fix the following bug "S/MIME emails are rendered blank when using GnuTLS"

The ssl_load_error.patch that I have included in this package reverts that commit, not the best solution and is just a temporary solution.

I have tested S/MIME emails and everything is still fine on archlinux.

Thanks again for all of your help.

DJ_L commented on 2018-10-09 17:31

Thanks. If that works for chetwisniewski, we'll need to create proper version specific patches and attach to the bug at I'll do it tonight if I have time.

deons commented on 2018-10-09 06:35

Hi DJ_L,

I only needed to remove it from sogo (UI/MailPartViewers/UIxMailPartSignedViewer.m) and now everything is working for me. Thanks for your help. I have added the fix to the PKGBUILD file for now. If anyone else is having a problem with this package please leave a comment.

DJ_L commented on 2018-10-09 04:42

I'm not sure that ssl message isn't a misnomer. Unfortunately, with OpenSSL-1.1.1, it appears that the message you are seeing should be harmless. The library is initialized by default now days.

The suggestions should get rid of the SSL error messages on OpenSSL-1.1.0+ (just drop in immediately before configure in each resp.).

For SOPE (forgive the long line, you can break in the PKGBUILD):

sed -e '/SSL_library_init/d' -e '/SSL_load_error_strings/d' -i sope-core/NGStreams/NGActiveSSLSocket.m

For SOGo:

sed '/SSL_load_error_strings/d' -i UI/MailPartViewers/UIxMailPartSignedViewer.m

Again, the above is just speculation, I have NOT seen that error, but I suspect it was because I lag behind a bit. I've built as above, against OpenSSL-1.1.1 before suggesting those, and it is still working for me. The issue I had seen today was with the recent mariadb upgrade (a restart of mariadb fixed it). Again, however, the messages should be harmless, so I doubt that fixes the message list errors, but worth a shot I suppose.

Note: Forgive the edits, I've no idea how to force a hard return. Also, if this does not get it, despite the fact that I don't see the error, two to one, I'd suggest dropping back to 4.0.1 until the devs answer in the bug.

DJ_L commented on 2018-10-08 16:27


DJ_L commented on 2018-10-08 16:25

I too am seeing the issue now. OpenSSL-1.1.1 is the cause. I did not have time to address this morning, but I'll try and update again this evening and see what I can do to track it down. Assuming it's not a dependent library someplace, a cursory glance suggests that we need only to add a conditional in SOGo for SSL version and then use OPENSSL_init_ssl() rather than SSL_load_error_strings(). Again, I didn't really have time to look at it and IANAP, so I may be over simplifying. SOPE uses GNUTLS by default, so no worries there, but it should fixed anyway for the off chance that GNUTLS is not available as well (both should be done upstream, but will have to be done locally in the interim assuming that I'm even correct, of course).