The ebuilds for Evolution 1.4.3 and 1.4.4 are written so that if the mozilla useflag is not set, it should use nspr and nss for handling SSL encryption. However that does not end up happening. If the mozilla useflag it not set, it doesn't seem to call anything for ssl support. If you do a pretend emerge with the command 'USE="ssl -mozilla" emerge -pev =net-mail/evolution-1.4.4' you will not see either package in the dependency list. I've been able to replicate this on x86 and sparc both using ~arch for ACCEPT_KEYWORDS. Reproducible: Always Steps to Reproduce: 1. USE="ssl -mozilla" emerge -pev =net-mail/evolution-1.4.4 2. 3. Actual Results: nspr and nss were not in the dependency list. Expected Results: nspr and nss should have been in the dependency list. Portage 2.0.48-r7 (default-sparc64-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.21-sparc-r1 sparc64 sun4u GENTOO_MIRRORS="http://adelie.polymtl.ca/ ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://gentoo.mirrors.pair.com/" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="sparc apm crypt cups fbcon foomaticdb jpeg libwww mad ncurses oss png pdflib spell truetype xv xmms zlib gdbm berkdb readline X sdl tcpd pam ssl perl python esd imlib oggvorbis gtk qt kde motif opengl ldap artswrappersuid dga emacs gtk2 gtkhtml imap samba X509 Xaw3d xface -avi -encode -gif -gnome -java -mikmod -mpeg -nls -xml2 -slang -arts" COMPILER="gcc3" CHOST="sparc-unknown-linux-gnu" CFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O3 -pipe" CXXFLAGS="-mcpu=ultrasparc -mtune=ultrasparc -O3 -pipe" ACCEPT_KEYWORDS="sparc ~sparc" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox buildpkg ccache"
You dont happen to have mozilla around ? It's an OR , so the nspr/nss stuff only gets installed only when you don't have mozilla at all. I'm not sure exactly why this is done this way, lqx probably did that and can explain why.
Correct, I do not have mozilla installed. I do have MozillaFirebird installed but it doesn't appear to have linked against it during compilation.
the mozilla useflag was from long ago before we has nss/nspr ebuilds. if -mozilla is specified, the ebuild uses openssl instead of nss/nspr. both are equivalent in functionality, just that some ppl may not like to have mozilla installed. so no need to panic here. not a bug
Well, the reason I opened it is because evolution is unable to connect to IMAPS services if the mozilla useflag is not set, but ssl is (at least on sparc). Basically in evolution, there is no way to set it to use a secure connection for IMAP, it only allows you to use the default insecure IMAP services. I had thought that nss/nsbr was to be used in place of mozilla.
odd, because my evolution does imaps and uses openssl instead of nss/nspr. can you try running: ldd /usr/lib/evolution/1.4/libcamel.so ... libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4135b000) ... well, right now the evolution ebuild can link to either net-www/mozilla or ( dev-libs/nss dev-libs/nspr)
Evolution is linked as you mentioned libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x70d90000) Evolution always tries to bind to the regular IMAP port (143) and never tries for the IMAPS port (993). Nor can you configure the SSL options for the account or in general as they do not exist in the menu system.
Clarification on the SSL options. Yes you can tell evolution to use SSL, however it does not seem to adjust the port number it attempts to connect on. I have not been able to find a setting for this.
if you want to force the port to say 993, you could do it by using imap.server.com:993 as the server name this is very odd given that i'm using SSL and also imaps off dev.gentoo.org. i wonder if it could be something else causing it. the last time i heard this happening was way back in 1.2.x.
Well this turns out not to be valid for two reasons. 1) I had a firewall blocking IMAP traffic, this is fixed. 2) IMAP server I was trying to access only supports IMAP and not IMAPS Sorry for the confusion.
