From butirsky at gmail.com Wed Feb 14 11:58:02 2018 From: butirsky at gmail.com (Andrey Butirsky) Date: Wed, 14 Feb 2018 14:58:02 +0300 Subject: [SyncEvolution] KDE5 support In-Reply-To: <20180105210605.GA14292@mac.home> References: <20180105210605.GA14292@mac.home> Message-ID: Hi, is there any source code I could compile to get KDE5 port of the syncevolution akonadi plugin? I'm on Slackware so can't try the Debian package. _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From tino.keitel+syncevolution at tikei.de Wed Feb 14 19:11:15 2018 From: tino.keitel+syncevolution at tikei.de (Tino Mettler) Date: Wed, 14 Feb 2018 20:11:15 +0100 Subject: [SyncEvolution] KDE5 support In-Reply-To: References: <20180105210605.GA14292@mac.home> Message-ID: <20180214191115.GA14952@mac.home> On Wed, Feb 14, 2018 at 14:58:02 +0300, Andrey Butirsky wrote: > Hi, > > is there any source code I could compile to get KDE5 port of the > syncevolution akonadi plugin? Hi, I started a port, but got stuck in RL. Currently I have some half-finished version that compiles, but kwallet is disabled and no KDE libs are used by the result, so I guess it doesn't do something useful. Regards, Tino _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From butirsky at gmail.com Wed Feb 14 20:01:55 2018 From: butirsky at gmail.com (Andrey) Date: Wed, 14 Feb 2018 23:01:55 +0300 Subject: [SyncEvolution] KDE5 support In-Reply-To: <20180214191115.GA14952@mac.home> References: <20180105210605.GA14292@mac.home> <20180214191115.GA14952@mac.home> Message-ID: <5822EE70-04F4-4438-BE43-197EF599B589@gmail.com> OK, thanks anyway On February 14, 2018 10:11:15 PM GMT+03:00, Tino Mettler wrote: >On Wed, Feb 14, 2018 at 14:58:02 +0300, Andrey Butirsky wrote: >> Hi, >> >> is there any source code I could compile to get KDE5 port of the >> syncevolution akonadi plugin? > >Hi, > >I started a port, but got stuck in RL. Currently I have some >half-finished version that compiles, but kwallet is disabled and no KDE >libs are used by the result, so I guess it doesn't do something useful. > >Regards, >Tino >_______________________________________________ >SyncEvolution mailing list >SyncEvolution at syncevolution.org >https://lists.syncevolution.org/mailman/listinfo/syncevolution -- Sent from my Android device with K-9 Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ SyncEvolution mailing list SyncEvolution at syncevolution.org https://lists.syncevolution.org/mailman/listinfo/syncevolution From alain at knaff.lu Mon Feb 12 09:35:10 2018 From: alain at knaff.lu (Alain Knaff) Date: Mon, 12 Feb 2018 10:35:10 +0100 Subject: Syncevolution chokes on one calendar entry, doesn't say which, doesn't allow to skip, doesn't show actual server's complaint Message-ID: <62037096-81ff-04e3-5177-4b84605954a7@knaff.lu> Hi, When trying to use synccalendar, I occasionally get the following: [INFO @aev] operation temporarily (?) failed, going to retry in 5.0s before giving up in 298.7s: REPORT 'check for items': bad HTTP status: And then repeats the message with ever growing delays. Apparently, sync-evolution or the server doesn't like a certain calendar entry, and rather than move on to the next, just gets stuck on it. Sometimes killing syncevolution, and then starting it again fixes the issue, and sometimes not. Btw, to kill syncevolution, just using Ctrl-C doesn't do the job, you've actually got to use the kill command from another terminal session, or use Ctrl-Z and then kill. May I suggest three small changes to make this issue much less painful: 1. When such a thing occurs, actually say *which* calendar entry causes this. For most practical cases date, time and title should be enough to uniquely identify the entry and allow the user to "manually" transfer it (i.e. manually delete it on phone, manually change/create it on server, and sync it back), or even to allow him to understand what is causing this. 2. The message just echoes the HTTP Status line, and not the rest of the contents of the server's error page. Maybe the server (MS Exchange via davmail) does indeed explain what's the issue with that calendar entry? Bad status? Bad Reminder options? etc.? Impossible to know easily, as nowadays most server use HTTPs and so even tcpdump wouldn't be any help. 3. Rather than just retrying forever, syncevolution should skip over the entry, move on to the next, and repeat in the final summary message that such-and-such entry was skipped (and identify the entry as described in point 1) Other question: I run syncevolution on a BQ Aquaris E5 phone with Ubuntu Touch. Ubuntu no longer supports touch, however, and apt-get upgrade has stopped working for a while. So I'm stuck at version 1.5.1+15.04.20160706-0ubuntu1 However, UBports has taken up this task, and I suppose they've got a repository somewhere from which to get updates from them. Unfortunately there site is silent on that issue, and only describes how to install ubports from scratch on a new device, and not how to upgrade an existing Ubuntu touch device. Do you by chance know what to enter into /etc/apt/sources.list to get updates from UBports rather than from Ubuntu? Third question: due to this whole dropped support issue, I'm in the market for a new phone, and it will either be stock Android or Lineage OS (due to current lack of other Linux alternatives :-( ). Does syncevolution work on these two OS'es? Thanks, Alain From patrick.ohly at intel.com Wed Feb 14 09:59:33 2018 From: patrick.ohly at intel.com (Patrick Ohly) Date: Wed, 14 Feb 2018 10:59:33 +0100 Subject: Syncevolution chokes on one calendar entry, doesn't say which, doesn't allow to skip, doesn't show actual server's complaint In-Reply-To: <62037096-81ff-04e3-5177-4b84605954a7@knaff.lu> References: <62037096-81ff-04e3-5177-4b84605954a7@knaff.lu> Message-ID: <1518602373.25947.52.camel@intel.com> On Mon, 2018-02-12 at 10:35 +0100, Alain Knaff wrote: > Hi, > > When trying to use synccalendar, I occasionally get the following: > > [INFO @aev] operation temporarily (?) failed, going to retry in 5.0s > before giving up in 298.7s: REPORT 'check for items': bad HTTP > status: > > And then repeats the message with ever growing delays. 503 indicates a temporary error, so the WebDAV layer is correctly retrying it for a while. If that problem persists for certain operations, then the server operator and/or developer needs to investigate that. > Apparently, sync-evolution or the server doesn't like a certain > calendar? > entry, and rather than move on to the next, just gets stuck on it. Primarily this is the server. It could of course also be caused by bad data being sent by SyncEvolution, but then the server should outright reject it instead of reporting a temporary error. > Sometimes killing syncevolution, and then starting it again fixes > the? > issue, and sometimes not. Btw, to kill syncevolution, just using > Ctrl-C > doesn't do the job, you've actually got to use the kill command from > another terminal session, or use Ctrl-Z and then kill. You should get a message that you need to use Ctrl-C twice to abort immediately. Otherwise it tries to suspend the sync, which is less intrusive and may allow resuming it the next time. But I just tried that and noticed that there is no such message. I'm testing a fix. Ctrl-C twice however should work. > May I suggest three small changes to make this issue much less > painful: > > 1. When such a thing occurs, actually say *which* calendar entry > causes? > this. For most practical cases date, time and title should be enough > to? > uniquely identify the entry and allow the user to "manually" transfer > it? > (i.e. manually delete it on phone, manually change/create it on > server,? > and sync it back), or even to allow him to understand what is > causing? > this. This isn't as easy to implement as it seems. The layer which runs into the temporary error has no idea what item it is dealing with, and in some cases the "offending" calendar entry might not even be in the operation (for example, a PUT which removes some item from a larger set). Once the operation times out, the upper layers should print a proper ERROR message about the failed items. As the error in your case isn't really "temporary" and retrying the request doesn't make it go away, you might want to reduce the RetryDuration in your target configuration (the WebDAV side). > 2. The message just echoes the HTTP Status line, and not the rest of > the? > contents of the server's error page. Maybe the server (MS Exchange > via? > davmail) does indeed explain what's the issue with that calendar > entry?? > Bad status? Bad Reminder options? etc.? Impossible to know easily, > as? > nowadays most server use HTTPs and so even tcpdump wouldn't be any > help. How should SyncEvolution render the error response? Quite often it is HTML. There's also the risk of spewing a lot of text to the console. The INFO message is intentionally a single line. If someone wants to know more, they should run with a high log level (like 10) and look at the HTML log file for a failed sync to learn more about the individual HTTP requests. > 3. Rather than just retrying forever, syncevolution should skip over > the? > entry, move on to the next, and repeat in the final summary message > that? > such-and-such entry was skipped (and identify the entry as described > in > point 1) It shouldn't retry forever. The default is 5 minutes. Remember that this is for the case where the server really is loaded. Giving up a sync too soon would just make the situation worse because the next sync then might have to be done in slow mode, so IMHO it makes sense to try for a while. > Other question: I run syncevolution on a BQ Aquaris E5 phone with > Ubuntu? > Touch. Ubuntu no longer supports touch, however, and apt-get upgrade > has? > stopped working for a while. So I'm stuck at version > 1.5.1+15.04.20160706-0ubuntu1 > > However, UBports has taken up this task, and I suppose they've got a? > repository somewhere from which to get updates from them. > Unfortunately? > there site is silent on that issue, and only describes how to > install? > ubports from scratch on a new device, and not how to upgrade an > existing? > Ubuntu touch device. Do you by chance know what to enter into? > /etc/apt/sources.list to get updates from UBports rather than from? > Ubuntu? Sorry, I'm not familiar with Ubuntu phones (never had one). > Third question: due to this whole dropped support issue, I'm in the? > market for a new phone, and it will either be stock Android or > Lineage? > OS (due to current lack of other Linux alternatives :-( ). Does? > syncevolution work on these two OS'es? No, but there are other CalDAV/CardDAV clients, or you can sync the phone directly with Exchange. -- 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.