Bug 227579 - [NEW PORT] www/sogo4 : new major version branch of www/sogo[2,3]
Summary: [NEW PORT] www/sogo4 : new major version branch of www/sogo[2,3]
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Walter Schwarzenfeld
URL: https://reviews.freebsd.org/D15148
Depends on: 227578
Blocks: 227580
  Show dependency treegraph
Reported: 2018-04-17 10:44 UTC by Euan Thoms
Modified: 2019-08-14 15:27 UTC (History)
5 users (show)

See Also:
euan: maintainer-feedback+

New port via svn diff patch (167.10 KB, patch)
2018-04-17 10:44 UTC, Euan Thoms
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Euan Thoms 2018-04-17 10:44:58 UTC
Created attachment 192589 [details]
New port via svn diff patch

There is a new major version branch of SOGo (Groupware / webmail). It's a natural evolutionary progression of www/sogo3 and is compatible with earlier versions (including www/sogo2). In fact, they can co-exist (on seperate jails for example). The older v2 and v3 branches become legacy and continue to get maintenance versions.


DEVELOPER=yes make                      : PASS
portlint -AC                            : PASS
make check-plist (default options)      : PASS
make check-plist (all options disabled) : PASS
make check-plist (all options enabled)  : PASS
poudriere build                         : PASS

Production testing:

Been running in production on one server for 10 mins minimal basic testing. It all looks good so far.
Comment 1 Euan Thoms 2018-04-17 10:55:57 UTC
I forgot to mention, please give credit to Martin, whom emailed me the new port shar. I just checked it and made small fixes to pass portlint etc.

The commit should mention:

Submitted by:	Martin Waschbusch <martin waschbuesch de>
Approved by:	Euan Thoms <euan potensol com> (maintainer)
Comment 2 Baptiste Daroussin freebsd_committer 2018-04-24 09:39:54 UTC
it fails on me (freebsd 11.1):

The previous version did the same: dying at logon with SIGABRT

The main difference is the previous version worked when built with DEBUG option, this version dies even with DEBUG option
I'm CCing David as this happens since the last update of GNUStep and he followed on mailing lists for previous version

