I have used davmail for some months now to access our companies Exchange server via Thunderbird and successfully switched to kontact. From the DavMail Website: DavMail is a POP/IMAP/SMTP/Caldav/Carddav/LDAP exchange gateway allowing users to use any mail/calendar client (e.g. Thunderbird with Lightning or Apple iCal) with an Exchange server, even from the internet or behind a firewall through Outlook Web Access. DavMail now includes an LDAP gateway to Exchange global address book and user personal contacts to allow recipient address completion in mail compose window and full calendar support with attendees free/busy display.
Created attachment 259604 [details] davmail-3.8.7_p1558.ebuild This is the ebuild from http://forums.gentoo.org/viewtopic-t-789777.html It works perfectly well on amd64 and is in use on my companies laptop for over a month now.
Created attachment 259606 [details] davmail-3.8.8_p1608.ebuild new Version, released yesterday The new version was released yesterday, here is the ebuild for it. A Changelog can be found in the news here: http://sourceforge.net/news/?group_id=184600
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Dane [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
works fine here as well, both on x86 and amd64
Created attachment 261897 [details] davmail icon file First of all, thank you for ebuild. I've intalled the davmail-3.8.8_p1608. On x86 it works fine. How (and with whom) I can speak about optimization of ebuild? I disagree with the necessety of creation of the davmail invocation menu item: domenu "${FILESDIR}/davmail.desktop" It just overloads "Application" menu with practically useless item (davmail manually is started manually: it could be done from terminal emulator or run app DE launcher, later it's invoked by [for example] DEs autostart subsystem). Currently I'm writing the article in ru.gentoo-wiki.com http://ru.gentoo-wiki.com/wiki/Linux_workstation_%D0%B8_Microsoft_Exchange_server If anybody is interested in placing similiar article in English section of wiki --- welcome, I'll help to translate it.
(In reply to comment #5) > Created an attachment (id=261897) [details] > davmail icon file > > First of all, thank you for ebuild. > > I've intalled the davmail-3.8.8_p1608. On x86 it works fine. > How (and with whom) I can speak about optimization of ebuild? > Hello Sergey, thanks alot for your feedback! I have taken the ebuild from the quoted forums thread and didn't do anything to it. So I am not the original author. But as I have opened this bug, I would surely like to improve the quality of the ebuild. > I disagree with the necessety of creation of the davmail invocation menu item: > domenu "${FILESDIR}/davmail.desktop" > It just overloads "Application" menu with practically useless item (davmail > manually is started manually: it could be done from terminal emulator or run > app DE launcher, later it's invoked by [for example] DEs autostart subsystem). Well, I am actually using this launcher. As this is a laptop I am using, I do not need davmail anywhere but in the office, so I do not start it when I am off work. How about making the starter optional? > > Currently I'm writing the article in ru.gentoo-wiki.com > http://ru.gentoo-wiki.com/wiki/Linux_workstation_%D0%B8_Microsoft_Exchange_server > If anybody is interested in placing similiar article in English section of wiki > --- welcome, I'll help to translate it. > I am afraid I would be the wrong person as I do not have the time to do it. :-(
(In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=261897) [details] [details] > > davmail icon file Could you please change the Mime-Type from text/plain to image/png ?
Created attachment 262007 [details] Desktop file for DavMail This is the desktop file in question, used by the ebuilds
Created attachment 262009 [details] DavMail Icon File (with correct Mime-Type) The desktop icon now with correct Mime-Type
Created attachment 263611 [details] Version bump to 3.9.0; relying on system packages if possible This ebuild updates to 3.9.0 as released recently. The major improvement is that it forces DavMail to use Gentoo's on Java packages if available and only keeps those .jar files which are not available with Gentoo. Reduces size of package and allows distribution updates on dependencies.
(In reply to comment #10) > Created an attachment (id=263611) [details] > Version bump to 3.9.0; relying on system packages if possible > > This ebuild updates to 3.9.0 as released recently. The major improvement is > that it forces DavMail to use Gentoo's on Java packages if available and only > keeps those .jar files which are not available with Gentoo. > Reduces size of package and allows distribution updates on dependencies. > Wow, that's great! ...although I first wasn't too happy with 5 new packages to be installed as dependencies. Well, it *is* a lot more "gentoo" this way, isn't it? ;)
Created attachment 263885 [details] Bundled version, fixing the not-working-dependency reported below Sorry, but there is something completely broken with one of the dependencies. I can not say which dep it is (*), but after upgrading using the new "unbundled" ebuild, nothing worked any more. ((*) But I'll give it a try below) First, whenever I wanted to check one of my calendars, I got the message from kontact, that the server reply was empty. Next my LDap Adress book stopped to work. Finally the exchange Mail stopped working stating wrong Username and/or Password. I removed the following packages, and re-installed from the attached ebuild (which is simply a renamed version of the previous "bundled" one). And now everything is working normally again. One of the deps seems like having the wrong version. But as I am no java expert, I have no idea how to find out which. :-( Sorry! Removed Packages: === dev-java/commons-collections-3.2.1 : === I have no idea, what this is. === dev-java/jcifs-1.3.13 : === I did not expect davmail to use smb for the connection, everything is done via http (As I do not need the EWS method) so this should be perfectly save unless this is used for the server identification and validation. (See notes below log snippet) === dev-java/slf4j-api-1.5.11 : === No, certainly not the culprit as the logging looked fine. === dev-java/stax-1.2.0 : === But this might be the cause. The XML snippets in my logs looked weird, and as there's everything XML, the message "Empty response" could point towards bad parsing? However, it is a riddle to me. In the log file the program seems to check the server, and then stops after getting this reply: 2011-02-26 08:34:28,899 DEBUG [CaldavConnection-60983] davmail.caldav.CaldavConnection - < <?xml version="1.0" encoding="utf-8" ?><C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav"> <D:prop xmlns:D="DAV:"> <C:calendar-data/> </D:prop> <C:filter> <C:comp-filter name="VCALENDAR"> <C:comp-filter name="VEVENT"> <C:time-range start="20101128T000000Z" end="20110527T000000Z"/> </C:comp-filter> </C:comp-filter> </C:filter></C:calendar-query> In the working version, the log continues with the identification of the server being the right one (known hash) and a long log where it downloads the specific calendar. However, this is just a shot in the dark as I am completely at sea here. :-(
Created attachment 264249 [details] desktop file for davmail (davmail moved from Office to Network)
Created attachment 264251 [details] minor fixes to ebuild of davmail-3.9.0 Thank you. Fixes: 1. Fetch + restrict mirror. Because until DavMail isn't included to official portage tree it willn't be present on official distfiles mirrors. 2. Menu item is created not always (to my mind for such application it's uselessly), but depending on use flag.
Created attachment 266987 [details] davmail-3.9.1 ebuild
(In reply to comment #15) > Created attachment 266987 [details] > davmail-3.9.1 ebuild Works perfectly well, thank you!
(In reply to comment #14) > Created attachment 264251 [details] > minor fixes to ebuild of davmail-3.9.0 > > Thank you. > > Fixes: > 1. Fetch + restrict mirror. > Because until DavMail isn't included to official portage tree it willn't be > present on official distfiles mirrors. > > 2. Menu item is created not always (to my mind for such application it's > uselessly), but depending on use flag. The only problem I have with number 1 is that you will have to extract the original archive, rename the folder and recompress it. Otherwise, I'm running into this: >>> Install davmail-3.9.1 into /var/tmp/portage/mail-client/davmail-3.9.1/image/ category mail-client /var/tmp/portage/mail-client/davmail-3.9.1/temp/environment: line 2132: cd: /var/tmp/portage/mail-client/davmail-3.9.1/work/davmail-linux-x86-3.9.1: No such file or directory sed: can't read davmail.sh: No such file or directory This is for when the ebuild is correcting the shell script.
Created attachment 268065 [details] Init script Init script I'm using for davmail. I haven't found a clean way to kill the server because the shell script spawns a new process. What I've done is create a new user and kill everything related to that user. The upshot, IMHO, is that the entire process isn't running as root or a standard user. If there is a better way to kill the processes, please let me know.
Created attachment 268067 [details] conf file Simple conf file for the init.
Created attachment 268069 [details] pre-generated properties file Davmail creates this file at first run, but for those running headless it might be easier to just pre-install it.
Created attachment 268073 [details] 3.9.1 supporting my contibutions I took Sergey's idea for making the desktop files conditional as well as his depends fixes. I left the SRC_URI alone from previous versions due to my earlier comments. Granted, this isn't going to be found on a Gentoo server, but it will still hit Sourceforge's servers to download the package. As mentioned in the notes for the init script, this creates a new user for davmail to run under.
This looks promising. I have the previous davmail ebuild in my overlay. (http://git.overlays.gentoo.org/gitweb/?p=user/seden.git or "layman -a seden") Do you mind me putting the new one there as well?
Created attachment 268139 [details] 3.9.1_p1646 ebuild supporting my contibutions (In reply to comment #17) Mea culpa. I had the ebuild saved as davmail-3.9.1.ebuild and not davmail-3.9.1_p1646.ebuild. Sorry for the confusion there. So, this is an update of my ebuild to allow for the correct naming schema.
Real men build from source. ;) I find it funny that no one ever seems to attempt building Java stuff. I've just committed a source ebuild to java-overlay. http://overlays.gentoo.org/proj/java/browser/java-overlay/net-mail/davmail The only thing that's bundled is the WebDAV component of Apache Jackrabbit because it isn't really feasible to build that until the new Maven stuff is in place. You may find that the tray applet has a tendency to crash. This is due to an upstream bug that has been reported and apparently fixed in SVN. I suspect a new release will be out soon. "menu" isn't an established USE flag and it wouldn't be the first package to install an icon when some may not need it so I just followed convention. By the same token, I omitted the "server" USE flag because it doesn't pull in any extra dependencies or add to the compilation time.
(In reply to comment #24) > Real men build from source. ;) I find it funny that no one ever seems to > attempt building Java stuff. I've just committed a source ebuild to > java-overlay. And what use it is to create the same jars? I am no java expert, but wasn't the point of java that the sources build thze same byte code vereywhere that runs everywhere? However, I am currently testing you ebuild. The last "unbundling"-attempt (see above) was everything but successful. I hope this is better, because besides building from source, it is the many bundled packages that I dislike. However, the desktop Icon never crashed for me.
(In reply to comment #25) > However, I am currently testing you ebuild. Or not, stax2-api-src-3.1.1 can not be fetched. :-(
> And what use it is to create the same jars? I am no java expert, but wasn't the > point of java that the sources build thze same byte code vereywhere that runs > everywhere? I'm not going to get dragged into that debate but the fact is this is Gentoo, we compile things. It does have its uses, even for Java. :) > However, I am currently testing you ebuild. The last "unbundling"-attempt (see > above) was everything but successful. I hope this is better, because besides > building from source, it is the many bundled packages that I dislike. Building it from source will mean that any missing classes or other incompatibilities will get reported at compile time. I am also an experienced Java packager and have tested that it works. The previous attempt looked like guesswork at best. > Or not, stax2-api-src-3.1.1 can not be fetched. :-( Sorry, I've just fixed that. I was originally packaging that JAR with wstx, which has a different PV and that PV forms part of the URI. The filename didn't change though, which is why I didn't spot this mistake.
(In reply to comment #27) > > And what use it is to create the same jars? I am no java expert, but wasn't the > > I'm not going to get dragged into that debate but the fact is this is Gentoo, > we compile things. It does have its uses, even for Java. :) Sorry, no debate meant. I simply have no idea what it's good for. "We compile things" is _not_ valid reason. But "It does have its uses" is, and I just would like to know which. ;-) (Always willing to learn, I am...) > > Or not, stax2-api-src-3.1.1 can not be fetched. :-( > > Sorry, I've just fixed that. I was originally packaging that JAR with wstx, > which has a different PV and that PV forms part of the URI. The filename didn't > change though, which is why I didn't spot this mistake. No harm done. It is a bit tricky to find, but I manually downloaded it and the ebuild was happy. So far it works. Both mail to and from Exchange work, and all calendars get synchronized as always. There are only two issues, though tiny ones, I have: A) davmail now needs almost thirty seconds to start. With the fully bundled version it was up in less than five seconds. How can this be? I mean the bundled version is built from the very same sources, isn't it? I have started it thrice now and all three times it took this long. B) You have the revision number hardcoded in the ebuild, but the version will stay being 3.9.1. I doubt this to be a good idea, because the next release will be the same version with different revision. There then must be a (non-descriptive) 3.9.1-r1 ebuild or updating is a bit like fortune telling when to sync and rebuild. Couldn't the revision be part of the ebuild version?
> Sorry, no debate meant. I simply have no idea what it's good for. "We compile > things" is _not_ valid reason. But "It does have its uses" is, and I just would > like to know which. ;-) (Always willing to learn, I am...) A strong point used to be the potential to build everything with GCJ but since Java has been open sourced, there seems to have been less interest in GCJ. Some people still like to be able to build all their Java software with a free JDK though. Unbundling allows us to apply patches for libraries universally. Building from source allows you to easily do the same if you require. Not major points but hey. > A) davmail now needs almost thirty seconds to start. Are you referring to the init script or the tray applet or both? Mine starts immediately and I can start using it immediately. Maybe try using strace to see what it's waiting for. Use one of these. strace -f davmail sudo -u davmail strace -f davmail /etc/davmail.properties > B) You have the revision number hardcoded in the ebuild, but the version will > stay being 3.9.1. Are you sure? I got the impression that even though the revision number is made clearly visible, the version number still changes. There don't seem to be any releases on SourceForge that share the same version number.
So, run /etc/init.d/davmail start after configuring my server's URL in /etc/davmail.properties and nothing happens (thunderbird says failed to connect, the port used is 1143). No logs are logged into /var/log/davmail.log other than shutdown message. Can I figure what the davmail server doing? I ran it from command line like: # /opt/davmail/davmail.sh /etc/davmail.properties Still no output on the terminal or in the log file. One thing I note is that tcp6 0 0 [::]:1025 [::]:* LISTEN tcp6 0 0 [::]:1389 [::]:* LISTEN tcp6 0 0 [::]:1110 [::]:* LISTEN tcp6 0 0 [::]:1143 [::]:* LISTEN tcp6 0 0 [::]:socks [::]:* LISTEN These are IPv6 only. When thunderbird is connecting to "localhost", what is it connecting to? How can I disable IPv6 for davmail?
Try my ebuild instead? It's interesting that it's using IPv6. I had a sneaking suspicion that might have something to do with the delay that Sven Eden is seeing. I don't have IPv6 enabled in my kernel.
First of all sorry for the very late reply! (In reply to comment #29) > A strong point used to be the potential to build everything with GCJ but since > Java has been open sourced, there seems to have been less interest in GCJ. Some > people still like to be able to build all their Java software with a free JDK > though. Unbundling allows us to apply patches for libraries universally. > Building from source allows you to easily do the same if you require. Not major > points but hey. I think the GCJ-point is nil. But the possibility to apply individual patches is a very strong one for me. ;-) Never thought about that one before. > > A) davmail now needs almost thirty seconds to start. > > Are you referring to the init script or the tray applet or both? Mine starts > immediately and I can start using it immediately. Maybe try using strace to see > what it's waiting for. Use one of these. Nothing. It's the tray applet I am always using, I do not need a permanent service. And the delay came from a mistake of mine when configuring my kernel. Your unbundled version is as fast as the bundled one, my mistake! > > B) You have the revision number hardcoded in the ebuild, but the version will > > stay being 3.9.1. > > Are you sure? I got the impression that even though the revision number is made > clearly visible, the version number still changes. There don't seem to be any > releases on SourceForge that share the same version number. You are right, my memory failed me there. However, do you think davmail and its dependencies have a chance to hit the main tree (or at least sunrise) at all?
Great that it works for you now. I think there's little need for it to go into Sunrise if it's already in java-overlay. It'll need a maintainer for the main tree. There is talk of me becoming a developer but it is just talk for the moment. ;) Even so, I've actually stopped using this now because my company replaced Exchange Online with a regular Exchange server and now we have native IMAP access.
I have a problem. It didn't show up in the beginning, but from time to time davmail swaps like mad. Right now davmail needs 1.7GiB of my swap. top says: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 28529 sed 20 0 1712m 8412 1776 S 0 0.2 0:25.76 1.7g java and ps says: sed 28529 27470 0 09:50 ? 00:00:25 java -classpath /usr/share/htmlcleaner/lib/htmlcleaner.jar:/usr/share/slf4j-api/lib/slf4j-api.jar:/usr/share/xml-commons-resolver/lib/xml-commons-resolver.jar:/usr/share/ant-core/lib/ant.jar:/usr/share/jcifs-1.1/lib/jcifs.jar:/usr/share/sun-javamail/lib/mail.jar:/usr/share/jdom-jaxen-1.0/lib/jdom-jaxen.jar:/usr/share/tomcat-servlet-api-2.5/lib/servlet-api.jar:/usr/share/swt-3.6/lib/swt.jar:/usr/share/xml-commons-external-1.3/lib/xml-apis.jar:/usr/share/xml-commons-external-1.3/lib/xml-apis-ext.jar:/usr/share/xalan-serializer/lib/serializer.jar:/usr/share/commons-codec/lib/commons-codec.jar:/usr/share/xerces-2/lib/xercesImpl.jar:/usr/share/slf4j-nop/lib/slf4j-nop.jar:/usr/share/commons-collections/lib/commons-collections.jar:/usr/share/tomcat-servlet-api-2.5/lib/jsp-api.jar:/usr/share/ant-core/lib/ant-launcher.jar:/usr/share/servletapi-2.4/lib/servlet-api.jar:/usr/share/ant-core/lib/ant-bootstrap.jar:/usr/share/jdom-1.0/lib/jdom.jar:/usr/share/saxpath/lib/saxpath.jar:/usr/share/commons-logging/lib/commons-logging-api.jar:/usr/share/log4j/lib/log4j.jar:/usr/share/commons-logging/lib/commons-logging-adapters.jar:/usr/share/servletapi-2.4/lib/jsp-api.jar:/usr/share/commons-logging/lib/commons-logging.jar:/usr/share/davmail/lib/davmail.jar:/usr/share/commons-httpclient-3/lib/commons-httpclient.jar:/usr/share/stax2-api/lib/stax2-api.jar:/usr/share/davmail/lib/jackrabbit-webdav.jar -Djava.library.path=/usr/lib64:/lib:/usr/lib davmail.DavGateway is this normal behavior for a program that ought to do nothing but stay out of the way unless a connection is wanted and then simply map and wrap it? The swapping occurs when I have to use vmware-workstation, as it needs a lot of memory. As I use rarely this means that davmail ate up my RAM without me knowing.
That's certainly not normal. As I said, I'm not using it now but I didn't see that in the short time I did use it. I recommend you try using the upstream binaries before filing a bug with them.
I will try the old binary ebuild today. I have tweaked some .vm settings to have more mem and less swap usage, but "java" is listed in top as: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19105 sed 20 0 1715m 89m 24m S 0 2.4 0:07.83 java I hope I can find out what is pushing it up like that. There are no other java applications running at the moment.
Created attachment 286633 [details] net-mail/davmail-3.9.4 - Binary (packaged/bundled) version This is an updated ebuild, I took yours, Tom, but took the revision from the file name, like James did. I like it mcuh better this way. The bundled ebuild is mainly to see whether the memory usage changes with it like suggested by James in comment #35. Here is the result: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21088 sed 20 0 1467m 70m 21m S 0 1.9 0:03.33 java So, yes, but way not enough. Something in there is a resource hog. Or it is the JRE that did not scale down after stopping the old davmail and starting the new one. If a reboot changes this drastically, I'll report back.
Created attachment 291871 [details] net-mail/davmail-3.9.6 - Binary (packaged/bundled) version Here is the new ebuild. Unfortunately I can not test it, because portage does no longer work correctly with sourceforge mirrors on my system. Maybe someone has an idea? SRC_URI is set to "mirror://sourceforge/davmail/davmail-linux-x86_64-3.9.6-1843.tgz" But portage tries to download: http://[mirror].sourceforge.net/sourceforge/davmail/.tgz with [mirror] being all that are known in sequence. Strange.
Created attachment 293493 [details] davmail-bin-3.9.6-r1.ebuild I have decided to put davmail back into my overlay, as the source based ebuild in the java-overlay is not updated (yet). As this is a binary install, I have decided to rename it to davmail-bin. This is mainly to not clash with the source based ebuild in the java overlay.
Sorry for falling behind. It's hard enough keeping up to date with the stuff I actually do use. I renamed the ebuild and changed the revision. It builds and the GUI runs but I didn't test it beyond that. Give it a try yourself and if you're satisfied that it works, let me know and I'll update the overlay. Feel free to keep doing this. I will attempt to fix it if it breaks.
Created attachment 298627 [details] net-mail/davmail-3.9.7 - Binary (packaged/bundled) version Version bump, mirrored in my overlay.
My offer still stands!
Created attachment 303275 [details] davmail-3.9.8.ebuild Ebuild for the latest version 3.9.8. I slightly modified the ebuild to better comply with the Gentoo standards.
Created attachment 303277 [details] davmail.conf New conf.d file for DavMail.
Created attachment 303279 [details] davmail.init New init.d script.
Created attachment 303281 [details] davmail.properties New properties file with remote connections enabled.
Please make the older files obsolete.
Jiri Tyr, would you be interested in testing the source version?
(In reply to comment #48) > Jiri Tyr, would you be interested in testing the source version? The problem is that there are not all packages needed for the compilation in the Portage Tree. This is why I kept all the JARs delivered with the DavMail.
True but they are all in java-overlay, which is considered to be relatively stable.
Created attachment 334216 [details] net-mail/davmail-bin-4.1.0-r1.ebuild Jiri Tyr, thank you for the modified ebuild. It did not pay any attention on this bug for almost a year and didn't see it earlier. But I now took the time to update the binary ebuild, also in my overlay, to reflect your enhancements.
fyi: The current version of davmail is 4.3.4. The binary ebuild net-mail/davmail-bin in my overlay works without problems on a production machine.
I'm successfully running net-mail/davmail-bin-4.4.1 from the seden overlay against an Exchange 2013 server. I had to edit the ebuild slightly - if USE="server" is specified, the ebuild tries to call enewuser and fails with "command not found". Adding the "user" eclass to the "inherit" line fixes it.
(In reply to Karl-Johan Karlsson from comment #53) > I'm successfully running net-mail/davmail-bin-4.4.1 from the seden overlay > against an Exchange 2013 server. > > I had to edit the ebuild slightly - if USE="server" is specified, the ebuild > tries to call enewuser and fails with "command not found". Adding the "user" > eclass to the "inherit" line fixes it. Thank you very much for the information!
net-mail/davmail-bin-4.5.0::seden still does "enewuser" without inheriting the "user" eclass, but otherwise works without problems.
(In reply to Karl-Johan Karlsson from comment #55) > net-mail/davmail-bin-4.5.0::seden still does "enewuser" without inheriting > the "user" eclass, but otherwise works without problems. Fixed. I have to admit that I completely forgot about that. I am very sorry and very thankful for the reminder!
