opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Chris Frey wrote:

> On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote:
>> From my point of view this is doable, also the current libsyncml is doing
>> most of the same. I think if no one wants to maintain this library
>> libsynthesis can safely replace it. Perhaps there would be some more work
>> on the transport stuff, which I saw in SyncEvolution, but didn't have
>> time to study.
> 
> I suspect it is technically possible, but it might require some changes
> to libsynthesis. :-)  Or maybe a large wrapper, which uses libsynthesis
> as intended, to sync into a local database, and then write an opensync
> plugin to sync against that database.
> 

I was reading SySync_config_reference.pdf [p.17] where it states

3.1 Basic Concepts
The Synthesis SyncML engine performs three conceptually more or less
separate tasks:
• Running the SyncML protocol. [...] there is not a lot of configuration
needed for the SyncML protocol engine itself.
• Encoding and decoding the data that is synchronized with the SyncML
protocol. SyncML itself is designed to synchronize any type of data, even
proprietary, customer-defined types.
However, to make a SyncML server or client interoperable, it must support
some standard datatypes [...] vCard format for contact information and
vCalendar for events and tasklists, and a number of RFC(2)822 based email
formats for email synchronisation. [...]
• Interfacing the SyncML data with a server's or client's database. The
complexity of this task depends largely on the type and kind of database.
[...] 

and also SDK_manual.pdf [p.7]:

Synthesis AG makes their SyncML engine functionality available for
customized database plug-in adapters as a Software Development Kit ( SDK ).
Synthesis Plugin technology allows the customer to develop data base
adapters or user interfaces without the need of understanding the details
of the SyncML standard. It's an ideal division of work between Synthesis
and the customer's project: Synthesis delivers a scalable, high performance
SyncML OMA DS 1.2 engine, which is interoperability-tested against a huge
variety of SyncML devices on the market. The customer only needs the
specific knowledge to access his own data base framework or his own user
interface which can be written in several programming languages.
A small interface with only 48 + 23 well documented and easy-to-use
functions is the bridge of interaction. All SyncML protocol details are
hidden.
There are mainly two sections of the SDK:
• The data base interface ( DBApi ) for writing data base plugins (see
chapter 4).
• The user interface
( UIApi ) for writing user interfaces (see chapter 5).
Both sections can be used completely independently, though some interface
files are shared. 


So it really sounds doable. Perhaps we need to build something on top as you
say (derived classes or wrapper or so).
I would love also to read more about the JNI interface too and evaluate all
possible options. Perhaps it is easier to implement something in java
despite it will cause an overhead.
I think I'll spend the time around Christmas not in coding but reading the
documentation :-) as it looks more sophisticated.

Something else: Do we need these http and ds client and server (that you see
in libsyncml/libopensync-plugin-syncml - I didn't got it at 100% until now,
because I have been using the obex-client in the config and I've never
looked what is going on.

[to be continued ...]

kind regards

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Fri, Oct 28, 2011 at 04:27:02PM +0200, Patrick Ohly wrote:
> This advantage also has a significant downside: the rest of OpenSync has
> no idea about the DevInf of the SyncML peer and thus cannot take that
> into account when reading or writing the local database. It is also not
> possible to provide the capabilities of the local side to the Synthesis
> engine because there is not one single peer locally (group concept of
> OpenSync).
> 
> As a result, data will get lost when doing round-trip syncs.

I'm not a SyncML expert, so I'm not familiar what this "DevInf" information
will be, nor why we would lose it, nor why it might be important. :-(

Can you give me an example of what might be missing?

Thanks,
- Chris

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Patrick O. <pat...@gm...>]

On Fri, 2011-10-28 at 00:07 +0200, Lukas Zeller wrote:
> On Oct 27, 2011, at 21:40 , Chris Frey wrote:
> > On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote:
> > Or maybe a large wrapper, which uses libsynthesis
> > as intended, to sync into a local database, and then write an
> > opensync plugin to sync against that database.
> 
> That sounds like an interesting approach. It'll sure be easier to
> implement and debug, and would nicely decouple the different designs.

This advantage also has a significant downside: the rest of OpenSync has
no idea about the DevInf of the SyncML peer and thus cannot take that
into account when reading or writing the local database. It is also not
possible to provide the capabilities of the local side to the Synthesis
engine because there is not one single peer locally (group concept of
OpenSync).

As a result, data will get lost when doing round-trip syncs.

-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Lukas Z. <lu...@pl...>]

On Oct 27, 2011, at 21:40 , Chris Frey wrote:

> On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote:
>> From my point of view this is doable, also the current libsyncml is doing
>> most of the same. I think if no one wants to maintain this library
>> libsynthesis can safely replace it. Perhaps there would be some more work
>> on the transport stuff, which I saw in SyncEvolution, but didn't have time
>> to study.
> 
> I suspect it is technically possible, but it might require some changes
> to libsynthesis. :-)

Quite some changed, probably. It was designed to be multi-platform, to run a big SyncML server as well as be small enough to run on a Palm V, extendable via subclassing, configurable via XML - but not to integrate as a part of something else (as much I would like to have it that way today). It's pretty monolithic, with lots of dependencies between the internal core classes.

> Or maybe a large wrapper, which uses libsynthesis
> as intended, to sync into a local database, and then write an opensync
> plugin to sync against that database.

That sounds like an interesting approach. It'll sure be easier to implement and debug, and would nicely decouple the different designs. Still, by tuning that local database (which maybe can be reduced to some in-memory data forwarder), there's a lot of access into the data stream when needed.

Best Regards,

