Hello Ove!

I've imported your git repos and merged the Maemo+Harmattan changes back
into current master.

While reviewing the resulting diff against master I found some oddities
and reverted some of the changes before committing the merged state.
Details are in the commit message:

commit 340579cbdbd8f630846d85319b274a3e41a6313a
Merge: 6648a36 0d86dc1
Author: Patrick Ohly <[email protected]>
Date:   Thu Nov 1 14:39:31 2012 +0100

    Merge branch 'HARMATTAN-1-3-1'
    
    Fetched the code and its history from the 1.3.1 archives at:
    http://people.debian.org/~ovek/maemo/
    http://people.debian.org/~ovek/harmattan/
    
    Merged almost everything, except for Maemo/Harmattan specific build files:
      autogen-maemo.sh builddeb buildsrc debian
    
    The following changes were also removed, because they are either local
    workarounds or merge artifacts which probably also don't belong into
    the Maemo/Harmattan branch:
    
    diff --git a/configure.ac b/configure.ac
    index cb66617..2c4403c 100644
    --- a/configure.ac
    +++ b/configure.ac
    @@ -44,7 +44,7 @@ if test "$enable_release_mode" = "yes"; then
        AC_DEFINE(SYNCEVOLUTION_STABLE_RELEASE, 1, [binary is meant for 
end-users])
     fi
    
    -AM_INIT_AUTOMAKE([1.11.1 tar-ustar silent-rules subdir-objects 
-Wno-portability])
    +AM_INIT_AUTOMAKE([subdir-objects -Wno-portability])
    
     AM_PROG_CC_C_O
    
    diff --git a/src/backends/webdav/CalDAVSource.cpp 
b/src/backends/webdav/CalDAVSource.cpp
    index decd170..7d338ac 100644
    --- a/src/backends/webdav/CalDAVSource.cpp
    +++ b/src/backends/webdav/CalDAVSource.cpp
    @@ -1282,6 +1282,7 @@ void 
CalDAVSource::Event::fixIncomingCalendar(icalcomponent *calendar)
         // time.
         bool ridInUTC = false;
         const icaltimezone *zone = NULL;
    +    icalcomponent *parent = NULL;
    
         for (icalcomponent *comp = icalcomponent_get_first_component(calendar, 
ICAL_VEVENT_COMPONENT);
              comp;
    @@ -1295,6 +1296,7 @@ void 
CalDAVSource::Event::fixIncomingCalendar(icalcomponent *calendar)
             // is parent event? -> remember time zone unless it is UTC
             static const struct icaltimetype null = { 0 };
             if (!memcmp(&rid, &null, sizeof(null))) {
    +            parent = comp;
                 struct icaltimetype dtstart = icalcomponent_get_dtstart(comp);
                 if (!icaltime_is_utc(dtstart)) {
                     zone = icaltime_get_timezone(dtstart);
    diff --git a/src/backends/webdav/CalDAVSource.h 
b/src/backends/webdav/CalDAVSource.h
    index 517ac2f..fa7c2ca 100644
    --- a/src/backends/webdav/CalDAVSource.h
    +++ b/src/backends/webdav/CalDAVSource.h
    @@ -45,6 +45,10 @@ class CalDAVSource : public WebDAVSource,
         virtual void removeMergedItem(const std::string &luid);
         virtual void flushItem(const string &uid);
         virtual std::string getSubDescription(const string &uid, const string 
&subid);
    +    virtual void updateSynthesisInfo(SynthesisInfo &info,
    +                                     XMLConfigFragments &fragments) {
    +        info.m_backendRule = "HAVE-SYNCEVOLUTION-EXDATE-DETACHED";
    +    }
    
         // implementation of SyncSourceLogging callback
         virtual std::string getDescription(const string &luid);
    
    Making SySync_ConsolePrintf a real instance inside SyncEvolution leads
    to link errors in other configurations. It really has to be extern. Added
    a comment to the master branch to make that more obvious:
    
    -extern "C" { // without curly braces, g++ 4.2 thinks the variable is extern
    -    int (*SySync_ConsolePrintf)(FILE *stream, const char *format, ...);
    -}
    +// This is just the declaration. The actual function pointer instance
    +// is inside libsynthesis, which, for historic purposes, doesn't define
    +// it in its header files (yet).
    +extern "C" int (*SySync_ConsolePrintf)(FILE *stream, const char *format, 
...);

-- 
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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to