Re: [Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-16 at 09:05 +0200, Milan Crha via evolution-hackers wrote: > On Wed, 2019-05-15 at 15:49 -0700, James Bottomley wrote: > > gnutls Add support for timeouts on GnuTLS pulls > > > > So if you apply that on top of 2.54.1, the test programme works > > again. > > Hi, > do you see from the server logs whether the patched code tried TLS > v1.3, and then v1.2? I'm only wondering. My expectation based on the patch is that 1.3 is negotiated successfully. I tested against googlemail.com (so no server logs). I've currently got an email user out travelling who can't upgrade until I get the machine back, so I can't test on my server until they come back on Friday to avoid breaking them. > After re-reading the previous messages in this thread, you found that > the development version 2.55.2 works fine. As it's a development > version, the (usual) distributions may pick the stable version, > 2.56.0 or later. Or they can find which patch fixed it between 2.55.1 > and 2.55.2 and backport only that one (you referenced that change > above). openSUSE has chosen the backport to 2.54.1 route. > Thinking of it, maybe it's a nonsense to ask them about the TLS > version downgrade on the fly. My "suggestion" would be over- > complicated. > > In any case, thank you for your time and help on this. You're welcome, Regards, 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 failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 18:00 +0200, Milan Crha via evolution-hacker > Consider filling a bug against glib-networking [1] and ask them > whether they can do anything about it. You've a clear view what is > going on in the background, thus you'd be able to explain the problem > to them. Feel free to use the test program to your liking. openSUSE triaged this to commit 0795cd14651c965659ccef33630872a53a7bc8ec Author: Olivier Crête Date: Fri Jul 3 12:43:45 2015 +0100 gnutls Add support for timeouts on GnuTLS pulls So if you apply that on top of 2.54.1, the test programme works again. I tried to file a bug but I can't seem to recover my account credentials for the new gitlab system. 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 failing on TLSv1.3 after gnutls upgrade
On Mon, 2019-05-13 at 09:17 +0200, Milan Crha via evolution-hackers wrote: > On Sun, 2019-05-12 at 11:04 -0700, James Bottomley via evolution- > hackers wrote: [...] > > I think the solution is to simply bar glib-networking below 2.55.2 > > from using gnutls VERS-TLS1.3 which looks like it can be done > > reasonably well in g_tls_connection_gnutls_init_priorities() > > There are some issues with it: a) the function is a private function, > I didn't find it in any of the header files under /usr/include/; b) > it's a very specific function, there's a branch to support also > openssl in glib-networking, where this would do nothing; c) getting > such change into an old evolution-data-server or glib-networking > might be tricky, especially with Long Term Support distributions; d) > as Sasa showed (if I understand it correctly), limiting TLS version > may lead to rejected connections on otherwise working system (it's > when the server increases TLS version requirement, but the "proposed > change" would limit what can be used). With glib-networking < 2.55.2 there seems to be no way of supporting TLSv1.3. All current TLSv1.3 systems also support at least 1.2 (the allegedly more secure ones may have turned off 1.0 and 1.1 for various reasons), so disabling only 1.3 seems like a useful solution. As for how to apply the fix (assuming we can find it), this is a hard one. Clearly the bug was always present, but the conditions that trip it remained untested until people started turning on TLSv1.3. I think the best way forward is to open bugs with the distros and see what they want to do: Either find and fix the bug or update to 2.55.2. > That said, when the server requires recent TLS version, the users > need to update their system to also support such TLS version. It > makes sense (once one knows where the problem is, which I wasn't sure > at all at the beginning). Just to clarify, the server isn't requiring a particular version, it's offering a set of options and we're choosing TLSv1.3 which we then can't negotiate successfully, so the bug is client side but triggered both by the client going to a gnutls (or probably openssl but I can't test that) version that makes 1.3 possible and the server offering it as an option. > Thank you James for all the testing and finding that out. > It's good to know that glib has it fixed already. You're welcome ... I just wish I could identify the actual fix. 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 failing on TLSv1.3 after gnutls upgrade
On Fri, 2019-05-10 at 23:23 +0200, Sasa Ostrouska via evolution-hackers wrote: > Hi all, and thanks Milan for the program. I also run an old version > of evolution 3.20.x and I get the following: > > rc@rc-laptop:~/Downloads$ gcc `pkg-config --cflags --libs glib-2.0 > gio-2.0` imap-conn.c -g -O0 -o imap-conn && ./imap-conn > imap.googlemail.com 993 > Connected to imap.googlemail.com:993 > Failed to read data from the server: Error reading data from TLS > socket: The specified session has been invalidated for some reason. > > I neded to #include on my slackware linux. Me too, but it was a trivial update. I did a bit of build bisection. Most of the failing glib-networking packages are 2.54.1 and below. 2.55.2 is the first working version (2.55.1 doesn't build due to missing glib-pacrunner). So, clearly, whatever the TLSv1.3 bug was it was fixed in this version, but I can find neither a bugzilla nor a commit obviously identifying the problem. 2.54.1 was the last version that used autoconf, 2.55.2 uses meson, which probably explains why a few distributions are stuck on 2.54.1. I think the solution is to simply bar glib-networking below 2.55.2 from using gnutls VERS-TLS1.3 which looks like it can be done reasonably well in g_tls_connection_gnutls_init_priorities() 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 failing on TLSv1.3 after gnutls upgrade
On Fri, 2019-05-10 at 08:41 +0200, Milan Crha via evolution-hackers
wrote:
> On Thu, 2019-05-09 at 11:03 -0700, James Bottomley wrote:
> > I can certainly test things out.
>
> Hi,
> that's great, thanks.
>
> > To be honest, I've had problems with TLSv1.3 every time it's been
> > negotiated, so disabling it is a reasonable thing to do.
>
> I see. If you are still willing to help, then it'll be appreciated.
>
> > I suppose there's no gntuls-cli equivalent for glib-
> > networking? That
> > would be the best way to test it.
>
> I agree, but I'm not aware of anything like that (which doesn't mean
> it
> doesn't exist). I made a little test program as promised, see the
> attachment. The first line contains a comment with a command to
> compile
> and run it (against Google's IMAP server). It's only a test program,
> mimic-ing what Evolution (or better Camel library from evolution-
> data-
> server) does. You may have installed development packages for glib
> and,
> if split, also for glib's gio, to be able to compile it.
>
> Bye,
> Milan
>
> P.S.: The result of the run as is in the file itself is below:
>
>
> $ ./imap-conn imap.googlemail.com 993
>
> Connected to imap.googlemail.com:993
> Response: * OK Gimap ready for requests from {IPADDRESS} {SOMETOKEN}
>
> Request: A01 CAPABILITY
> Response: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID
> XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN
> AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH
> A01 OK Thats all she wrote! {SOMETOKEN}
>
> Request: A02 LOGOUT
> Response: * BYE Logout Requested {SOMETOKEN}
> A02 OK Quoth the raven, nevermore... {SOMETOKEN}
So when I run it against my current setup (TLSv1.3 disabled) I get this
as expected:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Response: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready.
Request: A01 CAPABILITY
Response: * CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
LITERAL+ AUTH=PLAIN
Request: A02 LOGOUT
Response: A01 OK Pre-login capabilities listed, post-login capabilities have
more.
But when I enable TLSv1.3 in dovecot on the server I get this:
jejb@jarvis:~> ./imap-conn bedivere.hansenpartnership.com 993
Connected to bedivere.hansenpartnership.com:993
Failed to read data from the server: Error reading data from TLS socket: The
specified session has been invalidated for some reason.
Which isn't particularly helpful, although it does prove the issue is
indeed in glib-networking. Is there further debugging I should turn
on?
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 failing on TLSv1.3 after gnutls upgrade
On Thu, 2019-05-09 at 18:42 +0200, Milan Crha via evolution-hackers wrote: > On Thu, 2019-05-09 at 08:37 -0700, James Bottomley via evolution- > hackers wrote: > > On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing > > > > gnutls-3.6.7-lp150.9.1.x86_64 > > > > Lead to evolution failing on my dovecot imap server with > > > > Error reading data from TLS socket: The specified session has been > > invalidated for some reason > > Hi, > dealing with such requests is better either through the user list > (evolution-list), or through bugzilla - see the "bugs" section of: > https://wiki.gnome.org/Apps/Evolution/#Online_Support > not talking that your Evolution it rather old, the current stable > version is 3.32.2. > > Nonetheless, I do not expect that Evolution update would help, > because Evolution doesn't use gnutls. It doesn't use it directly. > Evolution relies on glib-networking and on whatever it uses, which is > gnutls in this case. Ah, right, that's why I couldn't find the direct connection. > I guess those developers would appreciate any help, > especially if the code is broken for them. If you wish, I can try to > create some simple test program (a .c file), which would open a > stream towards specified server and ask for capabilities or > something, which can be done in an unauthenticated state, on which > you can verify: > a) it's really in glib-networking, b) whether more recent version of > it will help. I can certainly test things out. To be honest, I've had problems with TLSv1.3 every time it's been negotiated, so disabling it is a reasonable thing to do. I suppose there's no gntuls-cli equivalent for glib-networking? That would be the best way to test it. 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
[Evolution-hackers] evolution failing on TLSv1.3 after gnutls upgrade
On OpenSUSE running evolution-3.26.6-lp150.2.6.x86_64, installing gnutls-3.6.7-lp150.9.1.x86_64 Lead to evolution failing on my dovecot imap server with Error reading data from TLS socket: The specified session has been invalidated for some reason Turning on ssl verbose debugging on the dovecot server shows this May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read finished May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully May 9 07:44:05 bedivere dovecot: imap-login: Debug: SSL alert: close notify May 9 07:44:05 bedivere dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=153.66.160.226, lip=153.66.160.254, TLS, session= So dovecot thinks the session was negotiated successfully, but evolution doesn't and thus no authentication attempts are made. gnutls-cli doesn't seem to have a problem connecting at TLSv1.3: jejb@jarvis:~> gnutls-cli -d 1 -p 993 bedivere.hansenpartnership.com Processed 405 CA certificate(s). Resolving 'bedivere.hansenpartnership.com:993'... Connecting to '66.63.167.143:993'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=bedivere.hansenpartnership.com', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x0328497b8aaa5af37e798c749a130cfb8d10, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-05-05 08:23:13 UTC', expires `2019-08-03 08:23:13 UTC', pin-sha256="X1hoRFoc2Dx7VFEFk8krheR0zwy5hYxE/xNrG0B+Qoo=" Public Key ID: sha1:12218c287996b0041d8eaec4782010a1999d9539 sha256:5f5868445a1cd83c7b54510593c92b85e474cf0cb9858c44ff136b1b407e428a Public Key PIN: pin-sha256:X1hoRFoc2Dx7VFEFk8krheR0zwy5hYxE/xNrG0B+Qoo= - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" - Status: The certificate is trusted. - Description: (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) - Options: - Handshake was completed - Simple Client Mode: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot (Debian) ready. So it's something within evolution itself. I've fixed this temporarily by disabling TLSv1.3 on the server, but since dovecot doesn't have a way to do this, I had to do it in openssl.cnf which is somewhat less optimal (although I'd already disabled TLSv1.3 for apache because of its failure to handle client certificates, so I think it's safe). 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] Need help debugging owncloud caldav problem
On Thu, 2015-11-26 at 09:06 +0100, Milan Crha wrote: > On Thu, 2015-11-26 at 08:01 +0300, James Bottomley wrote: > > I'm thinking currently the fix might be in libical. Both the issues: > > converting VALUE= to VALUE=x and adding it to the TZID look to be > > bugs in that library. > > Hi, > what is your libical version, please? As I said in the previous email, > mine version, 1.0.1, doesn't add quotes around the value. It only makes > the VALUE=X from VALUE=. I tried that on a local calendar (On This > Computer), which pointed to a custom file, where I did all the "raw" > editing. rpm -qi libical1 Name: libical1 Version : 1.0 Release : 5.2.2 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] Need help debugging owncloud caldav problem
On Tue, 2015-11-24 at 18:32 +0100, Milan Crha wrote: > On Tue, 2015-11-24 at 15:17 +0300, James Bottomley wrote: > > DTSTART;TZID=America/Los_Angeles:20131024T18 > > DTEND;TZID="America/Los_Angeles;VALUE=":20131024T20 > > > > Removing the quotes and the spurious ;VALUE= for the DTEND TZID causes > > the event to become visible when evolution is restarted. So, it looks > > like something in the caldav connector is adding bogus data to the TZID > > information. > > Hi, > I agree with you, the empty VALUE= should not be there. How the quotes > got around it is another question. OK, so I found the reason for this. There's a bug in the owncloud calendar importer that adds an empty VALUE= label to DTEND https://github.com/owncloud/calendar/issues/991 However, this doesn't excuse evolution's handling of it, because every other caldav implementation silently ignores this whereas we mangle it into a potentially unreadable timezone and then drop the event. The mangling seems to occur as part of the back end caching and is likely the fault of libical. I'll see if I can work out how to fix it. 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] Need help debugging owncloud caldav problem
On Wed, 2015-11-25 at 15:23 +0100, Milan Crha wrote: > On Wed, 2015-11-25 at 12:21 +0300, James Bottomley wrote: > > On Tue, 2015-11-24 at 18:32 +0100, Milan Crha wrote: > > > On Tue, 2015-11-24 at 15:17 +0300, James Bottomley wrote: > > > > DTSTART;TZID=America/Los_Angeles:20131024T18 > > > > DTEND;TZID="America/Los_Angeles;VALUE=":20131024T20 > > > > > > > > However, this doesn't excuse evolution's handling of it, > > Hi, > it depends. > > > because every other caldav implementation silently ignores this > > How do they ignore it? Do they convert the time into a floating time? > That means that they interpret the end time of the event as being in > the timezone the view is set for. No, they just drop the bogus VALUE=, so what owncloud supplies is DTEND;TZID=America/Los_Angeles;VALUE=:20151125T19 simply becomes DTEND;TZID=America/Los_Angeles:20151125T19 And the appointment ends up being displayed correctly. > Thus, if you've set your view's > (UI's) timezone to America/Los_Angeles, then you won't notice any > difference, the event will be on 2013-10-24 between 18:00 and 20:00. If > you've view's timezone set to UTC, then the time with the floating > interpretation is from 2013-10-25 02:00 to 2013-10-24 20:00. That means > the start of the event is _after_ its end. It's precisely what the > evolution's day view told you: > > (evolution:19872): calendar-gui-CRITICAL **: e_day_view_add_event: > > assertion 'start <= end' failed > > > whereas we mangle it into a potentially unreadable timezone and then > > drop the event. The mangling seems to occur as part of the back end > > caching and is likely the fault of libical. > > Right, I'd like to know which part added the quotes. I tried to read > the same event without the quotes and save it locally and the result > was: >DTEND;VALUE=X;TZID=America/Los_Angeles:20151125T19 > that means the libical didn't add there the quotes. At least the 1.0.1 > version doesn't do that. You started with the thing the wrong way around you need to feed it DTEND;TZID=America/Los_Angeles;VALUE=:20151125T19 Which then gets cached as DTEND;TZID="America/Los_Angeles;VALUE=":20151125T19 So for some reason the bogus value gets appended to the timezone. > I also tried what the evolution's UI will do when I change my view's > timezone to America/Los_Angeles and set the DTENT to the quoted TZID, > as you found it, and the result is that the evolution showed the event > properly. As soon as I changed to another timezone, like a > Europe/Prague, the event disappeared from the view and the evolution > console contained runtime warnings, though different from that yours: > >> e_day_view_add_event: assertion 'start < add_event_data->day_view > >> ->upper' failed > > Interestingly, a change of the view's timeozne to Pacific/Midway didn't > make the event longer. I would expect it to happen. > > > I'll see if I can work out how to fix it. > > Thanks, I appreciate it. Just consider that trying to workaround other > software's fault, especially such specific, is likely not to happen. > It's because the only correct fix is the fix of the broken software > (aka your opened ticket against ownCloud). I'm thinking currently the fix might be in libical. Both the issues: converting VALUE= to VALUE=x and adding it to the TZID look to be bugs in that library. 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] Need help debugging owncloud caldav problem
On Wed, 2015-11-18 at 10:03 -0800, James Bottomley wrote: > On Wed, 2015-11-18 at 07:53 +0100, Milan Crha wrote: > > On Tue, 2015-11-17 at 09:42 -0800, James Bottomley wrote: > > > Shows they're all present, including the ones evolution is not > > > displaying. I suspect there's some issue somewhere in the ical file > > > that's causing a parse problem ... so my question, how do I debug > > > this? Is there a magic debug option to show parsing of ical events? > > > > Hi, > > there is no magic option to debug parsing of the iCalendar object, the > > only CalDAV related debugging option you already found and used > > properly. > > Sigh, that's what I suspected from reading the code; thanks for > confirming. > > > I would double-check that you do not have any filters set in the > > Evolution's UI, then pick one of those missing events and enter a > > similar one into the CalDAV calendar. Then compare the two objects in > > the local cache and see the differences. Compare also UID and > > RECURRENCE-ID properties of the components, the later is there for > > recurring events only. > > Right, no filters. Actually I've been copying events into a local > calendar (as in creating an ical file from the events in the local > caldav cache) ... what do you know, not only do they appear, but the > missing equivalent in the caldav calendar also appears. So I'm thinking > this is either some sort of iterator problem in the data server itself, > or in the actual evolution front end. > > > It would be also interesting if you could share one of the missing > > events, with sanitized values like the Summary, Description and any > > e-mail addresses and such - anything you consider private. > > I will if I can find one which genuinely fails ... as in it won't appear > even when placed into a separate ical file. OK, I think I've identified one reason. It seems to be a misparsing of DTEND in the caldav cache. An event that's not appearing is triggering this warning: (evolution:19872): calendar-gui-CRITICAL **: e_day_view_add_event: assertion 'start <= end' failed And, on checking the calendar.ics cache, this appears for the times: DTSTART;TZID=America/Los_Angeles:20131024T18 DTEND;TZID="America/Los_Angeles;VALUE=":20131024T20 Removing the quotes and the spurious ;VALUE= for the DTEND TZID causes the event to become visible when evolution is restarted. So, it looks like something in the caldav connector is adding bogus data to the TZID information. 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] Need help debugging owncloud caldav problem
On Wed, 2015-11-18 at 07:53 +0100, Milan Crha wrote: > On Tue, 2015-11-17 at 09:42 -0800, James Bottomley wrote: > > Shows they're all present, including the ones evolution is not > > displaying. I suspect there's some issue somewhere in the ical file > > that's causing a parse problem ... so my question, how do I debug > > this? Is there a magic debug option to show parsing of ical events? > > Hi, > there is no magic option to debug parsing of the iCalendar object, the > only CalDAV related debugging option you already found and used > properly. Sigh, that's what I suspected from reading the code; thanks for confirming. > I would double-check that you do not have any filters set in the > Evolution's UI, then pick one of those missing events and enter a > similar one into the CalDAV calendar. Then compare the two objects in > the local cache and see the differences. Compare also UID and > RECURRENCE-ID properties of the components, the later is there for > recurring events only. Right, no filters. Actually I've been copying events into a local calendar (as in creating an ical file from the events in the local caldav cache) ... what do you know, not only do they appear, but the missing equivalent in the caldav calendar also appears. So I'm thinking this is either some sort of iterator problem in the data server itself, or in the actual evolution front end. > It would be also interesting if you could share one of the missing > events, with sanitized values like the Summary, Description and any > e-mail addresses and such - anything you consider private. I will if I can find one which genuinely fails ... as in it won't appear even when placed into a separate ical file. > By the way, what evolution(-data-server) version are you using, please? 3.12 James > Bye, > Milan > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Need help debugging owncloud caldav problem
At least, it may not necessarily be a caldav problem, I think it might actually be an ical parsing issue. The symptoms are that I've exported about 1,300 events from my google calendar and imported it successfully into owncloud. Verification via the web calendar and also the caldav android connector works and sees all the events. Evoution does not, its calendar only sees a couple of them. doing CALDAV_DEBUG=all, I see the caldav backend has sync'd all the events, confirmed by this message CalDAV - finished syncing with 1278 items in a cache And a manual inspection of .cache/evolution/calendar/1447535993.17449.1@jarvis/calendar.ics Shows they're all present, including the ones evolution is not displaying. I suspect there's some issue somewhere in the ical file that's causing a parse problem ... so my question, how do I debug this? Is there a magic debug option to show parsing of ical events? Thanks, 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] Imminent critical SSL problem in evolution 3.10
On Wed, 2014-10-29 at 07:56 +0100, Milan Crha wrote: On Mon, 2014-10-27 at 10:00 -0700, James Bottomley wrote: 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. Hi, we look on the same thing in a different ways. My point of view: the *current* stable version is 3.12.x (right now 3.12.7). This current stable version doesn't suffer of the issue described for 3.10 version. well, I know this, I run 3.12 as well. That's why the bugzilla is opened against 3.10.x. To close it as fixed becuase it's not a problem in 3.12.x is a brazen lie. It's not my fault that your distribution uses obsolete evolution version; I do not have any influence on it. The bug as such is fixed, in the *current* stable version. The 3.10 is dead for the upstream. Nonetheless, my intention was to provide a fix for such distributions anyway, in a way I chose. I'm not going to commit the patch to the gnome-3-10 branch, I do not like to add changes into dead branches, where no releases will be done. Fine so close it as WONTFIX if you're not maintaining a 3.10.x fixes branch ... it's not rocket science. 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] 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
[Evolution-hackers] Imminent critical SSL problem in evolution 3.10
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. 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
[Evolution-hackers] evolution-ews: complete failure of git head calendar to work
From this patch: commit 250164f2ec01cb3dad1fa4985e4a4a8a92dc3206 Author: Pavel Ocheretny pochere...@src.gnome.org Date: Wed Jul 27 13:04:59 2011 +0300 Move SOAP calls to use EWS_EXCHANGE_2007_SP1. this patch is for QA mostly, s It fails to load the calendar with this error: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._e_2ddata_2dcal_2derror.Code113: Cannot open calendar: The EWS Id is in EwsLegacyId format which is not supported by the Exchange version specified by your request. Please use the ConvertId method to convert from EwsLegacyId to EwsId format. With the current git head, it just crashes in e_cal_backend_open(). James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] password storage problem with evolution calendar
I notice this most often with evolution-ews, but I have seen it with google calendar as well. The calendar basically loses its ability to retrieve stored passwords and has to keep asking for them every time. What's happening is that the uri= property in gconf has been reset to the base_uri, meaning that the password retriever no longer has a URI to parse to get the protocol, user and host name for finding the password. The calendar still works because it uses the hosturl property for attachment. I can fix the bug by replacing the uri= property with what I know it should be, but it's pretty annoying. Does anyone know what the problem might be? James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-ews timezone handling bug
Hi All, Now that I've got evolution-ews working with UTC, I noticed that we have another bug with the handling of timezones that don't do daylight savings (it's not just UTC ... you can see the same thing with America/Phoenix for the same reason). To See the bug, Just schedule 12 recurring monthly meetings in a no DST timezone. If you use OWA to view the first meeting after your native timezone shifts in or out of DST, you'll see that the meeting you created wrongly shifts with you. Note that the bug only happens with recurring meetings. If you schedule a single instance meeting across DST boundaries, it all comes out right. The reason for the email is that I'm not sure where the bug lies. Clearly the Exchange Server is adding DST rules where none are present. We send timezone information for non-DST timezones as MeetingTimezoneBaseOffset//MeetingTimeZone With no Standard/ or Daylight/ elements The best practises document http://msdn.microsoft.com/en-us/library/bb738399%28v=exchg.80%29.aspx Indicates that this is exactly the correct way to specify no DST zones (it even gives phoenix as an example). I'm connecting to exchange 2010, so could people with other exchange servers verify they also see this bug? and, if you see the bug, does Outlook share it and if not, what is outlook sending to the server for non-DST scheduled meetings? Thanks, James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [PATCH] evolution-ews: fix calendar failure when specifying UTC as the TimeZone
From: James Bottomley jbottom...@parallels.com
If you use evolution to specify an appointment in UTC, currently it
gets translated as native time in whatever timezone the exchange
server happens to be running.
The bug is that the UTC timezone has no properties, so the check for
standard properties in ewscal_set_timezone() fails. Fix by assuming
that if the timezone has no properties, it must be UTC.
Signed-off-by: James Bottomley jbottom...@parallels.com
diff --git a/src/calendar/e-cal-backend-ews-utils.c
b/src/calendar/e-cal-backend-ews-utils.c
index 7489bfd..933d426 100644
--- a/src/calendar/e-cal-backend-ews-utils.c
+++ b/src/calendar/e-cal-backend-ews-utils.c
@@ -228,10 +228,6 @@ void ewscal_set_timezone (ESoapMessage *msg, const gchar
*name, icaltimezone *ic
xstd = icalcomponent_get_first_component(comp,
ICAL_XSTANDARD_COMPONENT);
xdaylight = icalcomponent_get_first_component(comp,
ICAL_XDAYLIGHT_COMPONENT);
- /* Should never happen. RFC5545 requires at least one */
- if (!xstd !xdaylight)
- return;
-
/* If there was only a DAYLIGHT component, swap them over and pretend
it was the STANDARD component. We're only going to give the server
the BaseOffset anyway. */
@@ -252,8 +248,13 @@ void ewscal_set_timezone (ESoapMessage *msg, const gchar
*name, icaltimezone *ic
/* Fetch the timezone offsets for the standard (or only) zone.
Negate it, because Exchange does it backwards */
- prop = icalcomponent_get_first_property(xstd, ICAL_TZOFFSETTO_PROPERTY);
- std_utcoffs = -icalproperty_get_tzoffsetto(prop);
+ if (xstd) {
+ prop = icalcomponent_get_first_property(xstd,
ICAL_TZOFFSETTO_PROPERTY);
+ std_utcoffs = -icalproperty_get_tzoffsetto(prop);
+ } else {
+ /* UTC has no properties at all, so just set manually */
+ std_utcoffs = 0;
+ }
/* This is the overall BaseOffset tag, which the Standard and Daylight
zones are offset from. It's redundant, but Exchange always sets it
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [PATCH] evolution-ews: fix draft flag on sent items
From: James Bottomley jbottom...@parallels.com
What's happening currently is that the outlook web server shows all my
sent messages with a yellow banner wrongly saying This Message has
not been Sent.
The design of EWS is that you should append to folders with
MessageDisposition SaveOnly and send with SendAndSaveCopy. The
former always sets the IsDraft flag and the latter always clears it.
Unfortunately, the design of evolution precludes us from using
SendAndSaveCopy since evolution wants to send and then separately save
the sent email. Thus we need to modify SaveOnly to respect the
CAMEL_MESSAGE_DRAFT flag by setting the MAPI message flags.
I also removed the FIXME: comment about the From: field. This is
irrelevant to us, since EWS respects all the properties in the MIME
body (which include the From: field and the Importance: field).
Signed-off-by: James Bottomley jbottom...@parallels.com
diff --git a/src/utils/ews-camel-common.c b/src/utils/ews-camel-common.c
index 98e2b77..2f478b1 100644
--- a/src/utils/ews-camel-common.c
+++ b/src/utils/ews-camel-common.c
@@ -27,6 +27,7 @@
#include ews-camel-common.h
#include e-ews-compat.h
+#include e-ews-message.h
struct _create_mime_msg_data {
CamelMimeMessage *message;
@@ -34,6 +35,10 @@ struct _create_mime_msg_data {
CamelAddress *from;
};
+/* MAPI flags gleaned from windows header files */
+#define MAPI_MSGFLAG_READ 0x01
+#define MAPI_MSGFLAG_UNSENT0x08
+
static void
create_mime_message_cb (ESoapMessage *msg, gpointer user_data)
{
@@ -42,6 +47,7 @@ create_mime_message_cb (ESoapMessage *msg, gpointer user_data)
CamelMimeFilter *filter;
GByteArray *bytes;
gchar *base64;
+ int msgflag;
e_soap_message_start_element (msg, Message, NULL, NULL);
e_soap_message_start_element (msg, MimeContent, NULL, NULL);
@@ -78,8 +84,24 @@ create_mime_message_cb (ESoapMessage *msg, gpointer
user_data)
e_soap_message_end_element (msg); /* MimeContent */
- /* FIXME: Handle From address and message_camel_flags */
+ /* more MAPI crap. You can't just set the IsDraft property
+* here you have to use the MAPI MSGFLAG_UNSENT extended
+* property Further crap is that Exchange 2007 assumes when it
+* sees this property that you're setting the value to 0
+* ... it never checks */
+ msgflag = MAPI_MSGFLAG_READ; /* draft or sent is always read */
+ if (create_data-message_camel_flags CAMEL_MESSAGE_DRAFT)
+ msgflag |= MAPI_MSGFLAG_UNSENT;
+
+ e_soap_message_start_element (msg, ExtendedProperty, NULL, NULL);
+ e_soap_message_start_element (msg, ExtendedFieldURI, NULL, NULL);
+ e_soap_message_add_attribute (msg, PropertyTag, 0x0E07, NULL, NULL);
+ e_soap_message_add_attribute (msg, PropertyType, Integer, NULL,
NULL);
+ e_soap_message_end_element (msg); /* ExtendedFieldURI */
+
+ e_ews_message_write_int_parameter (msg, Value, NULL, msgflag);
+ e_soap_message_end_element (msg); /* ExtendedProperty */
e_soap_message_end_element (msg); /* Message */
g_free (create_data);
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [PATCH] ews-exchange: allow set/reset of Importance flag
From: James Bottomley jbottom...@parallels.com
When you have a lot of people who set the Importance flag to high on
all their incoming messages, it's useful to be able to reset it so
that only genuinely important messages remain flagged in your folders.
This patch implements the ability to set the Importance flag from
evolution.
Signed-off-by: James Bottomley jbottom...@parallels.com
diff --git a/src/camel/camel-ews-folder.c b/src/camel/camel-ews-folder.c
index d71f359..a169f3c 100644
--- a/src/camel/camel-ews-folder.c
+++ b/src/camel/camel-ews-folder.c
@@ -591,6 +591,27 @@ msg_update_flags (ESoapMessage *msg, gpointer user_data)
e_ews_message_start_item_change (msg,
E_EWS_ITEMCHANGE_TYPE_ITEM,
mi-info.uid, mi-change_key,
0);
+ if (flags_changed CAMEL_MESSAGE_FLAGGED) {
+ const char *flag;
+
+ if (mi-info.flags CAMEL_MESSAGE_FLAGGED)
+ flag = High;
+ else
+ flag = Normal;
+
+ e_soap_message_start_element (msg, SetItemField,
NULL, NULL);
+
+ e_soap_message_start_element (msg, FieldURI, NULL,
NULL);
+ e_soap_message_add_attribute (msg, FieldURI,
item:Importance, NULL, NULL);
+ e_soap_message_end_element (msg);
+
+ e_soap_message_start_element (msg, Message, NULL,
NULL);
+
+ e_ews_message_write_string_parameter (msg,
Importance, NULL, flag);
+
+ e_soap_message_end_element (msg); /* Message */
+ e_soap_message_end_element (msg); /* SetItemField */
+ }
if (flags_changed CAMEL_MESSAGE_SEEN) {
e_soap_message_start_element (msg, SetItemField,
NULL, NULL);
@@ -708,7 +729,7 @@ ews_synchronize_sync (CamelFolder *folder, gboolean
expunge, EVO3(GCancellable *
/* Exchange doesn't seem to have a sane representation
for most flags — not even replied/forwarded. */
- if (flags_changed
(CAMEL_MESSAGE_SEEN|CAMEL_MESSAGE_ANSWERED|CAMEL_MESSAGE_FORWARDED)) {
+ if (flags_changed
(CAMEL_MESSAGE_SEEN|CAMEL_MESSAGE_ANSWERED|CAMEL_MESSAGE_FORWARDED|CAMEL_MESSAGE_FLAGGED))
{
mi_list = g_slist_append (mi_list, mi);
mi_list_len++;
} else if (flags_changed CAMEL_MESSAGE_DELETED) {
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [PATCH v2] evolution-ews: implement Exchange categories as evolution labels
From: James Bottomley jbottom...@parallels.com
This patch adds evolution labels to an exchange back end via
outlook categories. The outlook categories perform roughly the
same function and evolution even mirrors their colour scheme.
This patch allows evolution to fill in the labels from the EWS
Category element. That means that any colour you add to a message via
the categories in outlook (or the outlook web server) automatically
appears in evolution and vice versa.
Signed-off-by: James Bottomley jbottom...@parallels.com
---
I suppose the label mapping is still going to be controversial, but I
don't see how to make it all just work (tm) without that. I've done
some reasonably extensive testing (and run into several sync issues,
which are now fixed).
James
diff --git a/src/camel/camel-ews-folder.c b/src/camel/camel-ews-folder.c
index 7e20fc2..d71f359 100644
--- a/src/camel/camel-ews-folder.c
+++ b/src/camel/camel-ews-folder.c
@@ -60,7 +60,7 @@ which needs to be better organized via functions */
#define MAX_ATTACHMENT_SIZE 1*1024*1024 /*In bytes*/
-#define SUMMARY_ITEM_FLAGS item:ResponseObjects item:Sensitivity
item:Importance
+#define SUMMARY_ITEM_FLAGS item:ResponseObjects item:Sensitivity
item:Importance item:Categories
#define ITEM_PROPS item:Subject item:DateTimeReceived item:DateTimeSent
item:DateTimeCreated item:Size \
item:HasAttachments item:InReplyTo
#define SUMMARY_ITEM_PROPS ITEM_PROPS SUMMARY_ITEM_FLAGS
@@ -638,6 +638,22 @@ msg_update_flags (ESoapMessage *msg, gpointer user_data)
e_soap_message_end_element (msg); /* Message */
e_soap_message_end_element (msg); /* SetItemField */
}
+ /* now update the Categories */
+ e_soap_message_start_element (msg, SetItemField, NULL, NULL);
+
+ e_soap_message_start_element (msg, FieldURI, NULL, NULL);
+ e_soap_message_add_attribute (msg, FieldURI,
item:Categories, NULL, NULL);
+ e_soap_message_end_element (msg);
+
+ e_soap_message_start_element (msg, Message, NULL, NULL);
+ e_soap_message_start_element (msg, Categories, NULL, NULL);
+
+ ews_utils_replace_server_user_flags(msg, mi);
+
+ e_soap_message_end_element (msg); /* Categories */
+ e_soap_message_end_element (msg); /* Message */
+ e_soap_message_end_element (msg); /* SetItemField */
+
e_ews_message_end_item_change (msg);
camel_message_info_free (mi);
@@ -698,7 +714,11 @@ ews_synchronize_sync (CamelFolder *folder, gboolean
expunge, EVO3(GCancellable *
} else if (flags_changed CAMEL_MESSAGE_DELETED) {
deleted_uids = g_slist_prepend (deleted_uids,
(gpointer) camel_pstring_strdup (uids-pdata [i]));
camel_message_info_free (mi);
- }
+ } else {
+ /* OK, the change must have been the labels */
+ mi_list = g_slist_append (mi_list, mi);
+ mi_list_len++;
+ }
if (mi_list_len == EWS_MAX_FETCH_COUNT) {
success = ews_sync_mi_flags (folder, mi_list,
cancellable, error);
@@ -1328,7 +1348,7 @@ camel_ews_folder_init (CamelEwsFolder *ews_folder)
folder-permanent_flags = CAMEL_MESSAGE_ANSWERED |
CAMEL_MESSAGE_DELETED |
CAMEL_MESSAGE_DRAFT | CAMEL_MESSAGE_FLAGGED |
CAMEL_MESSAGE_SEEN |
- CAMEL_MESSAGE_FORWARDED;
+ CAMEL_MESSAGE_FORWARDED | CAMEL_MESSAGE_USER;
folder-folder_flags = CAMEL_FOLDER_HAS_SUMMARY_CAPABILITY |
CAMEL_FOLDER_HAS_SEARCH_CAPABILITY;
diff --git a/src/camel/camel-ews-utils.c b/src/camel/camel-ews-utils.c
index dbddc52..481ae05 100644
--- a/src/camel/camel-ews-utils.c
+++ b/src/camel/camel-ews-utils.c
@@ -33,6 +33,7 @@
#include camel-ews-utils.h
#include ews-esource-utils.h
#include e-ews-compat.h
+#include e-ews-message.h
#define SUBFOLDER_DIR_NAME subfolders
#define SUBFOLDER_DIR_NAME_LEN 10
@@ -651,6 +652,86 @@ camel_ews_utils_sync_deleted_items (CamelEwsFolder
*ews_folder, GSList *items_de
g_slist_free (items_deleted);
}
+static const gchar*
+ews_utils_rename_label (const gchar *cat, int from_cat)
+{
+ gint i;
+
+ /* this is a mapping from Exchange/Outlook categories to
+* evolution labels based on the standard colours */
+ const gchar *labels[] = {
+ Red Category, $Labelimportant,
+ Orange Category, $Labelwork,
+ Green Category, $Labelpersonal,
+ Blue Category, $Labeltodo,
+ Purple Category, $Labellater,
+ NULL, NULL
+ };
+
+ if (!cat || !*cat)
+ return ;
+
+ for (i = 0; labels[i]; i += 2) {
+ if (from_cat
Re: [Evolution-hackers] evolution-ews connection problem
On Tue, 2011-07-05 at 10:36 -0500, James Bottomley wrote: On Tue, 2011-07-05 at 18:01 +0300, Ocheretny, Pavel wrote: On Tue, 2011-07-05 at 17:47 +0300, James Bottomley wrote: Well, as I said, they're both FC14 systems, so yes, the version on both is libsoup-2.32.2-1.fc14.i686 James Try to run EWS_DEBUG=2 evolution the send the log file Would you believe it wouldn't reproduce with EWS_DEBUG=2? Further, whatever it was is now fixed and it won't reproduce on the system with or without EWS_DEBUG set. I suspect it was some state file somewhere, since evolution wouldn't shut down cleanly either. I actually finally caught it, with logging turned on for a different reason. The trace is attached. James --- ** (evolution:27725): DEBUG: Loading Exchange EWS Plugin Construct the listener** (evolution:27725): DEBUG: Loading Exchange MAPI Plugin ** (evolution:27725): DEBUG: MAPI listener is constructed with 0 listed MAPI accounts Migrating cached data Migrating config data Migrating local user data mv /home/jejb/.evolution/mail/vfolder/folders.db /home/jejb/.local/share/evolution/mail/vfolder/folders.db FAILED: Destination file already exists rmdir /home/jejb/.evolution/mail/vfolder FAILED: Directory not empty (contents follows) folders.db rmdir /home/jejb/.evolution/tasks FAILED: Directory not empty (contents follows) tasks rmdir /home/jejb/.evolution/mail FAILED: Directory not empty (contents follows) custom_view-imap:__jbottomley@prv1-3.novell.com_INBOX.xml custom_view-imap:__jejb@192.168.10.143_pdx-conf.xml current_view-imap:__jejb@redscar_jobs.xml current_view-imap:__jejb@hancock_eng_20MRs.xml custom_view-imap:__jejb@redscar_other.xml custom_view-imap:__jejb@192.168.10.143_Mail_Archives_old-inbox-2008.xml current_view-imap:__clh15@redscar_IFISI.xml custom_view-imap:__jejb@192.168.10.143_Lists_linux-parisc.xml custom_view-imap:__jejb@redscar_kernel_20summit.xml custom_view-imap:__jbottom...@imap.suse.de_INBOX_linux-scsi.xml custom_view-imap:__jejb@192.168.10.143_kernel_20summit_20pc.xml current_view-imap:__jejb@redscar_linux-ide.xml custom_view-imap:__jejb@192.168.10.143_other.xml current_view-imap:__jejb@192.168.10.143_Drafts.xml current_view-imap:__jejb@192.168.10.143_Mail_Archives_linux-ide.xml current_view-imap:__jejb@hancock_linux-scsi.xml current_view-imap:__jbottomley@prv1-3.novell.com_drafts.xml custom_view-imap:__jbottom...@imap.suse.de_INBOX_linux-ide.xml custom_view-imap:__jejb@192.168.10.143_Linux_20Foundation_Tech_20Board.xml custom_view-imap:__jejb@172.17.4.18_OSDL_20Board.xml current_view-imap:__jbottomley@imap.novell.com_Calendar.xml current_view-mbox:_home_jejb_.evolution_mail_local_Sent.xml custom_view-imap:__jejb@redscar_INBOX.xml current_view-imap:__jejb@hancock_Sent.xml custom_view-imap:__jejb@192.168.10.143_Lists_pulseaudio.xml current_view-imap:__jbottomley@wal-1.novell.com_INBOX.xml custom_view-imap:__jejb@172.17.4.18_INBOX.xml custom_view-imap:__jejb@hancock_old-inbox-2005.xml current_view-imap:__jbottom...@imap.suse.de_INBOX_linux-scsi.xml custom_view-imap:__clh15@redscar_IFISI.xml custom_view-groupwise:__jbottomley@wal-1.novell.com_Mailbox.xml current_view-imap:__jejb@192.168.10.143_Mail_Archives_old-inbox-2008.xml current_view-imap:__clh15@192.168.10.143_INBOX.xml current_view-imap:__jejb@redscar_travel.xml custom_view-imap:__jejb@hancock_adverts.xml custom_view-imap:__jejb@redscar_jobs.xml galview.xml custom_view-imap:__jejb@redscar_linux-scsi.xml custom_view-imap:__jejb@redscar_Linux_20Foundation_Tech_20Board.xml custom_view-vfolder:_home_jejb_.evolution_mail_vfolder_All_20Account_20Search.xml current_view-imap:__jejb@redscar_other.xml custom_view-imap:__jejb@192.168.10.143_Mail_Archives_linux-scsi.xml current_view-imap:__jejb@redscar_Sent.xml current_view-imap:__jejb@192.168.10.143_Linux_20Foundation_Tech_20Board.xml custom_view-imap:__jejb@172.17.4.18_Sent.xml custom_view-imap:__jejb@192.168.10.143_Mail_Archives_old-inbox-2007.xml current_view-imap:__jejb@192.168.10.143_Linux_20Foundation_Board.xml current_view-imap:__jejb@192.168.10.143_other.xml current_view-mbox:_home_jejb_.evolution_mail_local#Outbox.xml current_view-imap:__jbottom...@imap.suse.de_INBOX_linux-ide.xml custom_view-imap:__jejb@redscar_spam.xml custom_view-imap:__jejb@192.168.10.143_Linux_20Foundation_Board.xml current_view-imap:__jejb@172.17.4.18_OSDL_20Board.xml custom_view-imap:__jejb
[Evolution-hackers] evolution-ews connection problem
This is a bit weird: I have two FC14 systems both connecting identically (the evolution configuration is actually cloned between them). One connects just fine, but the other won't do the initial mailbox scan. The log is full of (evolution:2589): libsoup-CRITICAL **: soup_session_get_connection: assertion `soup_connection_get_state (item-conn) != SOUP_CONNECTION_DISCONNECTED' failed If I click on an individual mailbox, then it will refresh it, but it doesn't happen automatically. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-ews connection problem
On Tue, 2011-07-05 at 18:01 +0300, Ocheretny, Pavel wrote: On Tue, 2011-07-05 at 17:47 +0300, James Bottomley wrote: Well, as I said, they're both FC14 systems, so yes, the version on both is libsoup-2.32.2-1.fc14.i686 James Try to run EWS_DEBUG=2 evolution the send the log file Would you believe it wouldn't reproduce with EWS_DEBUG=2? Further, whatever it was is now fixed and it won't reproduce on the system with or without EWS_DEBUG set. I suspect it was some state file somewhere, since evolution wouldn't shut down cleanly either. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)
On Mon, 2011-06-27 at 13:22 +0100, David Woodhouse wrote: On Mon, 2011-05-23 at 16:55 +0400, James Bottomley wrote: I kid you not. You can see this just by going to your own outlook web server (when you highlight a message, you'll see an empty tall oblong, click and it will bring up the categories). Exchange allows arbitrary labels (like we do), but the default ones are Blue, Green, Orange, Purple, Red and Yellow. Evolution has label mappings for everything apart from Yellow. I figured we should map default to default. I don't really like mapping 'Red' to 'Important', etc. I was just doing a mapping of what seems to be intended. This is also what the imap camel plugin does (except it maps $label1 - important etc.) Given that we support arbitrary labels on both sides, I think the best solution is to synchronise the set of labels. If we see a label on an Exchange message which isn't already known in Evolution, *add* it to Evolution's list. And if we're trying to add a label to an Exchange item which isn't already known on the Exchange side, add it there too. I don't think we can ... at least it's an invasive change. There doesn't seem to be a way to show arbitrary labels. The plugins have a label map, which is partly provider supplied and partly user supplied (if the provider allows user labels). If the imap server comes across a label it doesn't have a map for, it just ignores it ... This keeps biting me because I use a custom patch label in my mailboxes for my git workflow. When I move to a new machine, I always have a WTF where are my patches moment ... until I remember to add the label mapping. James ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)
This patch is a proof of concept for adding evolution labels to an
exchange back end. The outlook categories perform roughly the same
function, and evolution even mirrors their colour scheme.
This patch allows evolution to fill in the labels from the EWS
Category element. That means that any colour you add to a message via
the categories in outlook (or the outlook web server) automatically
appears in evolution.
The next phase will be to allow evolution to modify the categories.
Signed-off-by: James Bottomley james.bottom...@parallels.com
diff --git a/src/camel/camel-ews-folder.c b/src/camel/camel-ews-folder.c
index cd5ac7c..af0753a 100644
--- a/src/camel/camel-ews-folder.c
+++ b/src/camel/camel-ews-folder.c
@@ -59,7 +59,7 @@ which needs to be better organized via functions */
#define MAX_ATTACHMENT_SIZE 1*1024*1024 /*In bytes*/
-#define SUMMARY_ITEM_FLAGS item:ResponseObjects item:Sensitivity
item:Importance
+#define SUMMARY_ITEM_FLAGS item:ResponseObjects item:Sensitivity
item:Importance item:Categories
#define ITEM_PROPS item:Subject item:DateTimeReceived item:DateTimeSent
item:DateTimeCreated item:Size \
item:HasAttachments item:InReplyTo
#define SUMMARY_ITEM_PROPS ITEM_PROPS SUMMARY_ITEM_FLAGS
@@ -1301,7 +1301,7 @@ camel_ews_folder_init (CamelEwsFolder *ews_folder)
folder-permanent_flags = CAMEL_MESSAGE_ANSWERED |
CAMEL_MESSAGE_DELETED |
CAMEL_MESSAGE_DRAFT | CAMEL_MESSAGE_FLAGGED |
CAMEL_MESSAGE_SEEN |
- CAMEL_MESSAGE_FORWARDED;
+ CAMEL_MESSAGE_FORWARDED | CAMEL_MESSAGE_USER;
folder-folder_flags = CAMEL_FOLDER_HAS_SUMMARY_CAPABILITY |
CAMEL_FOLDER_HAS_SEARCH_CAPABILITY;
diff --git a/src/camel/camel-ews-utils.c b/src/camel/camel-ews-utils.c
index d983130..83057ac 100644
--- a/src/camel/camel-ews-utils.c
+++ b/src/camel/camel-ews-utils.c
@@ -651,6 +651,58 @@ camel_ews_utils_sync_deleted_items (CamelEwsFolder
*ews_folder, GSList *items_de
g_slist_free (items_deleted);
}
+static const gchar*
+ews_utils_rename_label(const gchar *cat)
+{
+ gint i;
+
+ /* this is a mapping from Exchange/Outlook categories to
+* evolution labels based on the standard colours */
+ const gchar *labels[] = {
+ Red Category, $Labelimportant,
+ Orange Category, $Labelwork,
+ Green Category, $Labelpersonal,
+ Blue Category, $Labeltodo,
+ Purple Category, $Labellater,
+ NULL, NULL
+ };
+
+ if (!cat || !*cat)
+ return ;
+
+ for (i = 0; labels[i]; i += 2) {
+ if (!g_ascii_strcasecmp (cat, labels[i]))
+ return labels[i + 1];
+ }
+ return cat;
+}
+
+static void
+ews_utils_merge_server_user_flags (EEwsItem *item, CamelEwsMessageInfo *mi)
+{
+ GSList *list = NULL;
+ const GSList *p;
+ const CamelFlag *flag;
+
+ /* transfer camel flags to a list */
+ for (flag = camel_message_info_user_flags (mi-info); flag;
+flag = flag-next)
+ list = g_slist_append(list, (gchar *)flag-name);
+
+ /* we're transferring from server only, so just dump them */
+ for (p = list; p; p = p-next) {
+ camel_flag_set(mi-info.user_flags, p-data, 0);
+ }
+ //g_slist_foreach(list, (GFunc)g_free, NULL);
+ g_slist_free(list);
+
+ /* now transfer over all the categories */
+ for (p = e_ews_item_get_categories (item); p; p = p-next) {
+ camel_flag_set(mi-info.user_flags,
+ ews_utils_rename_label(p-data), 1);
+ }
+}
+
static gint
ews_utils_get_server_flags (EEwsItem *item)
{
@@ -833,8 +885,9 @@ camel_ews_utils_sync_updated_items (CamelEwsFolder
*ews_folder, GSList *items_up
gint server_flags;
server_flags = ews_utils_get_server_flags (item);
+ ews_utils_merge_server_user_flags (item, mi);
if (camel_ews_update_message_info_flags
(folder-summary, (CamelMessageInfo *)mi,
- server_flags, NULL))
+server_flags,
NULL))
camel_folder_change_info_change_uid (ci,
mi-info.uid);
mi-change_key = g_strdup (id-change_key);
diff --git a/src/server/e-ews-item.c b/src/server/e-ews-item.c
index fd42ea9..9787958 100644
--- a/src/server/e-ews-item.c
+++ b/src/server/e-ews-item.c
@@ -169,6 +169,12 @@ struct _EEwsItemPrivate {
EwsId *associated_calendar_item_id;
+ /* the evolution labels are implemented as exchange
+* Categories. These appear in the message headers as
+* Keywords: and are set and extracted from the EWS server as
+* Categories which is a string array valued XML element */
+ GSList *categories
Re: [Evolution-hackers] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)
On Mon, 2011-05-23 at 12:19 +0100, David Woodhouse wrote:
On Mon, 2011-05-23 at 14:41 +0400, James Bottomley wrote:
+
+ /* this is a mapping from Exchange/Outlook categories to
+* evolution labels based on the standard colours */
+ const gchar *labels[] = {
+ Red Category, $Labelimportant,
+ Orange Category, $Labelwork,
+ Green Category, $Labelpersonal,
+ Blue Category, $Labeltodo,
+ Purple Category, $Labellater,
+ NULL, NULL
+ };
That's the only reason I might *not* want to apply your patch
immediately, right?
Is there a correct way to handle the mapping? Does Exchange really
just store them by colour?
I kid you not.
You can see this just by going to your own outlook web server (when you
highlight a message, you'll see an empty tall oblong, click and it will
bring up the categories).
Exchange allows arbitrary labels (like we do), but the default ones are
Blue, Green, Orange, Purple, Red and Yellow. Evolution has label
mappings for everything apart from Yellow. I figured we should map
default to default.
James
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)
On Mon, 2011-05-23 at 14:21 +0200, Milan Crha wrote: On Mon, 2011-05-23 at 14:41 +0400, James Bottomley wrote: This patch ... Hi, could you use Gnome's bugzilla for patch reviews, please? Consider this more an RFC requiring feedback than a patch requiring review. James It has couple reasons why: a) bugzilla is meant for that b) bugzilla has integrated tools for patches and their review c) it's easier to follow (broken) commit with bugzilla reference than with some mailing list message to which the reference cannot be added such easily like a bug reference. Basically all the tools used in Gnome are ready and capable of bugzilla and makes life much easier when it is used, especially the part with commits and git and so on. There used to be evolution-patches message list, but it was dropped because the history showed it as an unusable medium for patch submission. That's how I understood it. Thanks and bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