Lukas

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Thu, Oct 27, 2011 at 12:17:40PM +0200, deloptes wrote:
> From my point of view this is doable, also the current libsyncml is doing
> most of the same. I think if no one wants to maintain this library
> libsynthesis can safely replace it. Perhaps there would be some more work
> on the transport stuff, which I saw in SyncEvolution, but didn't have time
> to study.

I suspect it is technically possible, but it might require some changes
to libsynthesis. :-)  Or maybe a large wrapper, which uses libsynthesis
as intended, to sync into a local database, and then write an opensync
plugin to sync against that database.


> Chris, guys what is your opinion? Can we arrange a kickoff meeting in some
> irc or skype or so?

I think email is best.  Until we have real technical details to discuss,
or even proof-of-concept code, we might be just sitting around reading
documentation together. :-)

- Chris

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Lukas, thank you for your input, it is really great, that you posted this
information.
I just had an overview of the documentation and the sample code and had a
look into SyncEvolution. I recall a discussion with Patrick and his
analysis where he said it's virtually impossible because of opensync's
architecture, so I want to find out if it is feasible at the end and some
time and work is worth to put into this. I'll ask more questions in the
future, but what I need as a starting point is a kind of overview of
possible design.  I'll need some time to read in the docs, but the benefit
is clear, so I really appreciate this discussion. 

Lukas Zeller wrote:

> 
>> If I wanted to just talk to a SyncML device, get latest changes, get all
>> changes, delete records, add/modify changes, and then disconnect, would
>> that be possible with libsynthesis?
> 
> Unlike many of today's web APIs, a SyncML session has an awful lot of
> state - you can't use it to just ask for something in a REST-like manner.
> 
> The order of how you have to do the read and write operations is very
> strict in SyncML. Much in libsynthesis is about getting this order right,
> including numerous workarounds for peers that do it wrong. So libsynthesis
> has to be in control of the sync session from start to end.
> 
> On the DB backend API side, it calls out to plugins to get list of
> changes, read items, insert/update/delete items.
> 
> On the application API side, you can edit the client settings (URL,
> syncmode etc. - much what you see in a phone SyncML client, or my iOS
> apps), then initialize a session, and then "step" through the session.
> This means, it's not a single syncNow() function that blocks everything
> for a long time, but you have your own main loop which repeatedly calls
> the SessionStep() API function until the sync is done. SessionStep() has
> different return values, and informs you when a SyncML message is ready to
> be delivered to the peer, or when a SyncML response is expected from the
> peer. So the implementation of transporting messages (via HTTP, BT,
> whatever) is not in libsynthesis, but must (can!) be done in the calling
> code.
> 

>From my point of view this is doable, also the current libsyncml is doing
most of the same. I think if no one wants to maintain this library
libsynthesis can safely replace it. Perhaps there would be some more work
on the transport stuff, which I saw in SyncEvolution, but didn't have time
to study.

Chris, guys what is your opinion? Can we arrange a kickoff meeting in some
irc or skype or so?

regards

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Lukas Z. <lu...@pl...>]

Hello,

On Oct 24, 2011, at 23:14 , Chris Frey wrote:

> On Sun, Oct 23, 2011 at 12:40:35PM +0200, deloptes wrote:
>> My proposal is to discuss it here and I'm asking for input basically to work
>> out the design.
>>> From the akonadi-plugin experience it is clear what needs to be done on the
>> opensync side, so I need some ideas how synthesis can be brought into the
>> game.
>> 
>> I was thinking perhaps to take over the syncml library, but it looks like
>> there is too much SyncML stuff to care about, which is already done in
>> synthesis.
>> 
>> If one of you is interested to assist, please let me know.
> 
> I'm willing to help answer opensync questions and general C and C++ questions
> as I am able.  I'm not a libsynthesis expert, so I don't have much to offer
> in that regard.
> 
> It appears that libsynthesis is also an engine.  I don't know if that will
> get in the way of turning it into an opensync plugin.  You'll have to find
> out first if you can use libsynthesis like an API, or whether you have to
> use it like a plugin.
> 
> Maybe other people more familiar with the library can answer this.

I'm not familiar with Opensync, but I wrote most of libsynthesis. Indeed, libsynthesis is a SyncML engine which has two APIs:

- one to use the library in an application to provide SyncML sync (client or server)
- another for datastore backend plugins, which are *called* by the engine to read/write/delete data.

So the question is if this can fit into the Opensync picture somehow. As libsynthesis was not designed to be integrated as a subsystem of an overall sync architecture as Opensync, it might be difficult.

Best Regards,

Lukas Zeller, plan44.ch
lu...@pl... - www.plan44.ch

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Lukas Z. <lu...@pl...>]

Hello Chris,

On Oct 25, 2011, at 10:14 , Chris Frey wrote:

> Thanks... I'm guessing you meant for this to go to the mailing list? :-)

Yes, sorry. I just sent it again to the list.

> If I wanted to just talk to a SyncML device, get latest changes, get all
> changes, delete records, add/modify changes, and then disconnect, would
> that be possible with libsynthesis?

Unlike many of today's web APIs, a SyncML session has an awful lot of state - you can't use it to just ask for something in a REST-like manner.

The order of how you have to do the read and write operations is very strict in SyncML. Much in libsynthesis is about getting this order right, including numerous workarounds for peers that do it wrong. So libsynthesis has to be in control of the sync session from start to end.

On the DB backend API side, it calls out to plugins to get list of changes, read items, insert/update/delete items.

