[SyncEvolution] Re: moving SyncEvolution infrastructure

2022-03-31 Thread Milan Crha 
On Thu, 2022-03-31 at 13:12 +0200, Patrick Ohly wrote:
> I'm not sure. We can try. I created
> https://groups.google.com/g/syncevolution and sent you an invitation
> to your Red Hat email address. Can you join?

Hi,
first of all, the invitation was in German, kinda challenging for me ;)

After clicking the only blue button there, "Diese Einladung annehmen",
it opened a page, which says "404 Not Found" when I'm not logged to the
Google site. When I am logged to the Google site, I'm told that I just
subscribed to the group. From that I suppose a Google account is needed
to subscribe to the Google group.
Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: moving SyncEvolution infrastructure

2022-03-31 Thread Milan Crha 
On Thu, 2022-03-31 at 09:36 +0200, Patrick Ohly wrote:
> Moving it elsewhere is an opportunity to clean this up. I would
> try to keep links valid as much as possible or at least have
> redirects. However, I only intend to copy page content, not comments.
> My plan is to export the original content (usually plain text with
> some Markdown and HTML), clean it up and then run a static page
> generator to recreate the HTML site.

Hi,
even I do not see it on the gitlab.freedesktop.org instance when not
logged in, the GitLab itself supports Wiki pages, like the GNOME's
instance have it here:
https://gitlab.gnome.org/GNOME/evolution-data-server/-/wikis/home
(there's no wiki page set in this project).

The GitLab seems to have a way to provide static pages as well:
https://gitlab.gnome.org/help/user/project/pages/index
https://gitlab.com/pages

And when you've .md files in the repo, they can be viewed as HTML too,
all done by the GitLab. As an example, see how it catches README.md at
the bottom of the:
https://gitlab.gnome.org/GNOME/gnome-software/
I know it's not the same as full static pages/markdown files.

I mean, you can have everything served by the GitLab, including
releases:
https://gitlab.gnome.org/GNOME/gnome-software/-/releases
at least if the relevant parts are enabled by the respective GitLab
instance.

The GNOME's instance allows user projects as well, or filled under
https://gitlab.gnome.org/World . Check the linked rules there, for a
project inclusion.

I do not have any opinion on the mailing list part. If a Google group
accepts non-Google addresses then it's probably fine. Otherwise I'd go
with a service not that restricting myself.
Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Syncing a New Android phone (Samsung A52) w KeepContacts

2022-01-12 Thread Milan Crha 
On Wed, 2022-01-12 at 08:03 -0500, Max Pyziur wrote:
> >get.c gcc -o get get.c `pkg-config --cflags --libs libsoup-2.4`

Hi,
everything after 'gcc', including the 'gcc' itself, is means to be a
separate command, thus:

   $ curl . >get.c

   $ gcc -o get `pkg-config --cflags --libs libsoup-2.4` get.c

   $ ./get 

Hope it helps.
Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release - 1.99.2

2021-02-11 Thread Milan Crha 
On Tue, 2021-02-09 at 18:28 +0100, Milan Crha wrote:
> I opened this new bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1926932

Hi,
there is written the cause of the failure:
https://bugzilla.redhat.com/show_bug.cgi?id=1926932#c4

To cite Jakub:

  So, seems this has nothing to do with LTO, and is related to the
  extern template class std::basic_string;
  extern template class std::vector;
  extern template class std::list;
  lines in src/syncevo/util.h , removing them makes the problem go away.

Could you try whether it'll work properly for you too, when you remove
those lines, please? Providing a new pre-release tarball will help,
maybe with applied the last patch Fedora carries:
https://src.fedoraproject.org/rpms/syncevolution/blob/rawhide/f/syncevolution-1.5.1-libical2.patch

Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release - 1.99.2

2021-02-09 Thread Milan Crha 
On Mon, 2021-02-08 at 14:43 +0100, Milan Crha wrote:
> Trying to build the previous sources in Koji also failed, the same
> sources which worked on January 30th. I opened this bug for it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1926239

Hi,
the above is a bad shot, there was a coincidence between rawhide
changes and the mass rebuild. I opened this new bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1926932

I have some builds in the COPR, which should make things easier to
track:
https://copr.fedorainfracloud.org/coprs/mcrha/syncevo2/builds/

Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release - 1.99.2

2021-02-08 Thread Milan Crha 
On Sun, 2021-02-07 at 20:35 +0100, Patrick Ohly wrote:
> Milan, can you perhaps try those sources without akonadi?

Hi,
sure, I did it, but regardless I use akonadi or not it fails in koji:
* with akonadi:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=61587847

* without akonadi:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=61588781

I do not understand how you might not face it, while Koji build fails.
I tried to build this (using `fedpkg local`) in an up-to-date rawhide
machine and it also fails, but this time with:

   {standard input}: Assembler messages:
   {standard input}:2634072: Warning: end of file not at end of a line; newline 
inserted
   {standard input}:2634901: Warning: zero assumed for missing expression
   g++: fatal error: Terminated signal terminated program cc1plus
   compilation terminated.

That's not what I see in the koji build.

Trying to build the previous sources in Koji also failed, the same
sources which worked on January 30th. I opened this bug for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1926239

By the way, Fedora carries one more patch, related to libical changes:
https://src.fedoraproject.org/rpms/syncevolution/blob/rawhide/f/syncevolution-1.5.1-libical2.patch
All the other patches from:
https://src.fedoraproject.org/rpms/syncevolution/tree/rawhide
seem to be either applied or irrelevant with the 1.99.2 version.

Bye,
Milan

___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release

2021-02-01 Thread Milan Crha 
On Sat, 2021-01-30 at 14:20 +0100, Patrick Ohly wrote:
> Do you have a more recent build log with the failure?

Hi,
sure, I re-ran the build here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=61020990

On Sat, 2021-01-30 at 18:23 +0100, Patrick Ohly wrote:
> /usr/bin/ld: cannot find -lkdeui
> /usr/bin/ld: cannot find -lkdecore

Fedora carries a patch for it:
https://src.fedoraproject.org/rpms/syncevolution/blob/master/f/syncevolution-1.4.1-akonadi.patch

> Perhaps also remove KDE support from the Fedora .spec file?

Right, I can probably do it. I only do not know how many users are
actually using it. If you know there are issues with it, then the best
would be, probably, to drop the code from the sources, otherwise I'm
afraid the users might eventually request to enable it in the package.

Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: SyncEvolution 2.0.0 pre-release

2021-01-04 Thread Milan Crha 
On Sat, 2020-12-19 at 12:40 +0100, Patrick Ohly wrote:
> I have tagged and built SyncEvolution 1.99.1, a pre-release of what
> will become 2.0.0.

Hi,
I gave it a try under Fedora Rawhide and after removing unneeded
downstream patches and updating one due to the boost changes (see the
attached patch) I get a linker error (see the very end of the log):
https://kojipkgs.fedoraproject.org//work/tasks/2132/58912132/build.log

The list of packages used for the build can be found here:
https://kojipkgs.fedoraproject.org//work/tasks/2132/58912132/root.log

Apart of the attached patch are applied also these two patches:
https://src.fedoraproject.org/rpms/syncevolution/blob/master/f/syncevolution-1.4.1-akonadi.patch
https://src.fedoraproject.org/rpms/syncevolution/blob/master/f/syncevolution-1.5.1-libical2.patch

I guess they do not have any real influence on the matter.

Hope it helps,
Milan

diff -up syncevolution-1.99.1/src/dbus/server/auto-sync-manager.cpp.7 syncevolution-1.99.1/src/dbus/server/auto-sync-manager.cpp
--- syncevolution-1.99.1/src/dbus/server/auto-sync-manager.cpp.7	2021-01-04 14:15:57.398518848 +0100
+++ syncevolution-1.99.1/src/dbus/server/auto-sync-manager.cpp	2021-01-04 14:16:30.347478837 +0100
@@ -49,10 +49,10 @@ std::shared_ptr AutoSyn
 result->init();
 
 // update cached information about a config each time it changes
-server.m_configChangedSignal.connect(Server::ConfigChangedSignal_t::slot_type(::initConfig, result.get(), _1).track_foreign(result));
+server.m_configChangedSignal.connect(Server::ConfigChangedSignal_t::slot_type(::initConfig, result.get(), boost::placeholders::_1).track_foreign(result));
 
 // monitor running sessions
-server.m_newSyncSessionSignal.connect(Server::NewSyncSessionSignal_t::slot_type(::sessionStarted, result.get(), _1).track_foreign(result));
+server.m_newSyncSessionSignal.connect(Server::NewSyncSessionSignal_t::slot_type(::sessionStarted, result.get(), boost::placeholders::_1).track_foreign(result));
 
 // Keep track of the time when a transport became online. As with
 // time of last sync, we are pessimistic here and assume that the
@@ -64,13 +64,13 @@ std::shared_ptr AutoSyn
 }
 p.m_btPresenceSignal.connect(PresenceStatus::PresenceSignal_t::slot_type(updatePresence,
  >m_btStartTime,
- _1).track_foreign(result));
+ boost::placeholders::_1).track_foreign(result));
 if (p.getHttpPresence()) {
 result->m_httpStartTime = now;
 }
 p.m_httpPresenceSignal.connect(PresenceStatus::PresenceSignal_t::slot_type(updatePresence,
>m_httpStartTime,
-   _1).track_foreign(result));
+   boost::placeholders::_1).track_foreign(result));
 
 return result;
 }
