Arch Linux User Repository

@nachfuellbar postgres-libs are now added as dependency, thanks.

Just wanted to ask - is there any reason why postgresql-libs isn't even listed as dependency but mariadb-libs are? In online documentation postgres is described and "othere database servers are supported" https://www.sogo.nu/files/docs/SOGoInstallationGuide.html#_database_configuration

Looks like the download URL for SOPE and SoGo has changed and curl doesn't redirect, the new location: https://packages.inverse.ca/SOGo/sources/

Just wanna drop some info about CalDAV. If you also have issues syncing calendar between SOGo and Thunderbird, have a look at: https://bugzilla.mozilla.org/show_bug.cgi?id=1737067#c6

@FrederickZh thanks, as a workaround I have added the preload to the systemd service file. It is now working.

@deons I gave LD_PRELOAD=/usr/lib/libytnef.so a shot blindly and it worked. Not sure why it wasn't loaded automatically though...

Seems to be related to a new depends for libytnef. Still investigating

compile error is fixed but now I am having an issue with undefined symbol: __objc_class_name_SOGoMailLabel

If I cant fix this soon I will have to revert to 5.1.0

I am aware that there is a new version out. I am currently working on a compiling problem. Will update shortly with progress.

And please add mariadb-libs to depends as well. If mariadb server runs on different server than sogo frontend, it will fail to start with:

Error (objc-load):libmariadb.so.3: cannot open shared object file: No such file or directory

Trying to build 5.0.0, noticed that:

inetutils is needed for the hostname command. Possibly a make dependency.

libsodium libzip are also required. These are shared libraries so I reckon they should also be needed during runtime.

Thanks to all for the help. Patches have been applied.

The dependency for sope should be gnustep-base<=1.27.0. The dependency for sogo is sope>=4.3.2. The patches work as advertised.

There are patches available for gnustep-base 1.27.0 and GCC 10 at https://sogo.nu/bugs/view.php?id=5029.

sope-4.3.2-1.patch

diff --git a/PKGBUILD b/PKGBUILD
index 1323b51..cbe223a 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -10,9 +10,9 @@ arch=('x86_64')
 url="http://www.sogo.nu/files/downloads/SOGo/Sources/"
 license=('GPL')
 options=('!strip')
 replaces=('sope2')
