emerge evolution -pv [ebuild U ] mail-client/evolution-2.4.0 [2.2.3-r2] +crypt +dbus -debug -doc* +firefox* +gstreamer +ipv6 -kerberos -krb4 -ldap -mono -mozilla -nntp -pda -profile +spell +ssl -static 0 kB but then I get: Evolution has been configured as follows: Mail Directory: , LDAP support: no Pilot conduits: no Kerberos 4/5: no/no SSL support: no SMIME support: no IPv6 support: yes Plugins: yes (addressbook-file audio-inline bbdb calendar-file calendar-http calendar-weather copy-tool default-mailer default-source groupwise-account-setup groupwise-features itip-formatter mail-account-disable mail-to-task mailing-list-actions mark-all-read mark-calendar-offline new-mail-notify plugin-manager print-message sa-junk-plugin save-calendar select-one-source startup-wizard subject-thread ) Gtk-doc: no DBus API version 230 don't know though if this actually depends on evolution-data-server
*** Bug 105033 has been marked as a duplicate of this bug. ***
Can confirm this bug. Using either mozilla or firefox for SSL support means evolution won't compile with SSL. Using just +ssl for evolution-data-server & evolution, evolution's configure script at least sees the necessary libs & includes & compiles SSL support: Evolution has been configured as follows: Mail Directory: , LDAP support: no NNTP support: yes Pilot conduits: no Kerberos 4/5: no/no SSL support: yes (Mozilla NSS) SMIME support: yes (Mozilla NSS) IPv6 support: yes Alas, once the compile is finished SSL support is buggy. To use SSL imap support you must configure your IMAPS server such: your.server.com:993 Or it will only ever try to connect to the server on standard IMAP (143). This at least gets evolution connecting to the right port & initiating the connection, however it never gets past this point & the connect times out as it doesn't send the username login correctly. It also hard crashes when quitting the application & it's bug buddy crash report implementation is broken. All this is by-the-by & perhaps best included in several more gentoo bugzilla reports, however my feeling is that these problems are probably more attributed to the upstream devs. Even though they have marked this as the latest stable release, this version of Evolution is not quite ready for prime time. It is hard-masked after all ;)
(In reply to comment #2) > Can confirm this bug. > > Using either mozilla or firefox for SSL support means evolution won't compile > with SSL. > > Using just +ssl for evolution-data-server & evolution, evolution's configure > script at least sees the necessary libs & includes & compiles SSL support: This is not entirely true since mine compiled fine with the mozilla and ssl use flag. just the firefox flag borked everything. [ Found these USE variables for mail-client/evolution-2.4.0 ] U I + + crypt + + dbus - - debug - - doc - - firefox - - gstreamer + + ipv6 - - kerberos - - krb4 + + ldap - - mono + + mozilla - - nntp - - pda - - profile + + spell + + ssl - - static - - debug - - debug OT: anyone know why tha hell equery returned 2 debug use flags?!
Shouldn't this be merged with bug 105030 - they are basically the same problem as the configure.ac code is the same in eds and evo. Both eds and evo merge fine with USE="mozilla -firefox" - perhaps should remove firefox support until firefox 1.0.6-r6 is unmasked, or -r5 fixed to install correct headers.
There is one more thing to this, I don't know why they commit such things to evolution, but the following code will break the things totally, it compiles fine with mozilla-1.0.6-r6, but does not have ssl-supprot at run-time because of this lines in smime/lib/e-cert-db.c : if (!RootsModule) { /* grovel in various places for mozilla's built-in cert module. XXX yes this is gross. *sigh* */ char *paths_to_check[] = { "/usr/lib", "/usr/lib/mozilla", "/opt/mozilla/lib", "/opt/mozilla/lib/mozilla" }; for (i = 0; i < G_N_ELEMENTS (paths_to_check); i ++) { char *dll_path = g_module_build_path (paths_to_check [i], "nssckbi"); which means it will not run with mozilla-firefox and probably with nss and nspr standalone packages. Should it be an upstream bug or should it be patched.
Dup'ing with 105030, as Ed points out, they're basically the same problem. We'll work on it over there. *** This bug has been marked as a duplicate of 105030 ***
