From jane at janeatkinson.co.nz Sun Mar 2 08:07:41 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Sun, 2 Mar 2014 21:07:41 +1300 Subject: [SyncEvolution] Some events showing wrong time on phone Message-ID: <5312E6CD.4070704@janeatkinson.co.nz> I'm running syncevolution 1.4 on Xubuntu 14.04. My local timezone is Pacific/Auckland. There have been no changes to Daylight Savings start/end dates for something like seven years. For events dated between 16 March and 5 April (final three weeks of NZDT), if the timezone is set to Pacific/Auckland on the server, the times on my E63 phone are one hour ahead after syncing. That is, they are 14 hours ahead of UTC instead of 13. But if I change the timezone for an event on the server to UTC, the correct time (13 hours ahead) shows on the phone after syncing. I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see if the problem occurs there. It doesn't. I'd like to report a bug, but I have no idea which package to report it against. Does anyone have any ideas? Jane Atkinson _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Mar 2 12:31:00 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 02 Mar 2014 13:31:00 +0100 Subject: [SyncEvolution] Some events showing wrong time on phone In-Reply-To: <5312E6CD.4070704@janeatkinson.co.nz> References: <5312E6CD.4070704@janeatkinson.co.nz> Message-ID: <1393763460.16577.5.camel@pohly-mobl1.fritz.box> On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: > I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see > if the problem occurs there. It doesn't. Interesting. SyncEvolution uses system timezone data parsed by libical. There could be a difference between libical 1.0 (in Xubuntu 14.04) and older libical (Ubuntu 12.04.4) and/or in the timezone data itself. > I'd like to report a bug, but I have no idea which package to report it > against. Does anyone have any ideas? A good start would be a syncevolution-log.html at loglevel=4 showing how SyncEvolution transfers one event with Pacific/Auckland timezone to the phone. That'll show how the timezones were defined in the event on the server, internally, and in the data sent to the phone. Doing the same on Ubuntu 12.04.4 would also be helpful as reference for a "good" sync. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From jane at janeatkinson.co.nz Mon Mar 3 02:47:38 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Mon, 3 Mar 2014 15:47:38 +1300 Subject: [SyncEvolution] Some events showing wrong time on phone In-Reply-To: <1393763460.16577.5.camel@pohly-mobl1.fritz.box> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> Message-ID: <5313ED4A.1040001@janeatkinson.co.nz> On 03/03/14 01:31, Patrick Ohly wrote: > On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: >> I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see >> if the problem occurs there. It doesn't. > Interesting. SyncEvolution uses system timezone data parsed by libical. > There could be a difference between libical 1.0 (in Xubuntu 14.04) and > older libical (Ubuntu 12.04.4) and/or in the timezone data itself. It looks as though libical1 may be the culprit. I installed libical0 and removed libical1. A test event synced correctly. Then replaced libical0 with libical1 and synced a second test event. The error occurred with this one. >> I'd like to report a bug, but I have no idea which package to report it >> against. Does anyone have any ideas? > A good start would be a syncevolution-log.html at loglevel=4 showing how > SyncEvolution transfers one event with Pacific/Auckland timezone to the > phone. That'll show how the timezones were defined in the event on the > server, internally, and in the data sent to the phone. > > Doing the same on Ubuntu 12.04.4 would also be helpful as reference for > a "good" sync. > Do I still need to do this in both (X)ubuntu versions, or would it suffice to do it with the two different libical versions (which would be a lot simpler)? Jane Atkinson _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Mon Mar 3 08:17:42 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 03 Mar 2014 09:17:42 +0100 Subject: [SyncEvolution] Some events showing wrong time on phone In-Reply-To: <5313ED4A.1040001@janeatkinson.co.nz> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> <5313ED4A.1040001@janeatkinson.co.nz> Message-ID: <1393834662.16577.6.camel@pohly-mobl1.fritz.box> On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote: > On 03/03/14 01:31, Patrick Ohly wrote: > > On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: > >> I'd like to report a bug, but I have no idea which package to report it > >> against. Does anyone have any ideas? > > A good start would be a syncevolution-log.html at loglevel=4 showing how > > SyncEvolution transfers one event with Pacific/Auckland timezone to the > > phone. That'll show how the timezones were defined in the event on the > > server, internally, and in the data sent to the phone. > > > > Doing the same on Ubuntu 12.04.4 would also be helpful as reference for > > a "good" sync. > > > Do I still need to do this in both (X)ubuntu versions, or would it > suffice to do it with the two different libical versions (which would be > a lot simpler)? Two different libical versions on the same system is good enough. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From jane at janeatkinson.co.nz Tue Mar 4 02:04:04 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Tue, 4 Mar 2014 15:04:04 +1300 Subject: [SyncEvolution] Some events showing wrong time on phone In-Reply-To: <1393834662.16577.6.camel@pohly-mobl1.fritz.box> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> <5313ED4A.1040001@janeatkinson.co.nz> <1393834662.16577.6.camel@pohly-mobl1.fritz.box> Message-ID: <53153494.5020506@janeatkinson.co.nz> On 03/03/14 21:17, Patrick Ohly wrote: > On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote: >> Do I still need to do this in both (X)ubuntu versions, or would it >> suffice to do it with the two different libical versions (which would >> be a lot simpler)? > Two different libical versions on the same system is good enough. > I've run the tests. Where do I send the logs? Jane Atkinson From patrick.ohly at intel.com Fri Mar 7 15:50:57 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Fri, 07 Mar 2014 16:50:57 +0100 Subject: [SyncEvolution] Some events showing wrong time on phone In-Reply-To: <5313ED4A.1040001@janeatkinson.co.nz> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> <5313ED4A.1040001@janeatkinson.co.nz> Message-ID: <1394207457.5750.110.camel@pohly-mobl1.fritz.box> On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote: > > On 03/03/14 01:31, Patrick Ohly wrote: > > On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: > >> I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see > >> if the problem occurs there. It doesn't. > > Interesting. SyncEvolution uses system timezone data parsed by libical. > > There could be a difference between libical 1.0 (in Xubuntu 14.04) and > > older libical (Ubuntu 12.04.4) and/or in the timezone data itself. > > It looks as though libical1 may be the culprit. > > I installed libical0 and removed libical1. A test event synced correctly. > > Then replaced libical0 with libical1 and synced a second test event. The > error occurred with this one. The logs that Jane sent me show a major difference between libical0 and libical1: libical1 includes information about historic summer saving times. This seems to break the mapping of CalDAV even timezones to internal timezones extracted from libical such that the phone gets an event in New_Zealand timezone (probably from libsynthesis itself) with outdated information (?). libical0: TZ:+12:00 DAYLIGHT:TRUE;+13;20140927T140000Z;20150404T140000Z;NZST;NZDT libical1: TZ:+12:00 DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+13;20141004T140000Z;20150= 314T140000Z;New_Zealand;New_Zealand I still need to dig deeper into this to determine why the libical information is no longer used. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Tue Mar 11 12:29:28 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 11 Mar 2014 13:29:28 +0100 Subject: [SyncEvolution] Some events showing wrong time on phone - libical 1.0 In-Reply-To: <5313ED4A.1040001@janeatkinson.co.nz> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> <5313ED4A.1040001@janeatkinson.co.nz> Message-ID: <1394540968.8343.17.camel@pohly-mobl1.fritz.box> On Mon, 2014-03-03 at 15:47 +1300, Jane Atkinson wrote: > > On 03/03/14 01:31, Patrick Ohly wrote: > > On Sun, 2014-03-02 at 21:07 +1300, Jane Atkinson wrote: > >> I fired up my old copy of Ubuntu 12.04.4, updated it and tested to see > >> if the problem occurs there. It doesn't. > > Interesting. SyncEvolution uses system timezone data parsed by libical. > > There could be a difference between libical 1.0 (in Xubuntu 14.04) and > > older libical (Ubuntu 12.04.4) and/or in the timezone data itself. > > It looks as though libical1 may be the culprit. The new behavior of libical1 is not really faulty. It now returns VTIMEZONE definitions which have multiple DAYLIGHT/STANDARD components instead of trying to combine those into one DAYLIGHT and STANDARD component with a suitable RRULE. The advantage is that the VTIMEZONE is now correct in all cases (the old code had issues). This was the motivation for the change, see: https://sourceforge.net/p/freeassociation/code/1130 http://sourceforge.net/p/freeassociation/bugs/76/ http://sourceforge.net/p/freeassociation/bugs/34/ The disadvantage is that not all peers and users of libical can handle this. This also caused problems in Evolution, which caused a bug report against libical asking for the old behavior to be restored: https://bugzilla.gnome.org/show_bug.cgi?id=708143 https://sourceforge.net/p/freeassociation/bugs/95/ In the case of SyncEvolution, the libical VTIMEZONEs can't be used without the RRULEs, and the fallback for New Zealand is out-dated, causing the issue currently discussed. I also expect that interoperability with peers like Google CalDAV will be affected. I am not sure what solution I can offer to SyncEvolution users. Ideally, some volunteer should implement the proposal in https://sourceforge.net/p/freeassociation/bugs/95/ -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Mar 26 17:08:49 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 26 Mar 2014 18:08:49 +0100 Subject: [SyncEvolution] Some events showing wrong time on phone - libical 1.0 In-Reply-To: <1394540968.8343.17.camel@pohly-mobl1.fritz.box> References: <5312E6CD.4070704@janeatkinson.co.nz> <1393763460.16577.5.camel@pohly-mobl1.fritz.box> <5313ED4A.1040001@janeatkinson.co.nz> <1394540968.8343.17.camel@pohly-mobl1.fritz.box> Message-ID: <1395853729.2442.76.camel@pohly-mobl1.fritz.box> On Tue, 2014-03-11 at 13:29 +0100, Patrick Ohly wrote: > I am not sure what solution I can offer to SyncEvolution users. Ideally, > some volunteer should implement the proposal in > https://sourceforge.net/p/freeassociation/bugs/95/ As an interim solution (which, as these things tend to go, will probably be with us for a long time) I am going to copy the relevant code libical 0.x into SyncEvolution and ensure that libsynthesis picks up that code to populate its timezone database. That should fix the issue of syncing. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From chingupt at gmail.com Tue Mar 11 17:53:55 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Tue, 11 Mar 2014 23:23:55 +0530 Subject: DevInf sent to Server again in fast sync Message-ID: Hi Patrick, Once a handset is registered with the server, does the handset still have to send the DevInf again to the Server in subsequent Sync Operations? Currently when syncing, syncevolution sends the DevInf again to the server even though it has in the previous sync operation. Can this be controlled or is it the expected behaviour? Regards Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.ohly at intel.com Tue Mar 11 20:36:32 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Tue, 11 Mar 2014 21:36:32 +0100 Subject: DevInf sent to Server again in fast sync In-Reply-To: References: Message-ID: <1394570192.8343.24.camel@pohly-mobl1.fritz.box> On Tue, 2014-03-11 at 23:23 +0530, Sachin Gupta wrote: > Once a handset is registered with the server, does the handset still > have to send the DevInf again to the Server in subsequent Sync > Operations? It only has to send the DevInf again if it has changed or the server asks for it with a Get request. > Currently when syncing, syncevolution sends the DevInf again to the > server even though it has in the previous sync operation. Can this be > controlled or is it the expected behaviour? It cannot be controlled by SyncEvolution; libsynthesis implements the behavior described automatically. Check the syncevolution-log.html file and search for DevInf. That should tell you why the library sends DevInf. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From chingupt at gmail.com Wed Mar 12 00:52:25 2014 From: chingupt at gmail.com (Sachin Gupta) Date: Wed, 12 Mar 2014 06:22:25 +0530 Subject: DevInf sent to Server again in fast sync In-Reply-To: <1394570192.8343.24.camel@pohly-mobl1.fritz.box> References: <1394570192.8343.24.camel@pohly-mobl1.fritz.box> Message-ID: Thanks patrick. Regards On Mar 12, 2014 2:06 AM, "Patrick Ohly" wrote: > On Tue, 2014-03-11 at 23:23 +0530, Sachin Gupta wrote: > > > Once a handset is registered with the server, does the handset still > > have to send the DevInf again to the Server in subsequent Sync > > Operations? > > It only has to send the DevInf again if it has changed or the server > asks for it with a Get request. > > > Currently when syncing, syncevolution sends the DevInf again to the > > server even though it has in the previous sync operation. Can this be > > controlled or is it the expected behaviour? > > It cannot be controlled by SyncEvolution; libsynthesis implements the > behavior described automatically. Check the syncevolution-log.html file > and search for DevInf. That should tell you why the library sends > DevInf. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jane at janeatkinson.co.nz Sat Mar 8 23:07:21 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Sun, 9 Mar 2014 12:07:21 +1300 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <52ED73AE.40402@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> Message-ID: <531BA2A9.1080704@janeatkinson.co.nz> On 02/02/14 11:22, Jane Atkinson wrote: > > On 02/02/14 02:04, Patrick Ohly wrote: >> On Sat, 2014-02-01 at 16:36 +1300, Jane Atkinson wrote: >>> From time to time, I need to change the date, but not the time, of an >>> appointment. When I do this, the change is not being propagated to the >>> client. If I change the time of an appointment, the change is propagated >>> correctly. >>> >>> I'm running syncevolution 1.3.99.7 on Xubuntu 14.04 (pre-release). The >>> client is a Nokia E63. The configuration type is webdav. Evolution is >>> not installed on this system. >>> >>> I'm not sure exactly when this started happening, but I think it's of >>> recent origin. No configuration options have been changed for a long time. >>> >>> Please let me know where to send the logs. Also, any further tests I can do. >> Send me a syncevolution-log.html created with loglevel=4 where a change >> should be transmitted and doesn't get transmitted to >> patrick.ohly at intel.com. Please identify the event (say, by quoting its >> description). >> > Strange... I set log-level=4 in ~/.config/syncevolution/config.ini. Then > the test event synced correctly when I ran the sync! > > On reverting log-level to the default (commented out in config.ini) the > sync is still working correctly with changed dates, both on new and > existing events. > > I'll keep watching it and if the problem recurs I'll send a log. > > > Probably not connected with this behaviour, but I regularly see an error > message: > [ERROR] GLib: Source ID 9 was not found when attempting to remove it > > Usually it's ID 9 but occasionally is another number. > > Regards > > Jane Atkinson > > > _______________________________________________ > SyncEvolution mailing list > SyncEvolution at syncevolution.org > https://lists.syncevolution.org/mailman/listinfo/syncevolution > > Update: I've determined that this is another error induced by using libical1. If I use libical0, then there are no problems with this. This would explain why the problem suddenly disappeared - libical wasn't on my radar at the time. Jane Atkinson _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From patrick.ohly at intel.com Sun Mar 9 19:39:22 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Sun, 09 Mar 2014 20:39:22 +0100 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <531BA2A9.1080704@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <531BA2A9.1080704@janeatkinson.co.nz> Message-ID: <1394393962.5750.131.camel@pohly-mobl1.fritz.box> On Sun, 2014-03-09 at 12:07 +1300, Jane Atkinson wrote: > I've determined that this is another error induced by using libical1. If > I use libical0, then there are no problems with this. This would explain > why the problem suddenly disappeared - libical wasn't on my radar at the > time. It is a bit harder to see how libical behavior may cause a modified event to not sync. Last time you said that you failed to reproduce the problem - was that because you were unintentionally using libical0? If you can reproduce it now, can you send me logs at loglevel=4 with libical0 (modified event synced okay) and libical1 (modified event not synced)? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From jane at janeatkinson.co.nz Sun Mar 9 20:20:59 2014 From: jane at janeatkinson.co.nz (Jane Atkinson) Date: Mon, 10 Mar 2014 09:20:59 +1300 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <1394393962.5750.131.camel@pohly-mobl1.fritz.box> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <531BA2A9.1080704@janeatkinson.co.nz> <1394393962.5750.131.camel@pohly-mobl1.fritz.box> Message-ID: <531CCD2B.8070305@janeatkinson.co.nz> On 10/03/14 08:39, Patrick Ohly wrote: > On Sun, 2014-03-09 at 12:07 +1300, Jane Atkinson wrote: >> I've determined that this is another error induced by using libical1. If >> I use libical0, then there are no problems with this. This would explain >> why the problem suddenly disappeared - libical wasn't on my radar at the >> time. > It is a bit harder to see how libical behavior may cause a modified > event to not sync. Last time you said that you failed to reproduce the > problem - was that because you were unintentionally using libical0? > > If you can reproduce it now, can you send me logs at loglevel=4 with > libical0 (modified event synced okay) and libical1 (modified event not > synced)? > That is what I strongly suspect - that I'd changed the libical version and not realised that it was having any effect. I did a couple of tests yesterday with the two different libical versions, which showed different behaviour each time. I'll get some tests done soon, but not quite sure whether it will be today. Jane Atkinson From patrick.ohly at intel.com Mon Mar 10 12:10:51 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Mon, 10 Mar 2014 13:10:51 +0100 Subject: [SyncEvolution] Calendar entries not syncing when date changed In-Reply-To: <531CCD2B.8070305@janeatkinson.co.nz> References: <52EC6BBD.1060604@janeatkinson.co.nz> <1391259852.30349.203.camel@pohly-mobl1.fritz.box> <52ED73AE.40402@janeatkinson.co.nz> <531BA2A9.1080704@janeatkinson.co.nz> <1394393962.5750.131.camel@pohly-mobl1.fritz.box> <531CCD2B.8070305@janeatkinson.co.nz> Message-ID: <1394453451.5750.151.camel@pohly-mobl1.fritz.box> On Mon, 2014-03-10 at 09:20 +1300, Jane Atkinson wrote: > > On 10/03/14 08:39, Patrick Ohly wrote: > > On Sun, 2014-03-09 at 12:07 +1300, Jane Atkinson wrote: > >> I've determined that this is another error induced by using libical1. If > >> I use libical0, then there are no problems with this. This would explain > >> why the problem suddenly disappeared - libical wasn't on my radar at the > >> time. > > It is a bit harder to see how libical behavior may cause a modified > > event to not sync. Last time you said that you failed to reproduce the > > problem - was that because you were unintentionally using libical0? > > > > If you can reproduce it now, can you send me logs at loglevel=4 with > > libical0 (modified event synced okay) and libical1 (modified event not > > synced)? > > > That is what I strongly suspect - that I'd changed the libical version > and not realised that it was having any effect. I did a couple of tests > yesterday with the two different libical versions, which showed > different behaviour each time. > > I'll get some tests done soon, but not quite sure whether it will be today. Thanks for the logs. It shows that the updated item with libical1 is sent to the phone and then phone rejects it with a very unspecific error. This may very well be because of the timezone definition, so it makes sense to fix that first and then check again. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From patrick.ohly at intel.com Wed Mar 5 10:16:43 2014 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 05 Mar 2014 11:16:43 +0100 Subject: [SyncEvolution] Fix build failure with eglibc 2.18 In-Reply-To: <20140224112605.GA1655@mac.home> References: <20140224112605.GA1655@mac.home> Message-ID: <1394014603.5750.30.camel@pohly-mobl1.fritz.box> On Mon, 2014-02-24 at 12:26 +0100, Tino Mettler wrote: > Hi, > > syncevolution 1.4 fails to build with glibc headers from eglibc 2.18 in > Debian Sid. Attatched is a patch. Thanks, merged into master. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.