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
Been running in production on one server for 10 mins minimal basic testing. It all looks good so far.
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)
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
(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.
testbuilds of this version are fine. TODO: compare with D15148
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)
(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.
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
Looking at sogo3 history, I can see multiple timeouts happened in the past about updates.
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
on 11.2-RELEASE amd64, installed only from packages, I can confirm I still have the same problem with sogo 4.0.1
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)
- Authentication to OpenLDAP
- PostgreSQL (users profile)
- nginx (web access)
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?
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.
I forgot to mention the authentication for me is on imap (dovecot)