* thread #1, name = 'sogod', stop reason = signal SIGABRT
    frame #0: 0x000000080606b71a libc.so.7`kill + 10
    frame #1: 0x000000080606b6d0 libc.so.7`___lldb_unnamed_symbol842$$libc.so.7 + 144
    frame #2: 0x000000080606b640 libc.so.7`__stack_chk_fail + 16
    frame #3: 0x000000080159f347 libSOGo.so.4`___lldb_unnamed_symbol1119$$libSOGo.so.4 + 375
    frame #4: 0x000000080159e93e libSOGo.so.4`___lldb_unnamed_symbol1109$$libSOGo.so.4 + 158
    frame #5: 0x0000000801595b0e libSOGo.so.4`___lldb_unnamed_symbol944$$libSOGo.so.4 + 990
    frame #6: 0x000000080158bee3 libSOGo.so.4`___lldb_unnamed_symbol849$$libSOGo.so.4 + 179
    frame #7: 0x000000080158c41b libSOGo.so.4`___lldb_unnamed_symbol851$$libSOGo.so.4 + 1051
    frame #8: 0x00000008106b4022 MainUI`___lldb_unnamed_symbol11$$MainUI + 386
    frame #9: libNGObjWeb.so.4.9`-[SoActionInvocation callOnObject:withPositionalParametersWhenNotNil:inContext:](self=0x000000080d9f2750, _cmd=<unavailable>, _client=<unavailable>, _positionalArgs=0x0000000000000000, _ctx=0x000000080c019210) at SoActionInvocation.m:300
  * frame #10: libNGObjWeb.so.4.9`-[SoObjectMethodDispatcher dispatchInContext:](self=0x00000008121f0870, _cmd=<unavailable>, _ctx=0x000000080c019210) at SoObjectMethodDispatcher.m:191
    frame #11: libNGObjWeb.so.4.9`-[SoObjectRequestHandler handleRequest:inContext:session:application:](self=0x000000080da91550, _cmd=<unavailable>, _rq=<unavailable>, _ctx=0x000000080c019210, _sn=<unavailable>, app=<unavailable>) at SoObjectRequestHandler.m:584
    frame #12: libNGObjWeb.so.4.9`-[WORequestHandler handleRequest:](self=0x000000080da91550, _cmd=<unavailable>, _request=0x000000080d98b610) at WORequestHandler.m:237
    frame #13: libNGObjWeb.so.4.9`-[WOCoreApplication dispatchRequest:usingHandler:](self=0x000000080c2d9c10, _cmd=<unavailable>, _request=0x000000080d98b610, handler=0x000000080da91550) at WOCoreApplication.m:712
    frame #14: sogod`-[SOGo dispatchRequest:](self=0x000000080c2d9c10, _cmd=<unavailable>, _request=<unavailable>) at SOGo.m:576
    frame #15: libNGObjWeb.so.4.9`-[WOHttpTransaction _run](self=0x000000080d8a5390, _cmd=<unavailable>) at WOHttpTransaction.m:566
    frame #16: libNGObjWeb.so.4.9`-[WOHttpTransaction run](self=0x000000080d8a5390, _cmd=<unavailable>) at WOHttpTransaction.m:619
    frame #17: libNGObjWeb.so.4.9`-[WOHttpAdaptor runConnection:](self=0x000000080c309b60, _cmd=<unavailable>, _socket=<unavailable>) at WOHttpAdaptor.m:373
    frame #18: libNGObjWeb.so.4.9`-[WOHttpAdaptor _handleAcceptedConnection:](self=0x000000080c309b60, _cmd=<unavailable>, _connection=<unavailable>) at WOHttpAdaptor.m:407
    frame #19: libNGObjWeb.so.4.9`-[WOHttpAdaptor _handleConnection:](self=0x000000080c309b60, _cmd=<unavailable>, connection=0x000000080c309bd0) at WOHttpAdaptor.m:466
    frame #20: libNGObjWeb.so.4.9`-[WOHttpAdaptor acceptControlMessage:](self=0x000000080c309b60, _cmd=<unavailable>, aNotification=<unavailable>) at WOHttpAdaptor.m:505
    frame #21: 0x0000000805398e6e libgnustep-base.so.1.25`_i_NSNotificationCenter___postAndRelease_ + 1102
    frame #22: 0x00000008054793f9 libgnustep-base.so.1.25`_i_GSRunLoopCtxt__pollUntil_within_ + 4409
    frame #23: 0x00000008053d246e libgnustep-base.so.1.25`_i_NSRunLoop__acceptInputForMode_beforeDate_ + 654
    frame #24: 0x00000008053d28c2 libgnustep-base.so.1.25`_i_NSRunLoop__runMode_beforeDate_ + 354
    frame #25: libNGObjWeb.so.4.9`-[WOCoreApplication run](self=0x000000080c2d9c10, _cmd=<unavailable>) at WOCoreApplication.m:584
    frame #26: libNGObjWeb.so.4.9`-[WOWatchDog _spawnChild:](self=0x000000080c07f690, _cmd=<unavailable>, child=0x000000080dac4010) at WOWatchDogApplicationMain.m:600
    frame #27: libNGObjWeb.so.4.9`-[WOWatchDog _ensureChildren](self=<unavailable>, _cmd=<unavailable>) at WOWatchDogApplicationMain.m:690
    frame #28: libNGObjWeb.so.4.9`-[WOWatchDog run:argc:argv:](self=0x000000080c07f690, _cmd=<unavailable>, newAppName=<unavailable>, newArgC=1, newArgV=<unavailable>) at WOWatchDogApplicationMain.m:942
    frame #29: libNGObjWeb.so.4.9`WOWatchDogApplicationMain(appName=0x000000000123e9f0, argc=1, argv=0x00007fffffffe8b0) at WOWatchDogApplicationMain.m:1051
    frame #30: sogod`main(argc=1, argv=0x00007fffffffe8b0, env=<unavailable>) at sogod.m:51
    frame #31: 0x00000000010357d0 sogod`_start + 384
