Hello! Please find attached citadel-6.25.ebuild. This is an updated package. I suggest net-mail/citadel. Citadel requires db-4.1.25_p1 or greater and libical-0.24_rc4; other dependencies are optional and will be installed based on USE flags. icc support is disabled right now because it doesn't work unless pam is also compiled with icc, and it usually isn't. Citadel is known to work on x86, ppc and sparc systems. It remains untested on hppa, but at last check it did not work due to threading problems and none of us have an HP box to test on anymore. Citadel is a powerful Internet e-mail and collaboration server. It contains many modern features such as: * Built-in SMTP, POP, and IMAP services * Database-driven, single-instance message store * Authenticated SMTP (no more tedious mucking about with POP-before-SMTP hacks!) * Multiple domain support * Global address book -- users in a single domain can be spread out over multiple Citadel servers * Group calendaring and scheduling * Web-based access to email * Very strong support for "public folders" * Built-in instant messaging Reproducible: Always Steps to Reproduce:
Created attachment 38443 [details] citadel-6.25.ebuild
Hi ! I'm interested in getting this into portage. But I'd like to know if latest versions of citadel can be installed under /usr hierarchy since no ebuild should install anything on /usr/local Cheers, Ferdy
*** Bug 49062 has been marked as a duplicate of this bug. ***
Created attachment 76136 [details] Citadel 6.63 split into a more Unix-style file structure This ebuild is based on the 6.25 ebuild found here. It's been updated to 6.63. It also uses the new make install-new that allows a more Unix-style file layout. However, there are still a few minor problems. Citadel still looks for it's exacutionables in --prefix. --prefix is also used by the setup program to determine the default home directory. I set --prefix to /usr/sbin so that citadel can find it's exacutionables. However, this breaks setup -q as I've also set Citadel's home to /var/lib/citadel and, because --prefix is set to /usr/sbin, setup defaults to the wrong directory. As long as setup is run manually and a home directory of /var/lib/citadel is supplied, everything works fine. I've also made some other changes. First, I'd suggest mail-mta for this ebuild. The new make install-new overwrites /usr/sbin/sendmail. I've added mailwrapper support but haven't tested it. I'm also changing /usr/sbin/sendmail to be a sym-link to /usr/sbin/citmail. citmail and sendmail are identical. I didn't see the point of duplication. Besides, making it a sym-link makes mailwrapper support possible. I also changed the name of the setup program to citsetup. I didn't like the idea of a package installing a program genericly named setup into /usr/sbin. I went ahead and copied the included schema file (with ldap use flag) to /etc/openldap/schema. However, at first glance, it doesn't contain anything that's not already included with openldap. It doesn't seem necessary, but I haven't tried using ldap yet. I think that about covers the changes. I'll try working on WebCit next as my main interest at this point is groupware and WebCit is needed for GroupDAV. Besides, the WebCit screenshots look nice. One thought I had was to include WebCit with the Citadel ebuild. I'm not really sure why they are seperate. However, one thing at a time... First I'll build it as a seperate ebuild.
Created attachment 80177 [details] Citadel 6.70 mail-mta ebuild
Created attachment 80178 [details] Citadel 6.70 net-mail ebuild
Created attachment 80179 [details] Citadel 6.70 text client ebuild. Goes in net-mail
Long night, but I think I have it... These are for Citadel 6.70. Citadel is capable of running along-side another MTA. So I've created two citadel-6.70.ebuild files. If you want to run Citadel as your MTA, "emerge mail-mta/citadel". If you want to run something else as your MTA, "emerge net-mail/citadel". Citadel also gives you a choice of clients. If you prefer a text interface, "emerge net-mail/citadel-client". If you prefer a web-based client, see bug #123139 and "emerge www-apps/webcit" The two server ebuilds are exclusive of each other. However, both clients can coexist. That said, there are still some path related bugs in 6.70. The ebuild works around a few of them. I had to SetUID citmail because it wants to create a temp file in /usr/sbin. Citsetup still wants to use /usr/sbin as the home default. I went around that using environmental variables. There is a major path bug I didn't get fixed. /etc/citadel/mail.aliases and /etc/citadel/public_clients are both ignored. I'm told this is fixed in 6.72. I'll update the ebuilds to that version just as soon as a tarball is available. It's currently in cvs (svn). As to some of my last notes... I still haven't tested newt. I did add it as a use flag. The programs can be built with ncurses or without. I'm not sure if they can be built with both ncurses and newt. I also haven't tested ldap. I did look at the included schema file. It's a combination of core.schema and kolab.schema. As I would prefer them separate, I'm thinking of adding the kolab.schema file to the ebuild. Have a good night, or morning...
Created attachment 85515 [details] Update to 6.81 This is the update to 6.81. I've removed the net-mail server build. With mailwrapper support, a separate non-mta ebuild is not needed. I've also removed newt and ncurses from the server build. Searching through the source shows that newt is only used in the setup program (which we handle in emerge --config. ncurses is only used in the client program. I added several .keepdir directives to make upgrading smoother. I've also added /var/lib/citadel to CONFIG_PROTECT to protect any modifications to the message files. This update has plenty of bug fixes and changes. Make sure to read the change log, and enjoy!
Created attachment 85516 [details] CLI for Citadel. Update to 6.81 version bump
Created attachment 93249 [details] Citadel 6.82 mail-mta ebuild Version update to Citadel 6.82. I've also fixed mailwrapper support. It works well with mailwrapper-0.2.1-r1 and eselect mailer. As a side note, The sendmail (citmail) included is very simplistic. It ignores the To: and From: in data sent to it. Instead, it uses getuid() to set From and takes an argument for To. This breaks mail support in a few programs (vixie-cron and hylafax). Emerging ssmtp along side citadel (with mailwrapper set in USE) fixes this problem. However, if you use emerge --config to configure citadel, don't forget to enable your mail ports. They are disabled by default if mailwrapper is set.
Created attachment 93250 [details] mailwrapper config file. Place in mail-mta/citadel/files
Created attachment 93251 [details] citadel-client version bump
The latest version is 7.24. Is any work on it?..
Reassigning
Any chance this can be bumped and pushed to portage? Probably the best free "groupware" solution out there!
Probably, but it's in need of a maintainer. I haven't had time to maintain this for quite a while, but I'll see if I can update it this weekend if I get some time off from shopping.
version bump to recent 7.63! Updated and refurbished ebuild for citadel. Whats working: The whole citadel stuff as standalone mailer and everything it should do. What needs love: mailwrapper stuff in order to install along with other mta. A tarball with all needed packages and a howto is provided on Citadel's homepage: http://www.citadel.org/doku.php/installation:ebuild (Dropped the citadel-client.ebuild approach, because I am not entirely sure how to handle the bureaucracy: which category for the server? two ebuilds for client and server? ...)
Created attachment 205163 [details] Citadel mail-mta 7.63 ebuild (cli client gets build, too)
Created attachment 205165 [details] Init script for recent versions (>=7.63) (goes into /files)
Created attachment 205167 [details] conf.d file for citadel (>=7.64) (goes into /files)
depends on dev-libs/libcitadel-7.63: http://bugs.gentoo.org/show_bug.cgi?id=286323
Created attachment 206038 [details] version bumped and vastly improved ebuild for version 7.66 Heavily reworked ebuild, should now work with mailwrapper. This ebuild now is in sunrise overlay, too.
missed the review by a few minutes, heres the link to unreviewd sunrise: https://overlays.gentoo.org/proj/sunrise/browser/sunrise/mail-mta/citadel
Hi there. I would like to install Citadel along side a existing postfix+courier-imap installation on my server. However, trying to emerge citadel results in blocked packages since citadel provides virtual/mta. As far as I know, citadel has the builtin capability of being installed alongside an existing mailserver setup. Is there any reason the ebuild HAS to block postfix, or is there a workaround?
(In reply to comment #25) > Hi there. > I would like to install Citadel along side a existing postfix+courier-imap > installation on my server. However, trying to emerge citadel results in blocked > packages since citadel provides virtual/mta. This was totally possible when gentoo/postfix was mailwrapper aware. You might look into the postfix ebuild, last time i checked, all the mailwrapper stuff was still there, but commented out. This method is no longer supported by gentoo (and has newer been propperly, for that matter.) That's why there is a mailwrapper flag for citadel. But read on below. > As far as I know, citadel has the builtin capability of being installed > alongside an existing mailserver setup. Is there any reason the ebuild HAS to > block postfix, or is there a workaround? > Yes, it has. (although this is complecated, too, i guess. There is no setup option for this, afaik. If there is i will include it in postinstall setup.) Most probably you will need to start citadel first and disable listening on port 25 from webcit or commandline client, only after that you will be able to start postfix on that port. The reason why the blockage occurs is, that I was too lazy to drop mailwrapper useflag and come up with a correct solution, sorry. But i am planning it for 7.85 release, which is going to come soon. Plan goes like this: Drop "mailwrapper" flag from ebuild (though i really would love to have an eselect mailer approach), maybe make postfix dependency (although this is ugly, since it is not a compile/runtime dep and would trigger nonsensical rebuilding of citadel when flag changes), take care of whatever there is to do at install time and put up information in einfo. Since i am not sure if I will use such a setup myself, I'd love delegating the guinea pig phase to somebody who does really use it. Would you care to join #citadel on freenode for faster communications so we can try to solve this together?
(In reply to comment #26) > (In reply to comment #25) > > Hi there. > > I would like to install Citadel along side a existing postfix+courier-imap > > installation on my server. However, trying to emerge citadel results in blocked > > packages since citadel provides virtual/mta. > This was totally possible when gentoo/postfix was mailwrapper aware. You might > look into the postfix ebuild, last time i checked, all the mailwrapper stuff > was still there, but commented out. This method is no longer supported by > gentoo (and has newer been propperly, for that matter.) That's why there is a > mailwrapper flag for citadel. But read on below. > > > As far as I know, citadel has the builtin capability of being installed > > alongside an existing mailserver setup. Is there any reason the ebuild HAS to > > block postfix, or is there a workaround? > > > Yes, it has. (although this is complecated, too, i guess. There is no setup > option for this, afaik. If there is i will include it in postinstall setup.) > Most probably you will need to start citadel first and disable listening on > port 25 from webcit or commandline client, only after that you will be able to > start postfix on that port. > > The reason why the blockage occurs is, that I was too lazy to drop mailwrapper > useflag and come up with a correct solution, sorry. But i am planning it for > 7.85 release, which is going to come soon. > > Plan goes like this: Drop "mailwrapper" flag from ebuild (though i really would > love to have an eselect mailer approach), maybe make postfix dependency > (although this is ugly, since it is not a compile/runtime dep and would trigger > nonsensical rebuilding of citadel when flag changes), take care of whatever > there is to do at install time and put up information in einfo. > > Since i am not sure if I will use such a setup myself, I'd love delegating the > guinea pig phase to somebody who does really use it. Would you care to join > #citadel on freenode for faster communications so we can try to solve this > together? > (In reply to comment #26) > (In reply to comment #25) > > Hi there. > > I would like to install Citadel along side a existing postfix+courier-imap > > installation on my server. However, trying to emerge citadel results in blocked > > packages since citadel provides virtual/mta. > This was totally possible when gentoo/postfix was mailwrapper aware. You might > look into the postfix ebuild, last time i checked, all the mailwrapper stuff > was still there, but commented out. This method is no longer supported by > gentoo (and has newer been propperly, for that matter.) That's why there is a > mailwrapper flag for citadel. But read on below. > > > As far as I know, citadel has the builtin capability of being installed > > alongside an existing mailserver setup. Is there any reason the ebuild HAS to > > block postfix, or is there a workaround? > > > Yes, it has. (although this is complecated, too, i guess. There is no setup > option for this, afaik. If there is i will include it in postinstall setup.) > Most probably you will need to start citadel first and disable listening on > port 25 from webcit or commandline client, only after that you will be able to > start postfix on that port. > > The reason why the blockage occurs is, that I was too lazy to drop mailwrapper > useflag and come up with a correct solution, sorry. But i am planning it for > 7.85 release, which is going to come soon. > > Plan goes like this: Drop "mailwrapper" flag from ebuild (though i really would > love to have an eselect mailer approach), maybe make postfix dependency > (although this is ugly, since it is not a compile/runtime dep and would trigger > nonsensical rebuilding of citadel when flag changes), take care of whatever > there is to do at install time and put up information in einfo. > > Since i am not sure if I will use such a setup myself, I'd love delegating the > guinea pig phase to somebody who does really use it. Would you care to join > #citadel on freenode for faster communications so we can try to solve this > together? > I'm jumping in on this, the_mgt will probably know me from Uncensored. I'm definitely planning to use this functionality, and since it's not a critical application, we can play around all we can :P. I will read up on the ebuild later.
Created attachment 261060 [details] Live ebuild for git master of citadel (with new postfix useflag) I version bumped the ebuild in sunrise to 7.85. I also attached my 9999 live ebuild for git master as a reference for the postfix useflag. I will bump the other two bugs with appropriate versions, too. Git master is under heavy work atm and includes lots of changes that will be released with Citadel 8. I finally removed mailwrapper useflag and functionality and introduced a "postfix" useflag. This will allow installation of postfix as mail transfer agent. However, I had to add a useflag-check for PROVIDE="virtual/mta" in order to get the logic straight and I was told that is a bad thing. Currently I see no other easy way to solve this. Please try and use the ebuilds from sunrise and report any issues here.
There is a spelling mistake in libcitadel-7.85.ebuild: replace-flags -03 -02 should be: replace-flags -O3 -O2 Oh's and zeroes :). Citadel is compiling with the postfix useflag as we speak.
(In reply to comment #29) > There is a spelling mistake in libcitadel-7.85.ebuild: > > replace-flags -03 -02 should be: > replace-flags -O3 -O2 > > Oh's and zeroes :). Citadel is compiling with the postfix useflag as we speak. Fixed! Thanks for noticing and reporting (there is a dedicated libcitadel bug btw) All Citadel ebuilds are now bumped to 7.86 in sunrise (trickling down through review) Postfix flag is still the way to go, but we now have new-style virtuals (as in: a dedicated ebuild for virtual/mta) and I need to contact the maintainer of virtual/mta in order to get Citadel listed there. So you might experience some blockage and portage not recognizing citadel as mta (without postfix useflag set, if that flag is set, postfix is mta and all is calm.) Enjoy!
*** Bug 364401 has been marked as a duplicate of this bug. ***
I am trying to emerge citadel and webcit but am getting fetch failed for dev-libs/libcitadel-8.04. I can not find libcitadel-8.04 on the citadel pages and citadels git tag list has no mention for 8.04, closest are 8.03 and 8.05.
I know. I finally commited up to date ebuilds to sunrise over a week ago. Unfortunately, there hasn't been a review in 7 weeks now, so nobody transfered the ebuilds to the publically avaiable, reviewed branch of sunrise.
This is broken beyond repair: CC utillib/citadel_dirs.c Dependencies: x86_64-pc-linux-gnu-gcc -M -I. -I ./include/ | sed -e 's!.o!.o /.o buildinfo!' > buildinfo CC server_main.c Compile: x86_64-pc-linux-gnu-gcc -march=nocona -mno-sse3 -O2 -pipe -Wall -Wcast-qual -Wcast-align -Wstrict-prototypes -Wno-strict-aliasing -D_REENTRANT -pthread -I ./include/ -I. -I ./include/ -DHAVE_CONFIG_H -DDIFF="/usr/bin/diff" -DPATCH="/usr/bin/patch" -c -o buildinfo LDFLAGS: -Wl,-O1 -Wl,--as-needed CC event_client.c CC user_ops.c In file included from server_main.c:56:0: sysdep_decls.h:22:2: error: #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. ^ Makefile:145: recipe for target 'server_main.o' failed make: *** [server_main.o] Error 1 make: *** Waiting for unfinished jobs.... In file included from user_ops.c:49:0: sysdep_decls.h:22:2: error: #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. ^ In file included from context.h:8:0, from citserver.h:14, from event_client.c:50: sysdep_decls.h:22:2: error: #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. #error Citadel requires Berkeley DB v4.1 or newer. Please upgrade. ^ Makefile:145: recipe for target 'user_ops.o' failed make: *** [user_ops.o] Error 1 Makefile:145: recipe for target 'event_client.o' failed make: *** [event_client.o] Error 1 * ERROR: mail-mta/citadel-8.24::sunrise failed (compile phase): * emake failed This is with sys-libs/db:{4.2,4.8,6.0} installed, so it seems to be broken with... every db in portage.
(In reply to Piotr Szymaniak from comment #34) > This is broken beyond repair: > * ERROR: mail-mta/citadel-8.24::sunrise failed (compile phase): > * emake failed > > > This is with sys-libs/db:{4.2,4.8,6.0} installed, so it seems to be broken > with... every db in portage. I am maintaining the ebuild in sunrise and I happened to reinstall my development machine just yesterday, been busy for too long. I immediately installed layman and added the sunrise overlay, compiled citadel-8.14 without any problem. You are reporting an error for 8.24, which is not in sunrise. I agree that the ebuild is not in the best shape and I will update it as soon as possible. I'll bump it to the latest version, too. Still, it is not "broken beyond repair" or rather, it was not before you messed around with it. ;)
(In reply to the_mgt from comment #35) > I agree that the ebuild is not in the best shape and I will update it as > soon as possible. I'll bump it to the latest version, too. Still, it is not > "broken beyond repair" or rather, it was not before you messed around with > it. ;) Well, maybe I was overreacting a bit ;), but I tried the in sunrise version with the same error, so I just bumped it to newer version and got the error again. So now I wonder why it missed those installed dbs...
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