On the application API side, you can edit the client settings (URL, syncmode etc. - much what you see in a phone SyncML client, or my iOS apps), then initialize a session, and then "step" through the session. This means, it's not a single syncNow() function that blocks everything for a long time, but you have your own main loop which repeatedly calls the SessionStep() API function until the sync is done. SessionStep() has different return values, and informs you when a SyncML message is ready to be delivered to the peer, or when a SyncML response is expected from the peer.
So the implementation of transporting messages (via HTTP, BT, whatever) is not in libsynthesis, but must (can!) be done in the calling code.

Best Regards,

Lukas Zeller, plan44.ch
lu...@pl... - www.plan44.ch

Re: [Opensync-devel] Discussion: syncml plugin with synthesis

[Chris F. <cd...@fo...>]

On Sun, Oct 23, 2011 at 12:40:35PM +0200, deloptes wrote:
> My proposal is to discuss it here and I'm asking for input basically to work
> out the design.
> >From the akonadi-plugin experience it is clear what needs to be done on the
> opensync side, so I need some ideas how synthesis can be brought into the
> game.
> 
> I was thinking perhaps to take over the syncml library, but it looks like
> there is too much SyncML stuff to care about, which is already done in
> synthesis.
> 
> If one of you is interested to assist, please let me know.

I'm willing to help answer opensync questions and general C and C++ questions
as I am able.  I'm not a libsynthesis expert, so I don't have much to offer
in that regard.

It appears that libsynthesis is also an engine.  I don't know if that will
get in the way of turning it into an opensync plugin.  You'll have to find
out first if you can use libsynthesis like an API, or whether you have to
use it like a plugin.

Maybe other people more familiar with the library can answer this.

- Chris

[Opensync-devel] Discussion: syncml plugin with synthesis

[deloptes <del...@ya...>]

Hi, guys, I'm thinking about writing a plugin that uses the synthesis
engine.
I read about synthesis last year, but I was busy with too many business
stuff to work on something like this.

My proposal is to discuss it here and I'm asking for input basically to work
out the design.
>From the akonadi-plugin experience it is clear what needs to be done on the
opensync side, so I need some ideas how synthesis can be brought into the
game.

I was thinking perhaps to take over the syncml library, but it looks like
there is too much SyncML stuff to care about, which is already done in
synthesis.

If one of you is interested to assist, please let me know.

Your opinion and estimates are really appreciated.

regards

[Opensync-devel] file renames to resolve version conflicts

[Chris F. <cd...@fo...>]

Hi,

The following commits have been added to the opensync git repo, to resolve
naming conflicts between opensync 0.2x packages and 0.4x packages:


commit 0a1eb5c84b641a02fa75f507844172f9a5d891d9
Author: Chris Frey <cd...@fo...>
Date:   Thu Oct 20 00:03:33 2011 -0400

    Renamed python module to opensync1, so it can coexist with 0.2x

commit 1f9e2f3852ee206a2fea506d248a0f006bba4659
Author: Chris Frey <cd...@fo...>
Date:   Wed Oct 19 23:50:45 2011 -0400

    Renamed some internal variables in osync1plugin to match new program name

commit 46825b649f531899b8623aa4050f84692e8da839
Author: Chris Frey <cd...@fo...>
Date:   Wed Oct 19 23:49:21 2011 -0400

    Renamed tools from osync* to osync1*, so they can coexist with 0.2x



I think this is a good move for python, since the API changed anyway.
And for the tools/ renames, these are mostly debug and development tools
anyway, so I don't see much impact.

Let me know if you think differently.

Thanks,
- Chris

Re: [Opensync-devel] make test doubts

[Chris F. <cd...@fo...>]

On Fri, Sep 23, 2011 at 10:48:17PM -0400, Chris Frey wrote:
> On Sun, Sep 04, 2011 at 05:40:08PM -0300, Luiz Angelo Daros de Luca wrote:
> > The following tests FAILED:
> >          39 - filter_destobjtype_delete (Failed)
> >         152 - engine_error_get_changes_disconnect_error (Failed)
> 
> These two are fixed now.

There were two more reported by others:

Henrik /KaarPoSoft reported:

     104 - engine_sync_reuse (Failed)
opensync-cdf/tests/engine-tests/check_engine.c:1321:E:engine_sync_reuse:function
+:0:
(after this point) Test timeout expired

This is a timeout, and might be connected to how busy the machine
is during the test.  To my knowledge, I haven't see this one yet.


Juergen Leising reported:

        107 - engine_sync_read_write_stress (Failed)

I did reproduce this one, but it was during heavy system load, and
ended up being a timeout as well:

	Running suite(s): engine
	0%: Checks: 1, Failures: 0, Errors: 1
	/home/cdfrey/software/opensync/git/opensync/tests/engine-tests/check_engine.c:1799:E:engine_sync_read_write_stress:function:0: (after this point) Test timeout expired
	<end of output>
	Test time =  30.05 sec


So I'm operating under the assumption that the serious test suite
bugs are all fixed, until someone finds more. :-)

Thanks,
- Chris

Re: [Opensync-devel] make test doubts

[Chris F. <cd...@fo...>]

On Sun, Sep 04, 2011 at 05:40:08PM -0300, Luiz Angelo Daros de Luca wrote:
> The following tests FAILED:
>          39 - filter_destobjtype_delete (Failed)
>         152 - engine_error_get_changes_disconnect_error (Failed)

These two are fixed now.

- Chris

[Opensync-devel] fixed: evolution syncing problem with get_changes on Debian Squeeze

[Chris F. <cd...@fo...>]

Hi,

Thought I should post this here as well.  The evolution-data-server
distributed with Debian Squeeze (stable) has a bug in the addressbook
get_changes call, and therefore does not return any changes even if
some were made in evolution.

The patch is available here:

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641898