Comment 3 Euan Thoms 2018-05-02 19:13:28 UTC
(In reply to Baptiste Daroussin from comment #2)

Ah, I was building it on 10.4 systems. I'll try it out on 11.1 when I get some time and report back.
Comment 4 Kurt Jaeger freebsd_committer 2018-05-13 15:35:24 UTC
See also:

Comment 5 Kurt Jaeger freebsd_committer 2018-05-13 16:45:21 UTC
testbuilds of this version are fine. TODO: compare with D15148
Comment 6 Jose Alonso Cardenas Marquez freebsd_committer 2018-06-03 06:03:16 UTC
I abandoned https://reviews.freebsd.org/D15148 because the best is add sogo4-activesync like subpackage. I pass maintainership of this port to me (no answer from maintainer 21 days about)
Comment 7 Euan Thoms 2018-06-11 15:09:23 UTC
(In reply to Jose Alonso Cardenas Marquez from comment #6)

I finally found some time to work on these ports again after being very at my day job for a few weeks now. Whilst I'm glad it's made it's way into the ports tree, I am dissapointed it wasn't pointed out to me that it was actually working. Especially after being told that it was not working.

I still feel I am the best person to be maintainer of the sogo ports aince I created them originally and I use them in production for 4 domains/sites and 3 companies of which I am the supervising sysadmin.
Comment 8 Baptiste Daroussin freebsd_committer 2018-06-12 08:33:15 UTC
I confirm what has been commited is broken and does not work.
Note that resetting maintainership after a single timeout is hard, the rules, specify this should happen after multiple timeouts

I reopen that bugs, because sogo4 is now broken in production
Comment 9 Baptiste Daroussin freebsd_committer 2018-06-12 08:44:14 UTC
Looking at sogo3 history, I can see multiple timeouts happened in the past about updates.
Comment 10 Jose Alonso Cardenas Marquez freebsd_committer 2018-07-19 16:33:42 UTC
I have tested sogo3 and sogo4 (latest versions) from packages on 11.2-amd64 and it works without problems. bapt, could you confirm it? maybe we can close this PR
Comment 11 Baptiste Daroussin freebsd_committer 2018-07-19 16:40:47 UTC
on 11.2-RELEASE amd64, installed only from packages, I can confirm I still have the same problem with sogo 4.0.1
Comment 12 Baptiste Daroussin freebsd_committer 2018-07-19 16:41:03 UTC
same trace
Comment 13 Jose Alonso Cardenas Marquez freebsd_committer 2018-07-25 18:25:27 UTC
bapt, what is your environment where you are using SOGo? For example mine is the following:

- SOGo 3.x and 4.x (with/without ActiveSync)
- Postfix
- Dovecot
- Authentication to OpenLDAP
- PostgreSQL (users profile)
- nginx (web access)
- memcached

it crashed when you tried login via web or activesync? did you see anything into /var/log/sogo/sogo.log? could you show us your sogo.conf file?
Comment 14 Baptiste Daroussin freebsd_committer 2018-07-26 05:55:38 UTC
It crashes on login on web AND on activesync
The is a message in /var/log/messages about SIGABRT

It all started after updates of gnustep itself (imho showing an existing bug). I bugged theraven@ about it at the time.

I have done some debugging since sogo4 to get the stacktrace on top of this bug.
Comment 15 Baptiste Daroussin freebsd_committer 2018-07-26 07:36:44 UTC
I forgot to mention the authentication for me is on imap (dovecot)
Comment 16 Walter Schwarzenfeld freebsd_triage 2019-08-14 15:27:25 UTC
Port already exists:

PORTNAME=               sogo4
PORTVERSION=            4.0.8