Re: [Evolution-hackers] Imminent critical SSL problem in evolution 3.10
On Mon, 2014-10-27 at 07:13 +0100, Milan Crha wrote: > On Sat, 2014-10-25 at 11:53 -0700, James Bottomley wrote: > > It looks like the recently released openssl 1.0.1j breaks evolution > > by > > causing it to have no overlapping cyphersuites. I've created a bug > > for > > it here: > > > > https://bugzilla.gnome.org/show_bug.cgi?id=739179 > > > > But it needs fixing as a matter of urgency, since this is the version > > most desktop distros ship and with heartbleed it won't take long for > > all > > the imap clients to be upgraded to this version. > > > > Hi, > I closed the bug, the fix is referenced from: > https://mail.gnome.org/archives/evolution-list/2014-October/msg00113.html > > As I wrote in the bug, you should ask the evolution-data-server > maintainers in your distribution to include the fix. OK, I reopened it as incomplete. You can't close it as FIXED when it isn't upstream in the gnome tree because that's going to cause massive confusion: a package maintainer reading the bugzilla list is going to think they're getting the fix from the 3.10 branch when, in fact, they're not. If there's some reason not to incorporate the distro patch into the 3.10 fixes branch, then close it as WONTFIX with reference to the distro patch. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Has Regressed Considerably
On Mon, Oct 27, 2014 at 6:09 PM, Matthew Barnes wrote: > On 10/27/2014 02:22 AM, Milan Crha wrote: > >> On Sat, 2014-10-25 at 06:09 +0100, Onyeibo Oku wrote: >> >>> The newest bizarre status is the "Unknown background operation". >>> What is that? >>> >> >> Unknown is unknown, the operation didn't identify itself yet. >> Backtrace matters here, but I'd guess this is related to server >> address resolutions (it uses to be), thus also related to the above >> bug. >> > > I added the "Unknown background operation" as a hack to try and flush out > tasks that were silently executing without a message being posted in the > status bar. > I think the status bar messages shall be cleaned up, today it's more like a place for "logs" of individual actions. Maybe a separate log window can be provided if the user clicks on something like this. but the status bar shall be used only for real stuff that provides status, like "downloading 1 of 100 messages" and it shall update in place, not replace itself with a new message "downloading 2 of 100 messages". When things are downloaded "it shall state "synced" for example, so that you know all messages are there in your inbox, etc. etc. For example, when I open an IMAP folder for the first time with 20k messages inside, the status bar floods with too many messages but does not really give any info since there's no time to read them! they come and disappear immediately. PS. Just a wish... Br, Emre ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Has Regressed Considerably
On 10/27/2014 02:22 AM, Milan Crha wrote: On Sat, 2014-10-25 at 06:09 +0100, Onyeibo Oku wrote: The newest bizarre status is the "Unknown background operation". What is that? Unknown is unknown, the operation didn't identify itself yet. Backtrace matters here, but I'd guess this is related to server address resolutions (it uses to be), thus also related to the above bug. I added the "Unknown background operation" as a hack to try and flush out tasks that were silently executing without a message being posted in the status bar. But sometimes even tasks that *do* push a status message only do so after some delay like waiting to acquire a mutex, and it's during that interim that you see the "Unknown background operation" message. One way you might fix that (for 3.14) is to break the CamelSession API to have camel_session_submit_job() take an initial message up front: void camel_session_submit_job (CamelSession *session, const gchar *initial_message, CamelSessionCallback callback, gpointer user_data, GDestroyNotify notify) Then you could push the initial message just after emitting the "job-started" signal in session_start_job_cb() and pop it just after the CamelSessionCallback function returns in session_do_job_cb(). That would eliminate the need for the "Unknown background operation" hack in Evolution because the Camel API would now *force* callers to provide a status message. It's a more direct solution for what I was trying to do with the hack. Just a suggestion. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