@@ -404,7 +404,7 @@ void AutoSyncManager::sessionStarted(con
 task->m_lastSyncTime = Timespec::monotonic();
 
 // track permanent failure
-session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(::anySyncDone, this, task.get(), _1).track_foreign(task).track_foreign(me));
+session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(::anySyncDone, this, task.get(), boost::placeholders::_1).track_foreign(task).track_foreign(me));
 
 if (m_session == session) {
 // Only for our own auto sync session: notify user once session starts successful.
@@ -416,7 +416,7 @@ void AutoSyncManager::sessionStarted(con
 
 // Notify user once session ends, with or without failure.
 // Same instance tracking as for sync success start.
-session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(::autoSyncDone, this, task.get(), _1).track_foreign(task).track_foreign(me));
+session->m_doneSignal.connect(Session::DoneSignal_t::slot_type(::autoSyncDone, this, task.get(), boost::placeholders::_1).track_foreign(task).track_foreign(me));
 }
 }
 
diff -up syncevolution-1.99.1/src/dbus/server/dbus-sync.cpp.7 syncevolution-1.99.1/src/dbus/server/dbus-sync.cpp
--- syncevolution-1.99.1/src/dbus/server/dbus-sync.cpp.7	2021-01-04 14:17:11.038429422 +0100
+++ syncevolution-1.99.1/src/dbus/server/dbus-sync.cpp	2021-01-04 14:17:31.548404511 +0100
@@ -120,11 +120,11 @@ std::shared_ptr DBusSync
 // away at any time, so use instance tracking.
 m_helper.m_messageSignal.connect(SessionHelper::MessageSignal_t::slot_type(::storeMessage,
agent.get(),
-   _1,
-

[SyncEvolution] Re: Fails to build with boost 1.73.0

2020-07-07 Thread Milan Crha 
On Fri, 2020-07-03 at 17:34 +0200, Milan Crha wrote:

> I'd propose a patch, but I do not know a single bit of the boost
> library.

Hi,
it turned out to be a semi-mechanical replace. See the attached
bind.patch.

As a bonus, there were these warnings [-Wcatch-value=]:

src/syncevo/SyncContext.cpp: In member function 'SyncEvo::SyncMLStatus 
SyncEvo::SyncContext::doSync()':
src/syncevo/SyncContext.cpp:3816:37: warning: catching polymorphic type 'class 
SyncEvo::TransportException' by value [-Wcatch-value=]
 3816 | } catch (TransportException e) {
src/syncevo/SyncContext.cpp: In member function 'bool 
SyncEvo::SyncContext::checkForScriptAbort(SyncEvo::SharedSession)':
src/syncevo/SyncContext.cpp:4647:14: warning: catching polymorphic type 'class 
SyncEvo::NoSuchKey' by value [-Wcatch-value=]
 4647 | } catch (NoSuchKey) {
src/syncevo/SyncContext.cpp:4651:14: warning: catching polymorphic type 'class 
SyncEvo::BadSynthesisResult' by value [-Wcatch-value=]
 4651 | } catch (BadSynthesisResult) {

for which is attached the catch-value.patch.

Bye,
Milan
diff -up syncevolution-1.5.3/src/backends/activesync/ActiveSyncSource.h.7 syncevolution-1.5.3/src/backends/activesync/ActiveSyncSource.h
--- syncevolution-1.5.3/src/backends/activesync/ActiveSyncSource.h.7	2020-07-07 13:58:12.779492076 +0200
+++ syncevolution-1.5.3/src/backends/activesync/ActiveSyncSource.h	2020-07-07 13:58:30.314408226 +0200
@@ -31,7 +31,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 #include 
@@ -41,6 +41,9 @@
 #include 
 
 #include 
+
+using namespace boost::placeholders;
+
 SE_BEGIN_CXX
 
 
diff -up syncevolution-1.5.3/src/backends/akonadi/akonadisyncsource.cpp.7 syncevolution-1.5.3/src/backends/akonadi/akonadisyncsource.cpp
--- syncevolution-1.5.3/src/backends/akonadi/akonadisyncsource.cpp.7	2018-01-05 16:10:27.0 +0100
+++ syncevolution-1.5.3/src/backends/akonadi/akonadisyncsource.cpp	2020-07-07 13:41:01.828429631 +0200
@@ -41,12 +41,13 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
 SE_BEGIN_CXX
 using namespace Akonadi;
+using namespace boost::placeholders;
 
 /**
  * We take over ownership of jobs by storing them in smart pointers
diff -up syncevolution-1.5.3/src/backends/pbap/PbapSyncSource.cpp.7 syncevolution-1.5.3/src/backends/pbap/PbapSyncSource.cpp
--- syncevolution-1.5.3/src/backends/pbap/PbapSyncSource.cpp.7	2018-01-05 16:10:27.0 +0100
+++ syncevolution-1.5.3/src/backends/pbap/PbapSyncSource.cpp	2020-07-07 13:41:01.829429626 +0200
@@ -45,11 +45,14 @@
 #include "gdbus-cxx-bridge.h"
 
 #include 
-#include 
+#include 
 
 #include 
 
 #include 
+
+using namespace boost::placeholders;
+
 SE_BEGIN_CXX
 
 #define OBC_SERVICE "org.openobex.client" // obexd < 0.47
diff -up syncevolution-1.5.3/src/backends/sqlite/SQLiteContactSource.h.7 syncevolution-1.5.3/src/backends/sqlite/SQLiteContactSource.h
--- syncevolution-1.5.3/src/backends/sqlite/SQLiteContactSource.h.7	2014-04-25 09:55:47.0 +0200
+++ syncevolution-1.5.3/src/backends/sqlite/SQLiteContactSource.h	2020-07-07 13:41:01.829429626 +0200
@@ -25,9 +25,12 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
+
+using namespace boost::placeholders;
+
 SE_BEGIN_CXX
 
 #ifdef ENABLE_SQLITE
diff -up syncevolution-1.5.3/src/backends/webdav/CalDAVSource.cpp.7 syncevolution-1.5.3/src/backends/webdav/CalDAVSource.cpp
--- syncevolution-1.5.3/src/backends/webdav/CalDAVSource.cpp.7	2018-01-05 16:10:27.0 +0100
+++ syncevolution-1.5.3/src/backends/webdav/CalDAVSource.cpp	2020-07-07 13:41:01.829429626 +0200
@@ -11,10 +11,13 @@
 
 #include "CalDAVSource.h"
 
-#include 
+#include 
 #include 
 
 #include 
+
+using namespace boost::placeholders;
+
 SE_BEGIN_CXX
 
 /**
diff -up syncevolution-1.5.3/src/backends/webdav/CardDAVSource.cpp.7 syncevolution-1.5.3/src/backends/webdav/CardDAVSource.cpp
--- syncevolution-1.5.3/src/backends/webdav/CardDAVSource.cpp.7	2014-07-23 10:38:16.0 +0200
+++ syncevolution-1.5.3/src/backends/webdav/CardDAVSource.cpp	2020-07-07 13:41:01.830429622 +0200
@@ -7,6 +7,8 @@
 #ifdef ENABLE_DAV
 
 #include 
+
+using namespace boost::placeholders;
 SE_BEGIN_CXX
 
 // TODO: use EDS backend icalstrdup.c
diff -up syncevolution-1.5.3/src/backends/webdav/NeonCXX.cpp.7 syncevolution-1.5.3/src/backends/webdav/NeonCXX.cpp
--- syncevolution-1.5.3/src/backends/webdav/NeonCXX.cpp.7	2015-04-17 11:19:46.0 +0200
+++ syncevolution-1.5.3/src/backends/webdav/NeonCXX.cpp	2020-07-07 13:51:27.319430971 +0200
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -30,6 +30,9 @@
 #include 
 
 #include 
+
+using namespace boost::placeholders;
+
 SE_BEGIN_CXX
 
 namespace Neon {
diff -up syncevolution-1.5.3/src/backends/webdav/WebDAVSource.cpp.7 syncevolution-1.5.3/src/backends/webdav/WebDAVSource.cpp
--- syncevolution-1.5.3/src/backends/webdav/WebDAVSource.cpp.7	2015-04-01 17:14:39.0 +02

[SyncEvolution] Fails to build with boost 1.73.0

2020-07-03 Thread Milan Crha 
Hi,
I'm rebuilding SyncEvolution 1.5.3 under Fedora Rawhide (to be Fedora 33),
which has boost 1.73.0 and this boost version has changed behavior of
the bind.hpp, as shown in the build log:

   In file included from /usr/include/boost/bind.hpp:30,
from ./src/syncevo/GLibSupport.h:41,
from src/syncevo/ForkExec.h:30,
from src/syncevo/ForkExec.cpp:20:
   /usr/include/boost/bind.hpp:36:1: note: '#pragma message: The
   practice of declaring the Bind placeholders (_1, _2, ...) in the
   global namespace is deprecated. Please use  +
   using namespace boost::placeholders, or define
   BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.'
  36 | BOOST_PRAGMA_MESSAGE(

The above is only a message, which leads to a build break later in the
sources:

   src/syncevo/Cmdline.cpp: In member function 'bool SyncEvo::Cmdline::run()':
   src/syncevo/Cmdline.cpp:1426:65: error: '_1' was not declared in this scope
1426 | processLUIDs(source, boost::bind(ShowLUID, logging, _1));

Declaring the BOOST_BIND_GLOBAL_PLACEHOLDERS mutes the message, but it
doesn't fix the build.

I'd propose a patch, but I do not know a single bit of the boost
library. I'm sorry.

Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Sync failure - F31

2019-11-12 Thread Milan Crha 
On Mon, 2019-11-11 at 13:27 -0500, Max Pyziur wrote:
> So this version will probably not be pushed out for distribution just
> yet. 
> Is that correct?

Hi,
no, I filled that update yesterday. It's in updates-testing right now.
You can find it here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-c07bce6764
I'll create a new update in case further changes will be needed.
Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Sync failure - F31

2019-11-11 Thread Milan Crha 
On Mon, 2019-11-11 at 17:21 +, m...@ericberndt.de wrote:
> For me it is working now, thanks a lot.

Hi,
thank you for a quick testing and confirmation. I'm working on an
official update for Fedora 31. The version, in which the fix is
included, is syncevolution-1.5.3-10.

> The only thing i have to look at is that the item 'memo' is
> deactivated. 
> Only the items Memo an Todo itself should be activated, otherwise all
> items are transferred on every sync.

That might be question for Patrick, I do not know how to debug it. It's
likely I made another mistake here, I only do not know how this works,
thus cannot tell you whether or where I made such mistake.

Thanks again and bye,
Milan

___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Sync failure - F31

2019-11-11 Thread Milan Crha 
On Sun, 2019-11-10 at 13:05 +, m...@ericberndt.de wrote:
> In my log file i found the following
> 
> https://paste.fedoraproject.org/paste/fqXYHwxS~A3sFzcrmq8baA

Hi,
I see from the backtrace that it's my fault. I'm sorry. When porting
syncevolution to libecal-2.0 I missed one place (maybe more), causing
the crash. The attached patch will fix it. I made a scratch build for
Fedora 31 here[1]. Could you give it a try, please? Just click the
architecture you use, then download packages you've installed:
   $ rpm -qa | grep syncevolution
then update them, from the directory you downloaded them to:
   $ sudo dnf update ./syncevolution*.rpm

Ideally install also debuginfo and debugsource packages for
syncevolution, thus any later backtraces will contain line numbers and
such.

The fix should make it work. Let me know if it helped, please, thus I
could make an official release with it.
Thanks and bye,
Milan

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=38911383
diff -up syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.eds-libecal-2.0-b syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp
--- syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.eds-libecal-2.0-b	2019-11-11 09:27:55.148982120 +0100
+++ syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp	2019-11-11 09:27:56.117982106 +0100
@@ -370,7 +370,11 @@ static void list_revisions(const GSList
 const GSList *l;
 
 for (l = objects; l; l = l->next) {
+#ifdef HAVE_LIBECAL_2_0
+ICalComponent *icomp = (ICalComponent*)l->data;
+#else
 icalcomponent *icomp = (icalcomponent*)l->data;
+#endif
 EvolutionCalendarSource::ItemID id = EvolutionCalendarSource::getItemID(icomp);
 string luid = id.getLUID();
 string modTime = EvolutionCalendarSource::getItemModTime(icomp);
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[SyncEvolution] Re: Sync failure - F31

2019-11-06 Thread Milan Crha 
On Wed, 2019-11-06 at 09:37 +0100, Patrick Ohly wrote:
> Milan does an excellent job with keeping
> the packages building, but this can't replace upstream testing.

Hi,
in fact, it can be an issue specific to Fedora 31. I made changes to
use python3 (not python2) where those can be wrong in some way (it was
semi-blind change). In other words, it can be my fault.

Hopefully the run from the command line will show where that
"unexpected die" happened precisely.

Max, could you check whether ABRT catch anything, please? Being it a
crash, it may record it.
Bye,
Milan
___
SyncEvolution mailing list -- syncevolution@syncevolution.org
To unsubscribe send an email to syncevolution-le...@syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [SyncEvolution] Use python3 (was: Re: Detect python binary name in build time)

2019-05-22 Thread Milan Crha 
On Fri, 2019-04-05 at 12:57 +0200, Milan Crha wrote:
> The attached is a result of the files being processes
> through it, including slightly modified patch proposed earlier (it
> looks for python3 now, instead of python2).

Hi,
I've been playing with this a bit more and there's an issue with
python3-twisted [1]. Once fixed, a similar issue rises with the
syncevo-http-server.py. The attached is an additional change to the
SyncEvolution, which removes that "import gobject", because it's not
used at that file at all. If you'd prefer to keep it there (like if
it's needed and I overlooked something), then you might change the
import to the smart one, like in src/dbus/server/pim/examples/sync.py,
where it reads:

   try:
   import gobject
   except ImportError:
   from gi.repository import GObject as gobject

   Hope it helps.
Bye,
Milan

   [1] https://bugzilla.redhat.com/show_bug.cgi?id=1712748
diff -up syncevolution-1.5.3/test/syncevo-http-server.py.imp-gobject syncevolution-1.5.3/test/syncevo-http-server.py
--- syncevolution-1.5.3/test/syncevo-http-server.py.imp-gobject	2019-05-21 17:35:12.463672604 +0200
+++ syncevolution-1.5.3/test/syncevo-http-server.py	2019-05-22 10:16:30.254545191 +0200
@@ -10,7 +10,6 @@ DBusGMainLoop(set_as_default=True)
 glib2reactor.install()
 
 import dbus
-import gobject
 import sys
 import urllib.parse
 import optparse
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Port to libecal-2.0 and libebook API changes

2019-05-02 Thread Milan Crha 
On Thu, 2019-05-02 at 20:59 +0200, deloptes wrote:
> but shouldn't be somewhere there a libical version check?

Hi,
that's assured through HAVE_LIBECAL_2_0 (see the first patch at this
thread). Nothing of this had been released yet, the evolution-data-
server's libecal-2.0 is waiting for the libical release currently, with
which it'll use libical-glib part of the libical project. The current
libecal-1.2 uses plain libical.
Bye,
Milan

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Port to libecal-2.0 and libebook API changes

2019-05-02 Thread Milan Crha 
On Wed, 2019-04-24 at 17:49 +0200, Milan Crha wrote:
> There are going to be made huge libecal API changes...

Hi,
upstream libical received additional API changes in the libical-glib
part, which touch also the previous patch. Even it's not released yet I
prepared those new changes (attached).
Bye,
Milan
diff -up syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.orig2 syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp
--- syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.orig2	2019-05-02 14:45:02.301086306 +0200
+++ syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp	2019-05-02 14:46:51.081084802 +0200
@@ -760,7 +760,7 @@ EvolutionCalendarSource::InsertItemResul
 eptr orig(retrieveItem(id));
 ICalProperty *orig_rid = i_cal_component_get_first_property(orig, I_CAL_RECURRENCEID_PROPERTY);
 if (orig_rid) {
-i_cal_component_take_property(subcomp, i_cal_property_new_clone(orig_rid));
+i_cal_component_take_property(subcomp, i_cal_property_clone(orig_rid));
 }
 g_clear_object(_rid);
 }
@@ -1448,7 +1448,7 @@ string EvolutionCalendarSource::icalTime
 if (tt || !i_cal_time_is_valid_time (tt) || i_cal_time_is_null_time (tt)) {
 return "";
 } else {
-eptr timestr(i_cal_time_as_ical_string_r(tt));
+eptr timestr(i_cal_time_as_ical_string(tt));
 if (!timestr) {
 SE_THROW("cannot convert to time string");
 }
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[SyncEvolution] Port to libecal-2.0 and libebook API changes

2019-04-24 Thread Milan Crha 
Hello,
I thought I'll file a bug with a proposed patch at
bugs.freedesktop.org, where the 
https://syncevolution.org/support#issues pointed me to, but it ends
with "Sorry, entering a bug into the product SyncEvolution has been
disabled.", thus I'm sending it here instead.

There are going to be made huge libecal API changes, as huge as it
deserved a version bump from 1.2 to 2.0, and together with it a small
libebook API changes, most likely being part of the evolution-data-
server 3.33.2 release, which is planned for May 20. More about this can
be found here:
https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00016.html

The attached is a patch which makes syncevolution build against 3.33.1
and the libical-glib branch without any new compiler warnings. I'm not
able to test the change though, and the `make check` doesn't run any
test here, thus the changes would need some real testing. I'm sorry
about that. On the other hand, this patch gives at least an overview of
the upcoming changes and what to do in the syncevolution code.

One note, the check for HAVE_E_BOOK_OPERATION_FLAGS is quite lame, it
only decides based on the expected version (the libical-glib branch
still references 3.33.1). Maybe you'd like to extend the test in some
better way.

I hope you'll find this useful.
Bye,
Milan
diff -up syncevolution-1.5.3/src/backends/evolution/configure-sub.in.orig syncevolution-1.5.3/src/backends/evolution/configure-sub.in
--- syncevolution-1.5.3/src/backends/evolution/configure-sub.in.orig	2019-04-24 14:10:09.961827490 +0200
+++ syncevolution-1.5.3/src/backends/evolution/configure-sub.in	2019-04-24 17:23:23.573667170 +0200
@@ -15,13 +15,23 @@ $anymissing"
 
 dnl check for Evolution packages
 PKG_CHECK_MODULES(EPACKAGE, libedataserver-1.2, EDSFOUND=yes, [EDSFOUND=no])
-PKG_CHECK_MODULES(ECAL, libecal-1.2, ECALFOUND=yes, [ECALFOUND=no])
+PKG_CHECK_MODULES(ECAL, libecal-2.0, ECALFOUND=yes, [ECALFOUND=no])
 PKG_CHECK_MODULES(EBOOK, libebook-1.2, EBOOKFOUND=yes, [EBOOKFOUND=no])
 
+if test "$ECALFOUND" = "yes"; then
+AC_DEFINE(HAVE_LIBECAL_2_0, 1, [libecal 2.0])
+else
+PKG_CHECK_MODULES(ECAL, libecal-1.2, ECALFOUND=yes, [ECALFOUND=no])
+fi
+
 PKG_CHECK_MODULES(EBOOK_VERSION, [libebook-1.2 >= 3.3],
   [AC_DEFINE(HAVE_E_CONTACT_INLINE_LOCAL_PHOTOS, 1, [have e_contact_inline_local_photos()])],
   [true])
 
+PKG_CHECK_MODULES(EBOOK_VERSION_3_33, [libebook-1.2 >= 3.33.2],
+  [AC_DEFINE(HAVE_E_BOOK_OPERATION_FLAGS, 1, [have EBookOperationFlags])],
+  [true])
+
 SE_ARG_ENABLE_BACKEND(ebook, evolution,
   [AS_HELP_STRING([--disable-ebook],
   [disable access to Evolution addressbooks (must be used to compile without it)])],
diff -up syncevolution-1.5.3/src/backends/evolution/e-cal-check-timezones.c.orig syncevolution-1.5.3/src/backends/evolution/e-cal-check-timezones.c
--- syncevolution-1.5.3/src/backends/evolution/e-cal-check-timezones.c.orig	2019-04-24 17:07:51.057680065 +0200
+++ syncevolution-1.5.3/src/backends/evolution/e-cal-check-timezones.c	2019-04-24 17:18:18.077671395 +0200
@@ -414,7 +414,11 @@ gboolean e_cal_check_timezones(icalcompo
 goto done;
  nomem:
 /* set gerror for "out of memory" if possible, otherwise abort via g_error() */
+#ifdef HAVE_LIBECAL_2_0
+*error = g_error_new(E_CLIENT_ERROR, E_CLIENT_ERROR_OTHER_ERROR, "out of memory");
+#else
 *error = g_error_new(E_CALENDAR_ERROR, E_CALENDAR_STATUS_OTHER_ERROR, "out of memory");
+#endif
 if (!*error) {
 g_error("e_cal_check_timezones(): out of memory, cannot proceed - sorry!");
 }
@@ -451,6 +455,10 @@ icaltimezone *e_cal_tzlookup_ecal(const
   const void *custom,
   GError **error)
 {
+#ifdef HAVE_LIBECAL_2_0
+g_propagate_error(error, e_client_error_create(E_CLIENT_ERROR_NOT_SUPPORTED, NULL));
+return NULL;
+#else
 ECal *ecal = (ECal *)custom;
 icaltimezone *zone = NULL;
 
@@ -470,6 +478,7 @@ icaltimezone *e_cal_tzlookup_ecal(const
 }
 return NULL;
 }
+#endif
 }
 
 /**
diff -up syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.orig syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp
--- syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp.orig	2019-04-24 14:19:15.057819952 +0200
+++ syncevolution-1.5.3/src/backends/evolution/EvolutionCalendarSource.cpp	2019-04-24 17:19:04.117670758 +0200
@@ -189,7 +189,7 @@ static EClient *newECalClient(ESource *s
   ECalClientSourceType ecalSourceType,
   GError **gerror)
 {
-return E_CLIENT(e_cal_client_new(source, ecalSourceType, gerror));
+return E_CLIENT(e_cal_client_connect_sync(source, ecalSourceType, -1, NULL, gerror));
 }
 #else
 char *EvolutionCalendarSource::authenticate(const char *prompt,

[SyncEvolution] Use python3 (was: Re: Detect python binary name in build time)

2019-04-05 Thread Milan Crha 
On Tue, 2018-07-24 at 18:18 +0200, Milan Crha wrote:
> On Tue, 2018-07-24 at 17:38 +0200, Patrick Ohly wrote:
> > I'm definitely interested.
> 
> I asked, but failed. It seems python folks are covered with more
> priority work, at least there where I tried. Thus I'm sorry, I do not
> have anyone able to port the files at the moment.

Hi again,
I've been told that there are some scripts, which can convert python2
code into python3 code, which led me to the 2to3 [1], provided by
python itself. The attached is a result of the files being processes
through it, including slightly modified patch proposed earlier (it
looks for python3 now, instead of python2). The resulting patch has
more than 96KB, thus I packed it.

Patrick, I believe you've a better test environment, which would verify
the functionality of those helper scripts heavily, definitely better
than me, thus I'd like to ask you to give it a try. Maybe if it'll
work, and the scripts would provide the same (or close to the same)
results, then you can do a python3-only release with whatever changes
you might have piled since the 1.5.3 release.

Thanks and bye,
Milan

[1] https://docs.python.org/2/library/2to3.html
<>
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Detect python binary name in build time

2018-07-24 Thread Milan Crha 
On Tue, 2018-07-24 at 17:38 +0200, Patrick Ohly wrote:
> I'm definitely interested.

Hi,
I asked, but failed. It seems python folks are covered with more
priority work, at least there where I tried. Thus I'm sorry, I do not
have anyone able to port the files at the moment. I've been redirected
to: https://portingguide.readthedocs.io/
For what I tried myself, by simply changing the shebangs to python3 in
the build-time scripts, some worked, but some failed on the syntax. I
cannot speak of the actual results of those scripts though.

> The Arch maintainer filed an issue for the
> same problem and attached his own patch here:
> https://bugs.freedesktop.org/show_bug.cgi?id=107014

I see. It seems there are covered more files, even not in the generic
way as with my patch.

> But as you said, the real solution has to be a port to Python3. Would
> it be okay to drop Python2 support entirely?

>From my point of view yes, because python2 support will be dropped kind
of soon anyway: https://pythonclock.org/

> Doing so in a 1.5.x maintenance release sounds too intrusive.

I agree, changing dependencies in the stable release is not ideal.

> Should I target a 1.6.0 release with Python3 as dependency and also
> include my "cxx-future" branch, where I require C++11?

Sounds good to me, though I cannot talk for all interested parties.
Thanks and bye,
Milan


___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[SyncEvolution] Detect python binary name in build time

2018-07-16 Thread Milan Crha 
Hello,
there is some effort to rename 'python' to 'python2' in the
distributions, but SyncEvolution still uses 'python' (without the
version number) in its scripts. I made a change for Fedora to detect
the installed python 2 binary name and use it in the scripts.

I know, an ideal solution would be to port to python3 at the same time,
but it's out of my knowledge, I do not speak pythonish and simple
change to /usr/bin/python3 makes the provided scripts not to run with a
runtime error about syntax and such, thus I decided to offer at least
this change to you. Maybe I'll convince someone with python knowledge
to port the scripts to python3, in which case I'd return back to you
with a follow up change, if you are interested.
Bye,
Milan
diff -up syncevolution-1.5.3/configure.ac.python2 syncevolution-1.5.3/configure.ac
--- syncevolution-1.5.3/configure.ac.python2	2018-01-09 16:53:28.0 +0100
+++ syncevolution-1.5.3/configure.ac	2018-07-16 18:31:06.970413427 +0200
@@ -62,6 +62,11 @@ dnl check for programs.
 AC_PROG_CXX
 AC_PROG_MAKE_SET
 
+AC_PATH_PROGS(PYTHON, python2 python, "")
+if test "x$PYTHON" = "x" ; then
+   AC_ERROR([python not found])
+fi
+
 dnl Use the most recent C++ standard that is supported by the code.
 dnl We can fall back to older versions, but not below C++11.
 dnl Akonadi/Qt don't work with C++17 yet, so we can't enable that.
diff -up syncevolution-1.5.3/src/src.am.python2 syncevolution-1.5.3/src/src.am
--- syncevolution-1.5.3/src/src.am.python2	2018-01-05 16:10:27.0 +0100
+++ syncevolution-1.5.3/src/src.am	2018-07-16 18:30:04.703414288 +0200
@@ -42,12 +42,12 @@ if COND_DBUS
 nodist_bin_SCRIPTS += src/syncevo-http-server
 endif
 src/syncevo-http-server: $(top_srcdir)/test/syncevo-http-server.py
-	$(AM_V_GEN)cp $< $@
+	$(AM_V_GEN)sed -e 's|\@PYTHON\@|$(PYTHON)|' $< > $@
 CLEANFILES += src/syncevo-http-server
 
 nodist_bin_SCRIPTS += src/syncevo-phone-config
 src/syncevo-phone-config: $(top_srcdir)/test/syncevo-phone-config.py
-	$(AM_V_GEN)cp $< $@
+	$(AM_V_GEN)sed -e 's|\@PYTHON\@|$(PYTHON)|' $< > $@
 CLEANFILES += src/syncevo-phone-config
 
 SYNCEVOLUTION_DEP =
@@ -72,7 +72,7 @@ src/synccompare : $(top_srcdir)/test/Alg
 bin_SCRIPTS += src/synclog2html
 CLEANFILES += src/synclog2html
 src/synclog2html: $(top_srcdir)/test/log2html.py
-	$(AM_V_GEN)cp $< $@ && chmod u+x $@
+	$(AM_V_GEN)sed -e 's|\@PYTHON\@|$(PYTHON)|' $< > $@ && chmod u+x $@
 
 CORE_SOURCES =
 
@@ -367,7 +367,7 @@ testcase2patch: $(TEST_FILES_GENERATED)
 nodist_noinst_DATA += src/ClientTest.cpp.html
 CLEANFILES += src/ClientTest.cpp.html
 src/ClientTest.cpp.html: build/source2html.py test/ClientTest.cpp
-	$(AM_V_GEN)python $+ >$@
+	$(AM_V_GEN)$(PYTHON) $+ >$@
 
 # copy base test files
 $(filter-out %.tem, $(filter src/testcases/%, $(subst $(top_srcdir)/test/,src/,$(CLIENT_LIB_TEST_FILES : src/% : $(top_srcdir)/test/%
diff -up syncevolution-1.5.3/test/log2html.py.python2 syncevolution-1.5.3/test/log2html.py
--- syncevolution-1.5.3/test/log2html.py.python2	2014-04-25 09:55:47.0 +0200
+++ syncevolution-1.5.3/test/log2html.py	2018-07-16 18:30:04.703414288 +0200
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!@PYTHON@
 
 """
 Converts the .log output for a client-test test into HTML, with
diff -up syncevolution-1.5.3/test/syncevo-http-server.py.python2 syncevolution-1.5.3/test/syncevo-http-server.py
--- syncevolution-1.5.3/test/syncevo-http-server.py.python2	2016-09-26 13:20:05.0 +0200
+++ syncevolution-1.5.3/test/syncevo-http-server.py	2018-07-16 18:30:04.703414288 +0200
@@ -1,4 +1,4 @@
-#! /usr/bin/python
+#!@PYTHON@
 
 '''Usage: syncevo-http-server.py 
 Runs a SyncML HTTP server under the given base URL.'''
diff -up syncevolution-1.5.3/test/syncevo-phone-config.py.python2 syncevolution-1.5.3/test/syncevo-phone-config.py
--- syncevolution-1.5.3/test/syncevo-phone-config.py.python2	2014-04-25 09:55:48.0 +0200
+++ syncevolution-1.5.3/test/syncevo-phone-config.py	2018-07-16 18:30:04.704414288 +0200
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!@PYTHON@
 #
 # Copyright (C) 2010 Intel Corporation
 #
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[SyncEvolution] [Patch] Fails to build with libical 3.0.0

2017-11-16 Thread Milan Crha 
Hi,
syncevolution 1.5.2 fails to build with libical 3.0.0.
I attached a patch which makes it build. Let me know if anything is
wrong, please.
Thanks and bye,
Milandiff -up syncevolution-1.5.2/src/backends/webdav/CalDAVSource.cpp.libical3 syncevolution-1.5.2/src/backends/webdav/CalDAVSource.cpp
--- syncevolution-1.5.2/src/backends/webdav/CalDAVSource.cpp.libical3	2017-11-16 12:21:40.808664704 +0100
+++ syncevolution-1.5.2/src/backends/webdav/CalDAVSource.cpp	2017-11-16 12:22:16.277664214 +0100
@@ -721,8 +721,8 @@ SubSyncSource::SubItemResult CalDAVSourc
 eptr fullcal = event.m_calendar;
 loadItem(event);
 event.m_sequence++;
-lastmodtime = icaltime_from_timet(event.m_lastmodtime, false);
-lastmodtime.is_utc = 1;
+lastmodtime = icaltime_from_timet_with_zone(event.m_lastmodtime, false, NULL);
+lastmodtime.zone = icaltimezone_get_utc_timezone();
 event.m_calendar = fullcal;
 for (icalcomponent *comp = icalcomponent_get_first_component(event.m_calendar, ICAL_VEVENT_COMPONENT);
  comp;
diff -up syncevolution-1.5.2/src/syncevo/icaltz-util.c.libical3 syncevolution-1.5.2/src/syncevo/icaltz-util.c
--- syncevolution-1.5.2/src/syncevo/icaltz-util.c.libical3	2017-11-16 12:22:43.408663839 +0100
+++ syncevolution-1.5.2/src/syncevo/icaltz-util.c	2017-11-16 12:23:37.109663096 +0100
@@ -224,7 +224,7 @@ find_transidx (time_t *transitions, ttin
 	struct icaltimetype itime;
 
 	now = time (NULL);
-	itime = icaltime_from_timet (now, 0);
+	itime = icaltime_from_timet_with_zone (now, 0, NULL);
 	itime.month = itime.day = 1;
 	itime.hour = itime.minute = itime.second = 0;
 	year_start = icaltime_as_timet(itime);
@@ -304,13 +304,13 @@ adjust_dtstart_day_to_rrule (icalcompone
 	icalrecur_iterator *iter;
 
 	now = time (NULL);
-	itime = icaltime_from_timet (now, 0);
+	itime = icaltime_from_timet_with_zone (now, 0, NULL);
 	itime.month = itime.day = 1;
 	itime.hour = itime.minute = itime.second = 0;
 	year_start = icaltime_as_timet(itime);
 
 	comp_start = icalcomponent_get_dtstart (comp);
-	start = icaltime_from_timet (year_start, 0);
+	start = icaltime_from_timet_with_zone (year_start, 0, NULL);
 
 	iter = icalrecur_iterator_new (rule, start);
 	iter_start = icalrecur_iterator_next (iter);
@@ -478,7 +478,7 @@ icaltzutil_fetch_timezone (const char *l
 			trans = transitions [stdidx] + types [zp_idx].gmtoff;
 		else
 			trans = types [zp_idx].gmtoff;
-		icaltime = icaltime_from_timet (trans, 0);
+		icaltime = icaltime_from_timet_with_zone (trans, 0, NULL);
 		dtstart = icaltime;
 		dtstart.year = 1970;
 		dtstart.minute = dtstart.second = 0;
@@ -520,7 +520,7 @@ icaltzutil_fetch_timezone (const char *l
 			trans = transitions [dstidx] + types [zp_idx].gmtoff;
 		else
 			trans = types [zp_idx].gmtoff;
-		icaltime = icaltime_from_timet (trans, 0);
+		icaltime = icaltime_from_timet_with_zone (trans, 0, NULL);
 		dtstart = icaltime;
 		dtstart.year = 1970;
 		dtstart.minute = dtstart.second = 0;
diff -up syncevolution-1.5.2/src/synthesis/configure.in.libical3 syncevolution-1.5.2/src/synthesis/configure.in
--- syncevolution-1.5.2/src/synthesis/configure.in.libical3	2016-10-06 16:40:43.0 +0200
+++ syncevolution-1.5.2/src/synthesis/configure.in	2017-11-16 12:06:02.169677684 +0100
@@ -101,9 +101,14 @@ AC_ARG_ENABLE(libical,
 if test "$enable_libical" == "yes"; then
PKG_CHECK_MODULES(LIBICAL, libical,
  [AC_DEFINE(HAVE_LIBICAL, 1, "libical available")
-  PKG_CHECK_MODULES(LIBICAL2, libical >= 2,
-[AC_DEFINE(USE_ICALTZUTIL_SET_EXACT_VTIMEZONES_SUPPORT, 1, "Use icaltzutil_set_exact_vtimezones_support() to enable interoperable timezone definitions.")],
-[true])],
+  PKG_CHECK_MODULES(LIBICAL3, libical >= 3,
+[have_libical3="yes"],
+[have_libical3="no"])
+  if test "$have_libical3" == "no"; then
+  PKG_CHECK_MODULES(LIBICAL2, libical >= 2,
+[AC_DEFINE(USE_ICALTZUTIL_SET_EXACT_VTIMEZONES_SUPPORT, 1, "Use icaltzutil_set_exact_vtimezones_support() to enable interoperable timezone definitions.")],
+[true])
+  fi],
  [AC_ERROR([libical not found, required for --enable-libical])])
 fi
 
diff -up syncevolution-1.5.2/src/synthesis/src/platform_adapters/linux/platform_timezones.cpp.libical3 syncevolution-1.5.2/src/synthesis/src/platform_adapters/linux/platform_timezones.cpp
--- syncevolution-1.5.2/src/synthesis/src/platform_adapters/linux/platform_timezones.cpp.libical3	2016-10-06 16:40:43.0 +0200
+++

Re: [SyncEvolution] Release preparations for 1.5.2

2016-09-30 Thread Milan Crha 
On Thu, 2016-09-29 at 14:45 +0200, Patrick Ohly wrote:
> Before I tag and release this as 1.5.2, it would be great to get some
> feedback that this release doesn't cause regressions.

Hi,
I cannot speak for runtime, but I was able to build the tarballs in
Fedora rawhide without any issue, more than that, I could remove the
gcc6 patch which Fedora uses. Thus looks fine here from the build point
of view.
Bye,
Milan

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Build fails with libical 2.0.0

2016-01-20 Thread Milan Crha 
On Tue, 2016-01-19 at 13:49 +0100, Patrick Ohly wrote:
> Does the libical 2.0 return "simple" VTIMEZONE definitions again, i.e.
> ones with RRULEs for summer and winter time?

Hi,
they do return expanded timezones, unless the library is built with
   -DUSE_INTEROPERABLE_VTIMEZONES=true
or unless the application (library user) calls:
   icaltzutil_set_exact_vtimezones_support (0);

That restores the previous behaviour. I'm going to call that function
in the evolution(-data-server) code, if available.
Bye,
Milan

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

[SyncEvolution] Build fails with libical 2.0.0

2016-01-19 Thread Milan Crha 
Hello,
I just realized that the syncevolution fails to build against
libical 2.0.0. The problem is synevolution's extract of
icaltz-util.c/.h, referencing extern const char *ical_tzid_prefix;
This variable had been made private and there is no way to get to it
from the outside of libical (the added icaltimezone_tzid_prefix() is
not exported in the libical library).

I do not know the rationale with the icaltz-util extract in the
syncevolution, but I'd say it's time to get rid of it when new-enough
libical is used for the build. What do you think?

I placed a lame workaround in my build and defined the missing variable
with the value copied from the libical 2.0.0 sources. I know it doesn't
scale and can easily break in the future, but I expect that there will
be done a proper fix upstream meanwhile and I'll be able to drop the
workaround once the fix will be released.
Bye,
Milan
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] Sync issue after upgrade

2015-05-27 Thread Milan Crha 
On Wed, 2015-05-27 at 14:53 +0200, Patrick Ohly wrote:
 On Wed, 2015-05-27 at 14:04 +0200, Daniel CLEMENT wrote:
  FOREIGN KEY constraint failed

Hi,
that was a bug in the address book code in evolution-data-server,
see [1] for more information.
Bye,
Milan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=743996

___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] SMS VMG reader (fwd)

2015-01-28 Thread Milan Crha 
On Wed, 2015-01-28 at 12:35 -0500, Max Pyziur wrote:
 Does Evolution have any sort of support for SMS/VMG files?
 
 
 From what I can tell, SMS messages are stored in VMG files, a text 
 file that is
 marked-up similarly to VCF files.
 

Hi,
there is no direct support for this type of file. The VCF file 
contains set of vCards, which is contact information. I do not know 
exact VMG format, though the closes might be a Memo (Journal) 
iCalendar component for it, maybe?

 I realize that this may not be the appropriate list,

Right, Evolution specific mailing list is evolution-l...@gnome.org .
Bye,
Milan



___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution

Re: [SyncEvolution] MS Exchange and KDE synchronization: Colleague's calendar?

2014-07-30 Thread Milan Crha 
On Tue, 2014-07-29 at 14:17 +0200, Patrick Ohly wrote:
 
 It seems that this is not possible via ActiveSync. See this mail 
 thread:
 https://www.mail-archive.com/syncevolution@syncevolution.org/msg04710.html  

Hi,
in Exchange Web Services (EWS) protocol (I know it's not the same as 
ActiveSync, but they seem quite close to each other), one has two 
options. One is to impersonate the user, which is done with 
ExchangeImpersonation element [1] in request SOAP message's header 
part, but it's not the same as shared folders, which are handled in a 
very different way (the impersonation requires admin settings on the 
server, if i recall correctly).

There is no way to get to shared folders, I guess it's for to security 
reasons, but users can add shared folders if they know them - those 
are share notifications emails for. That is easy for standard folders 
(distinguished folder names, like 'calendar' [2]), but it can work for 
any folder, supposing the user knows the folder ID. This may need 
testing with ActiveSync, and an ability to add custom folders with 
SyncEvolution, but maybe it'll work in a similar way as in EWS. (I 
mean, apart of list of folders reported by the server you might have 
an ability to let users add shared folders. These may be from Public 
Folders as well.)
Hope it helps,
Milan

[1] 
https://git.gnome.org/browse/evolution-ews/tree/src/server/e-ews-message.c#n137
[2] 
https://git.gnome.org/browse/evolution-ews/tree/src/configuration/e-ews-subscribe-foreign-folder.c#n511
___
SyncEvolution mailing list
SyncEvolution@syncevolution.org
https://lists.syncevolution.org/mailman/listinfo/syncevolution