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. TESTING ======= 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.
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.
See also: https://reviews.freebsd.org/D15148
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
same trace
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?
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)
Port already exists: PORTNAME= sogo4 PORTVERSION= 4.0.8