-depends=('gnustep-base<=1.26.0')
+depends=('gnustep-base')
 makedepends=('gcc-objc'
              'gnustep-make'
              'libxml2'
              'libmariadbclient'

sogo-4.3.2-1.patch

diff --git a/.SRCINFO b/.SRCINFO
index ceb858a..45ddcce 100644
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -27,12 +27,16 @@ pkgbase = sogo
    backup = etc/sogo/sogo.conf
    backup = etc/httpd/conf/extra/SOGo.conf
    backup = etc/conf.d/sogo
    source = http://www.sogo.nu/files/downloads/SOGo/Sources/SOGo-4.3.2.tar.gz
+   source = patch-gnustep-base-1.27.patch::https://sogo.nu/bugs/file_download.php?file_id=2190&type=bug
+   source = gcc10-fix.patch::https://sogo.nu/bugs/file_download.php?file_id=2189&type=bug
    source = sogo.service
    source = sogo.confd
    source = sogo_configure.patch
    sha256sums = ecf22e7763a3113ac86a891abbd0e50f7eac19275428798c34cf742cc83a446b
+   sha256sums = 663a9887ce7b31d6d6f4a54e7fe2d84dc2a569a5844a3194f8b9d7ee479f7c67
+   sha256sums = 3ed561519ad2a635869dd1d961329b557e1fa8fff0b0c4bc7e0b40926a35b13a
    sha256sums = 0720b9ad35a05d86d794c7adbf18277ecde57ed147e96f6105acca93f19d3b8c
    sha256sums = 8ee0d1ad77e998ea801053fce175d8c4a1c55dcc5ee1ff78f0a8e3797187a6a7
    sha256sums = e64ea4aa0ddf29785de8d786ab7ab09f940bfe316b6f1deeb8d04d9d16d35db1

diff --git a/PKGBUILD b/PKGBUILD
index 1828037..8876087 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -12,9 +12,9 @@ license=('GPL')
 options=('!strip')
 replaces=('sogo2')
 install=sogo.install
 makedepends=('gcc-objc'
-             'gnustep-make<=1.26.0')
+             'gnustep-make')
 depends=("sope>=${pkgver}" 
          'gnustep-base'
          'libmemcached'
          'memcached'
@@ -31,19 +31,25 @@ optdepends=('postgresql: run database server for sogo locally'
 backup=('etc/sogo/sogo.conf'
         'etc/httpd/conf/extra/SOGo.conf'
         'etc/conf.d/sogo')
 source=("http://www.sogo.nu/files/downloads/SOGo/Sources/SOGo-${pkgver}.tar.gz"
+        "patch-gnustep-base-1.27.patch::https://sogo.nu/bugs/file_download.php?file_id=2190&type=bug"
+        "gcc10-fix.patch::https://sogo.nu/bugs/file_download.php?file_id=2189&type=bug"
         "sogo.service"
         "sogo.confd"
         "sogo_configure.patch")
 sha256sums=('ecf22e7763a3113ac86a891abbd0e50f7eac19275428798c34cf742cc83a446b'
+            '663a9887ce7b31d6d6f4a54e7fe2d84dc2a569a5844a3194f8b9d7ee479f7c67'
+            '3ed561519ad2a635869dd1d961329b557e1fa8fff0b0c4bc7e0b40926a35b13a'
             '0720b9ad35a05d86d794c7adbf18277ecde57ed147e96f6105acca93f19d3b8c'
             '8ee0d1ad77e998ea801053fce175d8c4a1c55dcc5ee1ff78f0a8e3797187a6a7'
             'e64ea4aa0ddf29785de8d786ab7ab09f940bfe316b6f1deeb8d04d9d16d35db1')

 prepare() {
   cd "$srcdir/SOGo-${pkgver}"
   patch configure ../sogo_configure.patch
+  patch -p1 <"$srcdir/gcc10-fix.patch"
+  patch -p1 <"$srcdir/patch-gnustep-base-1.27.patch"
 }

 build() {
   cd "$srcdir/SOGo-${pkgver}"

@deons It's got gnustep-make<=1.26.0 in makedepends right now. Should it be gnustep-base<=1.26.0 or gnustep-make<=2.7.0 actually?

And btw it doesn't build with GCC 10 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=957826

Package updated but will only successfully compile with gnustep-base 1.26.0 for the moment. Busy with a patch to make it work with gnustep-base 1.27.0

Hi all,

I am busy working on version 4.3.2, busy attending to some compiling issues.

Yes, you'll have to rebuild SOPE and SOGo against the new version.

This package breaks reading emails on webmail on upgrade to GNUStep 1.26. I downgraded to gnustep-base-1.25.1-4 to fix.

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.

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.

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

Hi DJ_L,

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

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

https://github.com/inverse-inc/sogo/commit/5a48fca43dc387033f53f6f99ac045eae1cf9604#diff-3d19a9a222e32bc7b14dd7be7cb5751b

to fix the following bug "S/MIME emails are rendered blank when using GnuTLS" https://sogo.nu/bugs/view.php?id=4433

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.

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

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.

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.

FYI: https://sogo.nu/bugs/view.php?id=4566

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).

Hi DJ_L and chetwisniewski,

I am using openssl-1.1.1-1, here is the error messages that I am getting.

sogod[29991]: Error (objc-load):/usr/lib/GNUstep/SOGo/MailPartViewers.SOGo/MailPartViewers: undefined symbol: SSL_load_error_strings

sogod[29991]: Oct 05 08:16:29 sogod [29991]: [so-product-registry] could not load product: MailPartViewers

sogod[29991]: Error (objc-load):/usr/lib/GNUstep/SOGo/MailerUI.SOGo/MailerUI: undefined symbol: __objc_class_name_UIxMailSizeFormatter

sogod[29991]: Oct 05 08:16:29 sogod [29991]: [so-product-registry] could not load product: MailerUI

It does appear that it is something with ssl that is causing the issue but I cant find what it is.

OpenSSL-1.1.1?

I am getting the same error. It appears related to SSL in some way:

sogod[1194]: Error (objc-load):/usr/lib/GNUstep/SOGo/MailPartViewers.SOGo/MailPartViewers: undefined symbol: SSL_load_error_strings

Also using LDAP auth, but I think that is a red herring.

Downgrading to 4.0.1 fixed me as well, but I also downgraded sope out of caution.

Also, if still happening, what happens with version mismatch? SOPE-4.0.2 with SOGo-4.0.1? Another, any customizations for WebUI?

Yes, https://wiki.archlinux.org/index.php/SOGo#Active_Directory_4 Is it working for you now?

I have updated package to 4.0.2

DJ_L that report that you found is the exact problem that I am having, thanks for sharing. Are you using LDAP for your authentication?

FYI, the most recent instance I can find is this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906271

I built with existing patches, updated only version, release, and sha256sums. I am not seeing the problem. I had not been using the web GUI and hadn't yet run the update script /usr/lib/sogo/scripts/sql-update-3.2.10_to_4.0.0-mysql.sh, so I was getting the scrolling quick_update for the contacts list. Ran that script, and all was well with contacts view. My environment is per the current Arch wiki article, with Samba, MariaDB, Postfix, Dovecot, and Apache for the web server.

Where does the error occur, on the login screen, immediately after (MailerUI), or somewhere else?

Try and see if anything interesting in say 'journalctl -r -u sogo | head -n 100 | grep "ERROR" '

Hi DJ_L

This is the current error that I am trying to track down.

An error occurred during object publishing the requested object could not be found!

If I downgrade back to 4.0.1 then everything works as expected.

What kind of issues are you running into? I currently have a pending release for Saturday and my outstanding blockers will be done in about 10 minutes. Barring any major issues, I should have a few days available for Arch (CDT) if there is anything I can do to assist.

Hi all,

I am aware sogo 4.0.2 is available, but in my testing I am experiencing problems when upgrading from 4.0.1 to 4.0.2. As soon as I have managed to resolve the problem I will upgrade this package.

The dependency on SOPE should be 'sope>=4.0.1' both to avoid this issue in the future, and just in general. The sogo package holds the dependency, a greater sope version is not very likely to cause an issue, especially since it is very likely that it'll be updated shortly after.

As to yauort, I don't use any of the AUR helpers personally, but can it not catch the error, see that sogo will be later in the queue, then force the installation in that instance? If that can be done, you can even make it record the missing dep and if the dep is not met later by build failure (or any other reason), then roll back the dependent package from cache.

Hi schickel,

The only solution that I have for you at the moment is to first remove sogo then install it again. I am looking into solving this problem when using yaourt.

Hi,

compiling of SOGo failed because of SOPE:

==> Creating package "sope"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: sope 4.0.1-1 (Fri Jul 13 08:47:44 2018)
==> Cleaning up...

==> Continue installing sope ? [Y/n]
==> [v]iew package contents [c]heck package with namcap
==> ---------------------------------------------------
==> Y
loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing sope (4.0.1-1) breaks dependency 'sope=4.0.0' required by sogo
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-mk
cp: overwrite '/tmp/yaourt-tmp-mk/sope-4.0.1-1-x86_64.pkg.tar.xz'?

Added gcc-objc and gnustep-make to makedepends

As well, gnustep-make should be added to both. This was my oversight.

Indeed could you please add gcc-objc to make dependencies ?

3.2.9 came out today.

I'm not in front of an arch machine, but is that not pulled in by gnustep-make?

Also is necessary to install gcc-objc

Updated to 3.2.3. 2x versions in a few.

Most likely your gnustep-make package is slightly misconfigured. An update a few months ago made the configuration file an actual configuration file in the PKGBUILD and likely it didn't get updated. I'm referring to this bug: https://bugs.archlinux.org/task/50135 Just make sure that GNUSTEP_NETWORK_ADMIN_TOOLS=/usr/bin and GNUSTEP_LOCAL_ADMIN_TOOLS=/usr/bin in /etc/GNUstep/GNUstep.conf. Nothing should be referring to /sbin or /usr/sbin (they don't actually exist and dependent packages use these values). I'll be updating this package to 3.2.3 in just a few minutes anyway, but check those values and see if that's the problem.

error: failed to commit transaction (conflicting files) sogo: /usr/sbin exists in filesystem

3.2.0 is out and seems to work. I have it installed, but it is causing SIG11 when switching screens on current Chromium. Still investigating. Holding update until resolved.

Updated to 3.1.5.

mober: at best guess, you need to update gnustep-make to 2.6.8-2 (or presumably -3). EDIT: You probably already did this, but didn't update the config file. There should be an /etc/GNUstep/GNUstep.conf.pacnew file, which needs to replace the /etc/GNUstep/GNUstep.conf (if you've never modified that file). If you have modifications to the GNUstep configuration, change all instances of /usr/sbin to /usr/bin as it was incorrect in versions prior to gnustep-make-2.6.8-2. If this isn't it, I'll try and get a first hand look at it a bit later tonight or tomorrow as 3.1.5 was released today.

error: failed to commit transaction (conflicting files) sogo: /usr/sbin exists in filesystem sogo: /usr/sbin/sogo-ealarms-notify exists in filesystem sogo: /usr/sbin/sogo-slapd-sockd exists in filesystem sogo: /usr/sbin/sogo-tool exists in filesystem sogo: /usr/sbin/sogod exists in filesystem Errors occurred, no packages were upgraded.

GNUStep-Make has been fixed, bumped release to remove unneeded GNUSTEP_SYSTEM_ADMIN_TOOLS parameter.

Looks like this is fixed in gnustep-make-2.6.8-2.

Okay, so gnustep-make-2.6.8-1 is broken. So was gnustep-make-2.6.7-1, but it happened to work with this package. The quick fix is: # sed 's@/usr/sbin@/usr/bin@' -i.bak /usr/GNUstep/GNUstep.conf I've created a bug (with patch) for the package at https://bugs.archlinux.org/task/50135

Well, fakeroot is not the culprit. Looks like gnustep-make had some changes.

inserted test -d $pkgdir/usr/sbin && install -v -d -m 0755 $pkgdir/usr/bin && mv $pkgdir/usr/sbin/* $pkgdir/usr/bin && rmdir $pkgdir/usr/sbin at the end of package() {} section of the pkgbuild as you suggested in your previous post. As a result the binaries are moved in the correct /usr/bin directory. Thanks. Maybe you will be able to reproduce this bug on your host and find a permanent solution.

My hosts were installed both after and before your install date. I noticed I have fakeroot version 1.21-1 installed. Yours is one version behind. Could this be the difference?

Okay, I'll get a new host built tomorrow morning (maybe tonight) and pkgbuild updated to handle this case. Hopefully I'll actually be able to see the issue. I'd still like to figure out why these hosts behave differently. I'm kind of grasping at straws here. Do you happen to know when your testing hosts were brought online? My build host for this package was brought online 20160418. Earliest version of pacman was 5.0-1, fakeroot has only ever been 1.20.2-1. Not really sure what else to look at. I was guessing maybe the pacman-4.2 update, when the symlink handling was changed, but that was back in December 2014 and is unrelated to makepkg. Fakeroot install seems to be the difference (which is default on my system)... [pkguser@server3 sogo]$ makepkg -s ==> Making package: sogo 3.1.4-1 (Fri Jul 22 13:07:19 CDT 2016) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading SOGo-3.1.4.tar.gz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 246 100 246 0 0 867 0 --:--:-- --:--:-- --:--:-- 869 100 265 100 265 0 0 414 0 --:--:-- --:--:-- --:--:-- 414 100 30.7M 100 30.7M 0 0 4527k 0 0:00:06 0:00:06 --:--:-- 6484k -> Found sogo_configure.patch -> Found sogo.service -> Found sogo.confd ==> Validating source files with sha256sums... SOGo-3.1.4.tar.gz ... Passed sogo_configure.patch ... Passed sogo.service ... Passed sogo.confd ... Passed ==> Extracting sources... -> Extracting SOGo-3.1.4.tar.gz with bsdtar ==> Starting prepare()... patching file configure Hunk #1 succeeded at 263 (offset 12 lines). ==> Starting build()... GNUstep environment: system: /usr/System local: /usr/Local user: /home/pkguser/GNUstep path: /usr/System:/usr/Network:/usr/Local:/root/GNUstep flat: yes arch: x86_64-unknown-linux-gnu combo: gnu-gnu-gnu <snip> ==> Tidying install... -> Removing libtool files... -> Purging unwanted files... -> Removing static library files... -> Compressing man and info pages... ==> Checking for packaging issue... ==> Creating package "sogo"... -> Generating .PKGINFO file... -> Generating .BUILDINFO file... -> Adding install file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: sogo 3.1.4-1 (Fri Jul 22 13:09:52 CDT 2016) [pkguser@server3 sogo]$ ls -l pkg/sogo/usr/ total 12 drwxr-xr-x 2 pkguser pkguser 4096 Jul 22 13:09 bin drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:09 include drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:09 lib [pkguser@server3 sogo]$ cd src/SOGo-3.1.4 [pkguser@server3 SOGo-3.1.4]$ make DESTDIR=$PWD/dest install This is gnustep-make 2.6.7. Type 'make print-gnustep-make-help' for help. Making all in SOPE/NGCards ... Making all for library libNGCards... make[4]: Nothing to be done for 'internal-library-compile'. <snip> Making install for tool sogo-slapd-sockd... Installing tool sogo-slapd-sockd... Making install for tool sogo-ealarms-notify... Installing tool sogo-ealarms-notify... Making install in Tests/Unit ... Skipping installation of test tools... [pkguser@server3 SOGo-3.1.4]$ ls -l dest/usr/ total 12 drwxr-xr-x 5 pkguser pkguser 4096 Jul 22 13:13 include drwxr-xr-x 4 pkguser pkguser 4096 Jul 22 13:13 lib drwxr-xr-x 2 pkguser pkguser 4096 Jul 22 13:13 sbin [pkguser@server3 SOGo-3.1.4]$ Sorry so long, but really curious why this works here and not there.

I tried on desktop (x86_64), laptop (x86_64) and odroid C2 (aarch64) with up to date arch linux installations. On all hosts the binaries are going to be installed under /usr/sbin. $ git clone https://aur.archlinux.org/sogo.git $ makepkg -s $ ls -la /home/alarm/aur/sogo/pkg/sogo/usr drwxr-xr-x 5 alarm alarm 4096 Jul 22 19:05 include drwxr-xr-x 5 alarm alarm 4096 Jul 22 19:05 lib drwxr-xr-x 2 alarm alarm 4096 Jul 22 19:05 sbin The symlink "/usr/sbin" is pointing to "bin" (typo in previous post).

[pkguser@server3 usr]$ pacman -Q sogo sogo 3.1.4-1 [pkguser@server3 usr]$ pwd /home/pkguser/AUR/sogo/pkg/sogo/usr [pkguser@server3 usr]$ ls -l total 12 drwxr-xr-x 2 pkguser pkguser 4096 Jul 17 12:17 bin drwxr-xr-x 5 pkguser pkguser 4096 Jul 17 12:17 include drwxr-xr-x 5 pkguser pkguser 4096 Jul 17 12:17 lib Did you use something other than makepkg to build? Did you make any changes other than adding aarch64 to the arch array? A plain 'make DESTDIR=$PWD/dest install' does install those files to ./dest/usr/sbin, while in package(), the symlink is accounted for and the files are correctly installed into $pkgdir/usr/bin. I'm not clear on exactly how this works, I assume some fakeroot magic. While I could work around this, something like 'test -d $pkgdir/usr/sbin && install -vdm755 $pkgdir/usr/bin && mv $pkgdir/usr/sbin/* $pkgdir/usr/bin && rmdir $pkgdir/usr/sbin' at the end of the package function, it shouldn't be necessary. Something is working differently on your system vs my build host. You mentioned that /usr/sbin was a link to /bin. I'm not sure if that was just typing fast or if it is broken (or if even related). /usr/sbin should be a symlink to bin (not /bin, nor a hard link - though that would probably work as well if /bin weren't a symlink itself). If your original message was not a typo, then that might an issue, I don't know. Anyway, the string of commands above will work around it, but I'm not sure that it is appropriate to work around it. As to where this is defined in the build machinery, it's not quite that simple. This is defined in GNUStep's environment. That said, there is a makefile that specifies FHS layout and moves these to the sbin directory in the install prefix. I'll try the build on a fresh host this weekend and see if something has changed since my build host was brought up, but I suspect not.

Package 3.1.4 does not install. Tried 'x86_64' and new 'aarch64' architecture. $ sudo pacman -U sogo-3.1.4-1-aarch64.pkg.tar.xz debug: checking possible conflict: /usr/sbin/ debug: found file conflict /usr/sbin, packages sogo and (filesystem) debug: returning error 49 from _alpm_sync_check : conflicting files error: failed to commit transaction (conflicting files) sogo: /usr/sbin exists in filesystem Errors occurred, no packages were upgraded. /usr/sbin is a link to /bin and is therefore treated as a file rather than a directory. I extracted the package and files sogo-ealarms-notify, sogo-slapd-sockd, sogo-tool and sogod want to be installed in /usr/sbin rather than in /usr/bin. In which file is specified where the binaries are going to be installed?

Updated to 3.1.2. Angular was updated again (rc5), clear browser cache as usual.

Updated to 3.1.0. FYI, AngularJS was updated to 1.1.0rc4 in this release. Make sure that you clear browser cache if you experience any anomalies in the web interface.

Note that SOGo-2.x development continues and new package sogo2 is in AUR.