'Hula is a calendar and mail server. We are focused on building a calendar and mail server that people love to use, instead of broadly trying to build a "groupware server" that managers want to deploy.' Reproducible: Always Steps to Reproduce:
Created attachment 62669 [details] net-mail/hula/hula-<version>.ebuild Origional ebuild: http://www.users.on.net/~flynne/linux/hula/index.pl I'ts only at revision 209 because there are no new tarballs hosted anywhere. If somebody has some space and bandwith available, I can provide new tarballs (current rev: 253) You can also create your own tarball: http://forums.gentoo.org/viewtopic-p-2539637.html
Created attachment 62670 [details, diff] net-mail/hula/files/define_spamassassin.patch Adds extra messages as suggested by http://www.hula-project.org/Setting_Up_SpamAssassin
Created attachment 62671 [details] get_hula.sh Very premature tool to fetch Hula from SVN (subversion) More info: http://forums.gentoo.org/viewtopic-p-2539637.html
Created attachment 62674 [details] net-mail/hula/files/hula Hula init script...
Created attachment 63149 [details] new version: get_hula.sh (now includes all files needed) Created a new version of the bash script. I added command line options and nice looking color thingies... All the files that are needed (init script, patch, ebuild) are included in the script, so you'll only need the script to get started... I also added some error-checking...
Created attachment 63971 [details] net-mail/hula/hula-<version>.ebuild Fixed the missing init script...
I've been maintaining overlay ebuilds for hula for a while now that take care of things like mailwrapper integration. Also since r238 or so SpamAssassin support has been included in hula proper. I will be asking the net-mail herd if I can maintain it once it reaches 1.0. At the moment I don't feal it is stable enough as a package to be included in the tree. As it stands there is no easy way to upgrade as the schema is not versioned yet so schema changes cause breakage. This means that each revision the end user has to jump through hoops the get the new version up and running. As well hula devs are moving toward an mdb-ldap driver for the tree and away from the mdb-file driver. This also compicates upgrades. I'm in close contact with the main Hula devs and hang in #hula often. So unless someone from net-mail tells me I'm daft I think we will wait for things to stabalize a bit before putting this one into the tree.
Thanks for all the work done on here. I used the shell script to install r849 yesterday and it worked fine but didn't install the init script. Also, I noticed that the init script didn't work very well in keeping the daemon up. Starting hulamanager in a screen session works much more reliably with recognition of Ctrl-C as a gradual shutdown shortcut. As a note on the side, I'd be very interested to know how to get hula to work for multiple domains on its own without any other mta/mail server if anyone can shed any light on that as I've already look at the documentation.
With version 928 I had to add a "inherit mono" (I have mono as USE flag) to the ebuild generated via get_hula.sh, as following the suggestion found in http://forums.gentoo.org/viewtopic-t-241921-highlight-root+wapi.html, to get it to compile.
I added the inherit mono part and got hula to compile, but when I try to start it I get: Insufficient privileges; shutting down. Cannot read configuration. Shutting down. Hula messageing libary failed to initialize. Host not configured fo Hula. But when I compile manually from source with ./autogen --enable-prefix=/opt/hula it works... Could this be a problem with the ebuild?
(In reply to comment #10) > I added the inherit mono part and got hula to compile, but when I try to start > it I get: > > Insufficient privileges; shutting down. > Cannot read configuration. Shutting down. > Hula messageing libary failed to initialize. > Host not configured fo Hula. > > > But when I compile manually from source with ./autogen > --enable-prefix=/opt/hula it works... Could this be a problem with the ebuild? It could be a mono problem: when I launch hulamanager, I have two mono processes taking all the cpu: mono --debug /usr/lib/hula/HulaWeb.exe mono --debug /usr/lib/hula/HulaIndexer.exe For the indexer I read that you actullay need mono, but why running in debug? If I kill them hula stays up and continues working normally... >
I experience the same thing, however the indexer in debug doesn't affect much, but HulaWeb does. Maybe --debug should be turned off unless one specifies the debug use flag? Also, the generated ebuilds from the script must inherit the mono-eclass to prevent sandbox violations. Also, it should use https:// instead of svn+ssh:// according to the #hula@irc.gimp.org topic.
Daniel are you still planning add this ? Where do you have your ebuilds to test ?
There are current hula ebuilds in the breakmygentoo overlay.
Official tars are at: http://live.hula-project.org:8080/tarballs/ The ebuild should work for all tarballs just by version bumping. The tarballs are generated by hulas live-testing system. It generates suse rpms from the same revision and installs them (every night I think), and then starts them, so they should work to at least some degree at all times.
Upstream seems to have vanished, closing therefore.