I hope that the next point release of Squeeze will have this fixed, as
well as in Ubuntu.

- Chris

Re: [Opensync-devel] make test doubts

[Luiz A. D. de L. <lui...@gm...>]

It works! Thanks!

Now, just these two tests failed for me:

The following tests FAILED:
         39 - filter_destobjtype_delete (Failed)
        152 - engine_error_get_changes_disconnect_error (Failed)

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...


2011/9/2 Chris Frey <cd...@fo...>

> On Fri, Sep 02, 2011 at 12:52:55PM -0300, Luiz Angelo Daros de Luca wrote:
> > Hello,
> >
> > I'm trying to run some of the opensync test (make test) but with no luck
> > inside the binary-meta.
> > Is the "make test" supposed to be executed after or before a make
> install?
>
> It's supposed to be available before install.
>
> The failures are due to the RPATH being disabled.  Whoops.
>
> I've turned on RPATH again by default, for source-only builds.  If you
> really want RPATH disabled for source builds, do:
>
>        make USE_RPATH=off src
>
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] [PATCH]: rename plugin set_xxx callbacks to use _func suffix

[Chris F. <cd...@fo...>]

Merged.  Thanks!

- Chris


On Sat, Aug 27, 2011 at 05:55:19PM -0300, Luiz Angelo Daros de Luca wrote:
> Chris,
> 
> Now I createad all github repos, each project patch and I'm submitting
> the rename again:
> 
> git://github.com/luizluca/opensync-akonadi.git
> git://github.com/luizluca/opensync-barry.git
> git://github.com/luizluca/opensync-evolution2.git
> git://github.com/luizluca/opensync-file-sync.git
> git://github.com/luizluca/opensync-google-calendar.git
> git://github.com/luizluca/opensync-kdepim.git
> git://github.com/luizluca/opensync-luizluca.git
> 
> All using branch rename_plugin_callbacks
> 
> Is it the best way to submit patches?
> 
> Regards,
> 
> ---
> ?? ???? Luiz Angelo Daros de Luca, Me.
> ?? ?? ?? ?? ?? ?? lui...@gm...
> 
> 
> 
> 2011/7/3 Luiz Angelo Daros de Luca <lui...@gm...>:
> > Hello Chris,
> >
> > I'm back online (back from FISL12). Maybe in the future I can present
> > some stuff about opensync on it ;-)
> >
> > git://github.com/luizluca/opensync-luizluca.git branch rename_plugin_callbacks
> >
> > I also have some other branches on it that I might discuss in the
> > future. I don't know how I could proceed with the plugin's code. The
> > fix on them is trivial.
> >
> > Feel free to comment the patch.
> >
> > Regards,
> >
> > ---
> > ?? ???? Luiz Angelo Daros de Luca, Me.
> > ?? ?? ?? ?? ?? ?? lui...@gm...
> >
> >
> >
> > 2011/6/30 Chris Frey <cd...@fo...>:
> >> Hi Luiz,
> >>
> >> Talk about dropping the ball on this one. ??Sorry about that.
> >> Just getting to this now.
> >>
> >> Unfortunately, the patch is encoded as utf-8, and even when using
> >> utf-8 here, git am complains.
> >>
> >> Seems to be using odd characters on the tabs, or the context lines of
> >> the diff.
> >>
> >> Could you send the patch again, or even better, point me to your git
> >> repo?
> >>
> >> Thanks
> >> - Chris
> >>
> >>
> >>
> >> On Fri, Jun 10, 2011 at 03:10:53AM -0300, Luiz Angelo Daros de Luca wrote:
> >>> Renames the methods that define plugin callbacks:
> >>>
> >>> osync_plugin_set_initialize??->??osync_plugin_set_initialize_func
> >>> osync_plugin_set_finalize??->??osync_plugin_set_finalize_func
> >>> osync_plugin_set_discover??->??osync_plugin_set_discover_func
> >>>
> >>> This makes the callback definition methods similar to the respective
> >>> methods in plugin, format and sink.
> >>>
> >>>
> >>> >From 625b78ba3888ed99235ff71a07e656f4b29d6909 Mon Sep 17 00:00:00 2001
> >>> From: Luiz Angelo Daros de Luca <lui...@gm...>
> >>> Date: Wed, 8 Jun 2011 03:34:45 -0300
> >>> Subject: [PATCH 1/1] - Renamed osync_plugin_set_xxx callbacks function
> >>> to use _func suffix
> >>>
> >>> Signed-off-by: Luiz Angelo Daros de Luca <lui...@gm...>
> >>> ---
> >>> ??docs/examples/plugins/src/external_demo.c ?? ?? ?? ?? ??| ?? ??6 ++--
> >>> ??docs/examples/plugins/src/plugin.c ?? ?? ?? ?? ?? ?? ?? ?? | ?? ??6 ++--
> >>> ??docs/examples/plugins/src/simple_plugin.c ?? ?? ?? ?? ??| ?? ??6 ++--
> >>> ??.../plugins/src/simple_plugin_static_caps.c ?? ?? ?? ??| ?? ??6 ++--
> >>> ??opensync/plugin/opensync_plugin.c ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >>> ??opensync/plugin/opensync_plugin.h ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >>> ??tests/engine-tests/check_engine.c ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? 28 ++++++++++----------
> >>> ??tests/engine-tests/check_engine_error.c ?? ?? ?? ?? ?? ??| ?? ??8 +++---
> >>> ??tests/mock-plugin/mock_sync.c ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??| ?? ??6 ++--
> >>> ??9 files changed, 39 insertions(+), 39 deletions(-)
> >>> diff --git a/docs/examples/plugins/src/external_demo.c
> >>> b/docs/examples/plugins/src/external_demo.c
> >>> index adfbd5e..df59d6d 100644
> >>> --- a/docs/examples/plugins/src/external_demo.c
> >>> +++ b/docs/examples/plugins/src/external_demo.c
> >>> @@ -122,9 +122,9 @@ int main(int argc, char **argv)
> >>> ?? if (!plugin)
> >>> ?? goto error;
> >>>
> >>> - osync_plugin_set_initialize(plugin, initialize);
> >>> - osync_plugin_set_finalize(plugin, finalize);
> >>> - osync_plugin_set_discover(plugin, discover);
> >>> + osync_plugin_set_initialize_func(plugin, initialize);
> >>> + osync_plugin_set_finalize_func(plugin, finalize);
> >>> + osync_plugin_set_discover_func(plugin, discover);
> >>>
> >>>
> >>> ?? /** Client */
> >>> diff --git a/docs/examples/plugins/src/plugin.c
> >>> b/docs/examples/plugins/src/plugin.c
> >>> index eb3edb5..99dcdbf 100644
> >>> --- a/docs/examples/plugins/src/plugin.c
> >>> +++ b/docs/examples/plugins/src/plugin.c
> >>> @@ -402,9 +402,9 @@ osync_bool get_sync_info(OSyncPluginEnv
> >>> *pluginenv, OSyncError **error)
> >>> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>>
> >>> ?? //Now set the function we made earlier
> >>> - osync_plugin_set_initialize(plugin, initialize);
> >>> - osync_plugin_set_finalize(plugin, finalize);
> >>> - osync_plugin_set_discover(plugin, discover);
> >>> + osync_plugin_set_initialize_func(plugin, initialize);
> >>> + osync_plugin_set_finalize_func(plugin, finalize);
> >>> + osync_plugin_set_discover_func(plugin, discover);
> >>>
> >>> ?? if (!osync_plugin_env_register_plugin(pluginenv, plugin, error))
> >>> ?? goto error;
> >>> diff --git a/docs/examples/plugins/src/simple_plugin.c
> >>> b/docs/examples/plugins/src/simple_plugin.c
> >>> index 0b37770..313d859 100644
> >>> --- a/docs/examples/plugins/src/simple_plugin.c
> >>> +++ b/docs/examples/plugins/src/simple_plugin.c
> >>> @@ -322,9 +322,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >>> OSyncError **error)
> >>> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>>
> >>> ?? //Now set the function we made earlier
> >>> - osync_plugin_set_initialize(plugin, initialize);
> >>> - osync_plugin_set_finalize(plugin, finalize);
> >>> - osync_plugin_set_discover(plugin, discover);
> >>> + osync_plugin_set_initialize_func(plugin, initialize);
> >>> + osync_plugin_set_finalize_func(plugin, finalize);
> >>> + osync_plugin_set_discover_func(plugin, discover);
> >>>
> >>> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >>> ?? goto error;
> >>> diff --git a/docs/examples/plugins/src/simple_plugin_static_caps.c
> >>> b/docs/examples/plugins/src/simple_plugin_static_caps.c
> >>> index c70847d..091fcfc 100644
> >>> --- a/docs/examples/plugins/src/simple_plugin_static_caps.c
> >>> +++ b/docs/examples/plugins/src/simple_plugin_static_caps.c
> >>> @@ -321,9 +321,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >>> OSyncError **error)
> >>> ?? osync_plugin_set_description(plugin, "A longer description. < 200 chars");
> >>>
> >>> ?? //Now set the function we made earlier
> >>> - osync_plugin_set_initialize(plugin, initialize);
> >>> - osync_plugin_set_finalize(plugin, finalize);
> >>> - osync_plugin_set_discover(plugin, discover);
> >>> + osync_plugin_set_initialize_func(plugin, initialize);
> >>> + osync_plugin_set_finalize_func(plugin, finalize);
> >>> + osync_plugin_set_discover_func(plugin, discover);
> >>>
> >>> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >>> ?? goto error;
> >>> diff --git a/opensync/plugin/opensync_plugin.c
> >>> b/opensync/plugin/opensync_plugin.c
> >>> index b22200d..3afb93a 100644
> >>> --- a/opensync/plugin/opensync_plugin.c
> >>> +++ b/opensync/plugin/opensync_plugin.c
> >>> @@ -165,20 +165,20 @@ void osync_plugin_set_start_type(OSyncPlugin
> >>> *plugin, OSyncStartType start_type)
> >>> ?? plugin->start_type = start_type;
> >>> ??}
> >>>
> >>> -void osync_plugin_set_initialize(OSyncPlugin *plugin, initialize_fn init)
> >>> +void osync_plugin_set_initialize_func(OSyncPlugin *plugin, initialize_fn init)
> >>> ??{
> >>> ?? osync_assert(plugin);
> >>> ?? plugin->initialize = init;
> >>> ??}
> >>>
> >>> -void osync_plugin_set_finalize(OSyncPlugin *plugin, finalize_fn fin)
> >>> +void osync_plugin_set_finalize_func(OSyncPlugin *plugin, finalize_fn fin)
> >>> ??{
> >>> ?? osync_assert(plugin);
> >>>
> >>> ?? plugin->finalize = fin;
> >>> ??}
> >>>
> >>> -void osync_plugin_set_discover(OSyncPlugin *plugin, discover_fn discover)
> >>> +void osync_plugin_set_discover_func(OSyncPlugin *plugin, discover_fn discover)
> >>> ??{
> >>> ?? osync_assert(plugin);
> >>> ?? plugin->discover = discover;
> >>> diff --git a/opensync/plugin/opensync_plugin.h
> >>> b/opensync/plugin/opensync_plugin.h
> >>> index dcfb19e..2ce79e3 100644
> >>> --- a/opensync/plugin/opensync_plugin.h
> >>> +++ b/opensync/plugin/opensync_plugin.h
> >>> @@ -210,7 +210,7 @@ OSYNC_EXPORT void
> >>> osync_plugin_set_description(OSyncPlugin *plugin, const char *
> >>> ?? * @param plugin Pointer to the plugin
> >>> ?? * @param init The initialize function for the plugin
> >>> ?? */
> >>> -OSYNC_EXPORT void osync_plugin_set_initialize(OSyncPlugin *plugin,
> >>> initialize_fn init);
> >>> +OSYNC_EXPORT void osync_plugin_set_initialize_func(OSyncPlugin
> >>> *plugin, initialize_fn init);
> >>>
> >>> ??/** @brief Sets the finalize function for a plugin
> >>> ?? *
> >>> @@ -220,7 +220,7 @@ OSYNC_EXPORT void
> >>> osync_plugin_set_initialize(OSyncPlugin *plugin, initialize_fn
> >>> ?? * @param plugin Pointer to the plugin
> >>> ?? * @param fin The finalize function for the plugin
> >>> ?? */
> >>> -OSYNC_EXPORT void osync_plugin_set_finalize(OSyncPlugin *plugin,
> >>> finalize_fn fin);
> >>> +OSYNC_EXPORT void osync_plugin_set_finalize_func(OSyncPlugin *plugin,
> >>> finalize_fn fin);
> >>>
> >>> ??/** @brief Sets the optional discover function for a plugin
> >>> ?? *
> >>> @@ -234,7 +234,7 @@ OSYNC_EXPORT void
> >>> osync_plugin_set_finalize(OSyncPlugin *plugin, finalize_fn fin
> >>> ?? * @param plugin Pointer to the plugin
> >>> ?? * @param discover The discover function for the plugin
> >>> ?? */
> >>> -OSYNC_EXPORT void osync_plugin_set_discover(OSyncPlugin *plugin,
> >>> discover_fn discover);
> >>> +OSYNC_EXPORT void osync_plugin_set_discover_func(OSyncPlugin *plugin,
> >>> discover_fn discover);
> >>>
> >>>
> >>> ??/** @brief Returns the plugin_info data, set by the plugin
> >>> diff --git a/tests/engine-tests/check_engine.c
> >>> b/tests/engine-tests/check_engine.c
> >>> index b7cb9e5..03bf2e8 100644
> >>> --- a/tests/engine-tests/check_engine.c
> >>> +++ b/tests/engine-tests/check_engine.c
> >>> @@ -289,8 +289,8 @@ static OSyncDebugGroup *_create_group(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> @@ -636,8 +636,8 @@ static OSyncDebugGroup *_create_group2(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize_multi);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize_multi);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize_multi);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize_multi);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> @@ -1037,8 +1037,8 @@ static OSyncDebugGroup *_create_group3(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize_order);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize_order);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize_order);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize_order);
> >>>
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> @@ -1271,8 +1271,8 @@ static OSyncDebugGroup *_create_group4(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize_reuse);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize_reuse);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize_reuse);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize_reuse);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> @@ -1550,8 +1550,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize5);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize5);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize5);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize5);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> @@ -1758,8 +1758,8 @@ static OSyncDebugGroup *_create_group6(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize6);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize6);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize6);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize6);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> @@ -1961,8 +1961,8 @@ static OSyncDebugGroup *_create_group7(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize7);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize7);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize7);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize7);
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> ?? fail_unless(debug->client1 != NULL, NULL);
> >>> diff --git a/tests/engine-tests/check_engine_error.c
> >>> b/tests/engine-tests/check_engine_error.c
> >>> index 4eb3f1d..6dd8b40 100644
> >>> --- a/tests/engine-tests/check_engine_error.c
> >>> +++ b/tests/engine-tests/check_engine_error.c
> >>> @@ -210,8 +210,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >>> ?? osync_plugin_set_start_type(debug->plugin, OSYNC_START_TYPE_EXTERNAL);
> >>> ?? osync_plugin_set_config_type(debug->plugin, OSYNC_PLUGIN_NO_CONFIGURATION);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin, initialize_connect_error);
> >>> - osync_plugin_set_finalize(debug->plugin, finalize);
> >>> + osync_plugin_set_initialize_func(debug->plugin, initialize_connect_error);
> >>> + osync_plugin_set_finalize_func(debug->plugin, finalize);
> >>>
> >>>
> >>> ?? debug->plugin2 = osync_plugin_new(&error);
> >>> @@ -223,8 +223,8 @@ static OSyncDebugGroup *_create_group5(char *testbed)
> >>> ?? osync_plugin_set_description(debug->plugin2, "This is a pseudo plugin");
> >>> ?? osync_plugin_set_start_type(debug->plugin2, OSYNC_START_TYPE_EXTERNAL);
> >>>
> >>> - osync_plugin_set_initialize(debug->plugin2, initialize_connect_error);
> >>> - osync_plugin_set_finalize(debug->plugin2, finalize);
> >>> + osync_plugin_set_initialize_func(debug->plugin2, initialize_connect_error);
> >>> + osync_plugin_set_finalize_func(debug->plugin2, finalize);
> >>>
> >>>
> >>> ?? debug->client1 = osync_client_new(&error);
> >>> diff --git a/tests/mock-plugin/mock_sync.c b/tests/mock-plugin/mock_sync.c
> >>> index ecdde36..78f3c32 100644
> >>> --- a/tests/mock-plugin/mock_sync.c
> >>> +++ b/tests/mock-plugin/mock_sync.c
> >>> @@ -794,9 +794,9 @@ osync_bool get_sync_info(OSyncPluginEnv *env,
> >>> OSyncError **error)
> >>> ?? osync_plugin_set_description(plugin, "Plugin to synchronize files on
> >>> the local filesystem for unit tests");
> >>> ?? osync_plugin_set_start_type(plugin, OSYNC_START_TYPE_EXTERNAL);
> >>>
> >>> - osync_plugin_set_initialize(plugin, mock_initialize);
> >>> - osync_plugin_set_finalize(plugin, mock_finalize);
> >>> - osync_plugin_set_discover(plugin, mock_discover);
> >>> + osync_plugin_set_initialize_func(plugin, mock_initialize);
> >>> + osync_plugin_set_finalize_func(plugin, mock_finalize);
> >>> + osync_plugin_set_discover_func(plugin, mock_discover);
> >>>
> >>> ?? if (!osync_plugin_env_register_plugin(env, plugin, error))
> >>> ?? goto error;
> >>> --
> >>> 1.7.4.1
> >>>
> >>> ------------------------------------------------------------------------------
> >>> EditLive Enterprise is the world's most technically advanced content
> >>> authoring tool. Experience the power of Track Changes, Inline Image
> >>> Editing and ensure content is compliant with Accessibility Checking.
> >>> http://p.sf.net/sfu/ephox-dev2dev
> >>> _______________________________________________
> >>> Opensync-devel mailing list
> >>> Ope...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >>
> >> ------------------------------------------------------------------------------
> >> All of the data generated in your IT infrastructure is seriously valuable.
> >> Why? It contains a definitive record of application performance, security
> >> threats, fraudulent activity, and more. Splunk takes this data and makes
> >> sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-d2d-c2
> >> _______________________________________________
> >> Opensync-devel mailing list
> >> Ope...@li...
> >> https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >>
> >

Re: [Opensync-devel] make test doubts

[Chris F. <cd...@fo...>]

On Fri, Sep 02, 2011 at 12:52:55PM -0300, Luiz Angelo Daros de Luca wrote:
> Hello,
> 
> I'm trying to run some of the opensync test (make test) but with no luck
> inside the binary-meta.
> Is the "make test" supposed to be executed after or before a make install?

It's supposed to be available before install.

The failures are due to the RPATH being disabled.  Whoops.

I've turned on RPATH again by default, for source-only builds.  If you
really want RPATH disabled for source builds, do:

	make USE_RPATH=off src

- Chris

[Opensync-devel] make test doubts

[Luiz A. D. de L. <lui...@gm...>]

Hello,

I'm trying to run some of the opensync test (make test) but with no luck
inside the binary-meta.
Is the "make test" supposed to be executed after or before a make install?

If before, make test just fails for every test because it misses some
libraries like inside rootdir/lib and other that are
only inside builddir, like libopensync-testing.so.

If it is supposed to run after the "make install", why this exists in
file-sync test?

ADD_TEST( check_data ${CMAKE_CURRENT_SOURCE_DIR}/check_data
${CMAKE_BINARY_DIR} )

It uses the CMAKE_BINARY_DIR, which is the build dir. Inside the test, this
argument is used for pluginpath suffixed with src:

PLUGINPATH="$1/src"

Clearly, this expects to run before install.


Maybe a "test" target inside the binary-meta makefile would be interesting.
However, it would need to set some env vars as
LD_LIBRARY_PATH and PATH to the respective ones inside source/rootdir.

Another solution would be to set this env inside the test specs, like:

ADD_TEST( check_data ${CMAKE_CURRENT_SOURCE_DIR}/check_data
${CMAKE_BINARY_DIR}/src )
set_property(TEST check_data PROPERTY
    ENVIRONMENT "LD_LIBRARY_PATH=${LIB_INSTALL_DIR}"
    ENVIRONMENT "PATH=${BIN_INSTALL_DIR}:$ENV{PATH}"
)

I don't know it this would break a test outside the binary-meta. Also, this
is cmake 2.8 stuff.

Regards,
---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...

Re: [Opensync-devel] [BUG] Fix printf for size_t on google-calendar

[Chris F. <cd...@fo...>]

Obviously I should have read the man page slower. :-)

I've changed it to %zu, and it works for me.

Thanks Rick and Luiz!

- Chris


On Thu, Sep 01, 2011 at 03:42:41PM -0300, Luiz Angelo Daros de Luca wrote:
> Thanks guys!
> 
> I've seen that %zu is not portable for C90. I guess this is no problem for
> opensync :-)
> 
> As I'm not a C expert, I asked for some help :-)
> 
> Regards,
> 
> ---
>      Luiz Angelo Daros de Luca, Me.
>             lui...@gm...
> 
> 
> 2011/9/1 Rick Scott <rw...@al...>
> 
> > On Thu, 2011-09-01 at 01:26 -0400, Chris Frey wrote:
> > > On Fri, Aug 26, 2011 at 11:21:37PM -0300, Luiz Angelo Daros de Luca
> > wrote:
> > > > Sorry, wrong git URI
> > > >
> > > > git://github.com/luizluca/google-calendar.git fixprintf
> > > >
> > > > I guess %lu is ok for printf, isn't it?
> > >
> > > That works for 64bit, but it balked on my 32 bit. :-)
> > >
> > > I like the %lu, but added a cast, so it works on both 32 and 64bit.
> > >
> >
> > %zu works for both.
> >
> > > Thanks!
> > > - Chris
> > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > Special Offer -- Download ArcSight Logger for FREE!
> > > Finally, a world-class log management solution at an even better
> > > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > > download Logger. Secure your free ArcSight Logger TODAY!
> > > http://p.sf.net/sfu/arcsisghtdev2dev
> > > _______________________________________________
> > > Opensync-devel mailing list
> > > Ope...@li...
> > > https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
> >

> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] [BUG] Fix printf for size_t on google-calendar

[Luiz A. D. de L. <lui...@gm...>]

Thanks guys!

I've seen that %zu is not portable for C90. I guess this is no problem for
opensync :-)

As I'm not a C expert, I asked for some help :-)

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...


2011/9/1 Rick Scott <rw...@al...>

> On Thu, 2011-09-01 at 01:26 -0400, Chris Frey wrote:
> > On Fri, Aug 26, 2011 at 11:21:37PM -0300, Luiz Angelo Daros de Luca
> wrote:
> > > Sorry, wrong git URI
> > >
> > > git://github.com/luizluca/google-calendar.git fixprintf
> > >
> > > I guess %lu is ok for printf, isn't it?
> >
> > That works for 64bit, but it balked on my 32 bit. :-)
> >
> > I like the %lu, but added a cast, so it works on both 32 and 64bit.
> >
>
> %zu works for both.
>
> > Thanks!
> > - Chris
> >
> >
> >
> ------------------------------------------------------------------------------
> > Special Offer -- Download ArcSight Logger for FREE!
> > Finally, a world-class log management solution at an even better
> > price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> > download Logger. Secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsisghtdev2dev
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] [BUG] Fix printf for size_t on google-calendar

[Rick S. <rw...@al...>]

On Thu, 2011-09-01 at 01:26 -0400, Chris Frey wrote:
> On Fri, Aug 26, 2011 at 11:21:37PM -0300, Luiz Angelo Daros de Luca wrote:
> > Sorry, wrong git URI
> > 
> > git://github.com/luizluca/google-calendar.git fixprintf
> > 
> > I guess %lu is ok for printf, isn't it?
> 
> That works for 64bit, but it balked on my 32 bit. :-)
> 
> I like the %lu, but added a cast, so it works on both 32 and 64bit.
> 

%zu works for both.

> Thanks!
> - Chris
> 
> 
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better 
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] Patch for evolution plugin

[Chris F. <cd...@fo...>]

On Tue, Aug 23, 2011 at 12:28:48PM +0200, Nicolas wrote:
> I have just updated my distribution (debian sid), and now I have the
> same issue for calendar :

If I were to try to reproduce this, should I try 32 or 64bit sid?

Thanks!
- Chris

Re: [Opensync-devel] [BUG] Fix printf for size_t on google-calendar

[Chris F. <cd...@fo...>]

On Fri, Aug 26, 2011 at 11:21:37PM -0300, Luiz Angelo Daros de Luca wrote:
> Sorry, wrong git URI
> 
> git://github.com/luizluca/google-calendar.git fixprintf
> 
> I guess %lu is ok for printf, isn't it?

That works for 64bit, but it balked on my 32 bit. :-)

I like the %lu, but added a cast, so it works on both 32 and 64bit.

Thanks!
- Chris

Re: [Opensync-devel] Binary meta fails at "make fetch"

[Chris F. <cd...@fo...>]

On Fri, Aug 26, 2011 at 12:02:46PM -0300, Luiz Angelo Daros de Luca wrote:
> Hello Chris,
> 
> I just got a cellphone (and now I can play again with opensync). It is
> a simple samsung C3200 that does not work
> with any tool under linux. :-)

Looks like you'll be doing some opensync hacking then. :-)


> I saw that binary-meta now has more interesting make options.

Yep, they are being added, slowly but surely.


> I tried "make fetch" from a clean git
> and got this error:
> 
> (...)
> Receiving objects: 100% (747/747), 211.94 KiB | 93 KiB/s, done.
> Resolving deltas: 100% (539/539), done.
> Submodule path 'sources/kdepim': checked out
> '8a793cfb5e07a6f7443cdd00d8de18cdf0bf1b5c'
> fatal: destination path 'sources/opensync' already exists and is not
> an empty directory.
> Clone of 'git://repo.or.cz/opensync/opensync-cdf.git' into submodule
> path 'sources/opensync' failed
> make: ** [fetch] Erro 1

The only way a build/ directory should show up in the sources/opensync
tree is if you did a 'make src' earlier.  I'm not sure why git
would have failed there.

But you can clean your tree with a 'make clean' as well.  This uses
'git clean -xdf' in each submodule, and 'git clean -xdff' in the root,
to do the cleaning.   So changes you make to files that git
knows about will stay... but files that git does _not_ know about will
be lost, so use caution.  You may want to play around with it to see
what it does. :-)

Just remember that there are basically 3 different modes:

	src - just builds the code and installs it inside the tree

	debian packages - deb files show up under debian/

	rpm packages - rpm files show up under ~/rpmbuild/RPMS

The RPM support is lagging behind the debian support at the moment.

- Chris

Re: [Opensync-devel] binary-meta project: opensync git repos and binary packages

[Chris F. <cd...@fo...>]

On Thu, Aug 25, 2011 at 09:19:45AM +0200, Nicolas wrote:
> Libs are installed into ~/rpmbuild/BUILDROOT/xxx/usr/lib
> instead of lib64.
> 
> Then, the RPM script seeks the libs into lib64 (and of course found
> none)

Thanks again for reporting this!

I've fixed the opensync-latest.spec file for the base library.

I haven't tackled the autoconf and 0.2x side of things yet.

- Chris