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

Re: [Opensync-devel] python warning: 'set' conflicts with a built-in name

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

On Tue, Jun 05, 2012 at 07:29:58PM -0400, Chris Frey wrote:
> If MysteryFunction() does not exist, then I need to use a serious hack,
> and wrap the Error object in another struct, so that the OSyncError pointer
> can change at will.

I was unable to find the MysteryFunction, but I believe I avoided any
serious hackage.

I also fixed a leak in the Error object's get_child(), and used the same
technique in other places in the code.

For those interested, the changes are here, and included in binary-meta:

	http://repo.or.cz/w/opensync/opensync-cdf.git

- Chris

Re: [Opensync-devel] python warning: 'set' conflicts with a built-in name

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

On Tue, Jun 05, 2012 at 07:29:58PM -0400, Chris Frey wrote:
> If MysteryFunction() does not exist, then I need to use a serious hack,
> and wrap the Error object in another struct, so that the OSyncError pointer
> can change at will.

Just to give an impression of the hack, it's below.  And yes, this does
fix the issue demonstrated by this script:


------------
#!/usr/bin/python
import opensync1
e = opensync1.Error("First error msg")
print e.print_stack()
e.set_error(opensync1.ERROR_GENERIC, "Second error msg")
print e.get_msg()
print e.print_stack()
------------

Output should be:

ROOT CAUSE: "First error msg"
Second error msg
NEXT ERROR: "Second error msg"
ROOT CAUSE: "First error msg"



But without the patch below, it shows:

ROOT CAUSE: "First error msg"
First error msg
ROOT CAUSE: "First error msg"


- Chris



diff --git a/sources/opensync/wrapper/opensync-error.i b/sources/opensync/wrapper/opensync-error.i
index 71ea33d..dd73b7b 100644
--- a/sources/opensync/wrapper/opensync-error.i
+++ b/sources/opensync/wrapper/opensync-error.i
@@ -1,63 +1,100 @@
 typedef struct {} Error;
 %feature("exceptionclass") Error;
 %extend Error {
+	/*
+	 * Hackery notice: we currently wrap the Error pointer (which is
+	 * a typedef of OSyncError) inside an ErrorWrapper struct, defined
+	 * in the header section of opensync.i.  This wrapper struct is
+	 * used to hold the real Error pointer, which can change at will
+	 * due to some opensync API calls.  We then cast the ErrorWrapper
+	 * pointer back to an Error pointer and pass it back into the
+	 * Python workings, to use as the PyCObject void pointer.
+	 * We cast it back to ErrorWrapper when we need to use it.
+	 *
+	 * If there were a way to extract the PyObject from the PyCObject,
+	 * then this hackery would not be necessary.  Unfortunately, I don't
+	 * know how, or if it is possible.  - cdf
+	 *
+	 * The ErrorWrapper pointers are named 'eww' in honour of its hackery.
+	 */
+
 	/* called by python-module plugin */
 	Error(PyObject *obj) {
-		Error *error = PyCObject_AsVoidPtr(obj);
-		osync_error_ref(&error);
-		return error;
+		ErrorWrapper *eww = calloc(1, sizeof(ErrorWrapper));
+		ErrorWrapper *other = PyCObject_AsVoidPtr(obj);
+		eww->error = other->error;
+		osync_error_ref(&eww->error);
+		return (Error*) eww;
 	}
 
 	Error(const char *msg, ErrorType type=OSYNC_ERROR_GENERIC) {
-		Error *error = NULL;
-		osync_error_set(&error, type, "%s", msg);
-		return error;
+		ErrorWrapper *ew = calloc(1, sizeof(ErrorWrapper));
+		osync_error_set(&ew->error, type, "%s", msg);
+		return (Error*) ew;
 	}
 
 	~Error() {
-		osync_error_unref(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		osync_error_unref(&eww->error);
+		free(eww);
 	}
 
 	const char *get_name() {
-		return osync_error_get_name(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		return osync_error_get_name(&eww->error);
 	}
 
 	bool is_set() {
-		return osync_error_is_set(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		return osync_error_is_set(&eww->error);
 	}
 
 	ErrorType get_type() {
-		return osync_error_get_type(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		return osync_error_get_type(&eww->error);
 	}
 
 	void set_type(ErrorType type) {
-		osync_error_set_type(&self, type);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		osync_error_set_type(&eww->error, type);
 	}
 
 	const char *get_msg() { // 'print' is a reserved word
-		return osync_error_print(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		return osync_error_print(&eww->error);
 	}
 
 	char *print_stack() {
-		return osync_error_print_stack(&self);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		return osync_error_print_stack(&eww->error);
 	}
 
 	void set_from_error(Error *source) {
-		osync_error_set_from_error(&self, &source);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		ErrorWrapper *ewwsource = (ErrorWrapper*) source;
+		osync_error_set_from_error(&eww->error, &ewwsource->error);
 	}
 
-	void set(ErrorType type, const char *msg) {
-		osync_error_set(&self, type, "%s", msg);
+	void set_error(ErrorType type, const char *msg) {
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		osync_error_set(&eww->error, type, "%s", msg);
 	}
 
 	void stack(Error *child) {
-		osync_error_stack(&self, &child);
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		osync_error_stack(&eww->error, &child);
 	}
 
 	Error *get_child() {
-		Error *ret = osync_error_get_child(&self);
-		if (ret)
+		ErrorWrapper *eww = (ErrorWrapper*) self;
+		Error *ret = osync_error_get_child(&eww->error);
+		if (ret) {
+			/* Hackery: memory leak */
+			eww = calloc(1, sizeof(ErrorWrapper));
 			osync_error_ref(&ret);
+			eww->error = ret;
+			return (Error*) eww;
+		}
 		return ret;
 	}
 
diff --git a/sources/opensync/wrapper/opensync.i b/sources/opensync/wrapper/opensync.i
index 2e5edd4..2c2347d 100644
--- a/sources/opensync/wrapper/opensync.i
+++ b/sources/opensync/wrapper/opensync.i
@@ -56,6 +56,11 @@ typedef OSyncXMLField XMLField;
 typedef OSyncXMLFieldList XMLFieldList;
 typedef OSyncXMLFormat XMLFormat;
 
+/* struct wrapper for OSyncError, since the API can change the actual pointer*/
+typedef struct {
+	Error *error;
+} ErrorWrapper;
+
 /* make SWIG treat osync_bool as real Python booleans */
 typedef osync_bool bool;
 #define true TRUE

Re: [Opensync-devel] python warning: 'set' conflicts with a built-in name

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

On Mon, Jun 04, 2012 at 11:41:11PM +0200, Nicolas wrote:
> Le lundi 04 juin 2012 ?? 17:08 -0400, Chris Frey a ??crit :
> > wrapper/opensync-error.i:51: Warning 321: 'set' conflicts with a built-in name in python
> > 
> > I'm thinking that renaming the member from "set" to "set_error" is the
> > best solution, but I'm not a python guy, so maybe there's an even better
> > way?
> > 
> > Let me know... otherwise, I'll rename it. :-)
> 
> Indeed, I have renamed.
> 
> Not yet published, because I haven't already tested my modifications.

In my testing, I've run into a problem that occurs with or without the
rename, in my opinion.

The API osync_error_set() actually modifies the OSyncError pointer passed
into it, and this does not play well with Python.

The wrapper code, opensync-error.i uses the PyCObject to store the OSyncError
pointer, but if the pointer changes in a call such as set_error(), then
the Python world has an outdated pointer, and the set_error() member
function has no way to update it, as far as I can see.

The SWIG wrapper automatically passes in the PyCObject to set_error() and
calls it "self", but I don't see any way to find the PyObject from that
"self" PyCObject.  Is there a way?  If there is, then I could just update
it with PyCObject_SetVoidPtr() like below:

wrapper/opensync-error.i:

@@ -46,8 +48,13 @@ typedef struct {} Error;
                osync_error_set_from_error(&self, &source);
        }
 
-       void set(ErrorType type, const char *msg) {
-               osync_error_set(&self, type, "%s", msg);
+       void set_error(ErrorType type, const char *msg) {
+               PyObject *obj = MysteryFunction(self);
+               Error *error = PyCObject_AsVoidPtr(obj);
+               osync_error_set(&error, type, "%s", msg);
+               if( !PyCObject_SetVoidPtr(obj, error) ) {
+                       blah;
+               }
        }

Note the "MysteryFunction" which I need, but don't know if it exists.

If MysteryFunction() does not exist, then I need to use a serious hack,
and wrap the Error object in another struct, so that the OSyncError pointer
can change at will.

Any SWIG experts out there who can point me in the right direction?
I'm currently working on a fairly hacky patch, but I'd rather find that
MysteryFunction. :-)

- Chris

Re: [Opensync-devel] python warning: 'set' conflicts with a built-in name

[Nicolas <pr...@fr...>]

Le lundi 04 juin 2012 à 17:08 -0400, Chris Frey a écrit :
> Hi,
> 
> In compiling the opensync tree on the latest Debian sid, I ran into the
> following warning:
> 
> wrapper/opensync-error.i:51: Warning 321: 'set' conflicts with a built-in name in python
> 
> I'm thinking that renaming the member from "set" to "set_error" is the
> best solution, but I'm not a python guy, so maybe there's an even better
> way?
> 
> Let me know... otherwise, I'll rename it. :-)
> 
> Thanks,
> - Chris

Indeed, I have renamed.

Not yet published, because I haven't already tested my modifications.

Regards,

Nicolas

[Opensync-devel] python warning: 'set' conflicts with a built-in name

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

Hi,

In compiling the opensync tree on the latest Debian sid, I ran into the
following warning:

wrapper/opensync-error.i:51: Warning 321: 'set' conflicts with a built-in name in python

I'm thinking that renaming the member from "set" to "set_error" is the
best solution, but I'm not a python guy, so maybe there's an even better
way?

Let me know... otherwise, I'll rename it. :-)

Thanks,
- Chris

[Opensync-devel] libwbxml 0.11.1

[Michael B. <mic...@cm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

libwbxml 0.11.1 release notes

Download: https://sf.net/projects/libwbxml/files/libwbxml/0.11.1/

Major Changes
=============

  - Fixed performance problems during the parsing and generation of XML
    documents. This introduces a new memory allocation algorithm for
    WBXMLBuffer. Both original patches from the tickets #80 and #81 were
    committed. The patches were supplied by Conrad Irwin.

Minor Changes
=============

  - The tool xml2wbxml is now covered by LGPL v2.1 (or any later).
    Petr Písa? discovered that wbxml2xml and xml2wbxml used different
    licences.  This was a mistake. Aymerick Jehanne and Michael Bell
    (the copyright holders) agreed on using LGPL as licence.
    (ticket #76)
  - Extract node breaks (null'ed) the previous node link to a next node
    (too early clean-up in wbxml_tree_extract_node of wbxml_tree.c).
    The patch was supplied by Mark Ostrer from Websense (ticket #79).

Internal Changes
================

  - Added a trailing newline to the files THANKS and TODO (ticket #77).
  - The parameter malloc_block of the function wbxml_buffer_create_real
    is only used now for the initial memory allocation. The patch for
    ticket #80 introduced a more aggressive algorithm for memory
    re-allocation to support big files.


Special thanks goes to Conrad Irwin, Mark Ostrer (Websense) and Petr
Písa? (RedHat/Fedora).

Best regards

Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+/YwQACgkQ2L0ZGCAwWquNZwCdG5h03QAEfJM2ctOWeF8967SZ
HtYAoMj4GIPpkEOBjtFuYAU46rhU2n3F
=otCp
-----END PGP SIGNATURE-----

Re: [Opensync-devel] [codehelp@debian.org: Status of opensync in Debian - mass removal very likely]

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

On Mon, Mar 05, 2012 at 12:21:56PM +0100, Harald Jenny wrote:
> Well did you talk with some DD's? Maybe there would be an interest in a
> least keeping in experimental for those you are brave enough. If you
> really plan on making a private repo I could help you making the
> packages as Debian compliant as possible so a potential future packager
> might have no problems in reintegrating it (multiarch-compliant,
> hardening, etc).

All the binary packaging that I've done is in the binary-meta git repo,
which can be found here:

	http://repo.or.cz/w/opensync/binary-meta.git

If you would like to take a look at those packages, please do.
Keep in mind that it uses external debian directories, since the
binary-meta repo is really just a git repo of submodules.

The main goal of binary-meta is to make it as easy as possible to
build binary packages from the latest sources, even for end users.
But that doesn't mean that the other details of the Debian packaging
can't be improved.  I'm sure there's lots of improvement that can be done.

If what I'm saying doesn't really make sense, it will become more clear
once you look at how binary-meta does what it does. :-)

- Chris

Re: [Opensync-devel] [codehelp@debian.org: Status of opensync in Debian - mass removal very likely]

[Harald J. <ha...@a-...>]

On Mon, Mar 05, 2012 at 05:57:10AM -0500, Chris Frey wrote:
> Thanks Harald.

Hi Chris

> 
> I've responded, which can be read here:
> 
> http://lists.debian.org/debian-devel/2012/03/msg00104.html

Yep sorry I did not realise this earlier

> 
> Opensync might not make it into Debian.  But I am planning a separate
> apt-get repo for opensync and some of the plugins.  So Opensync users
> won't be completely left out in the cold.

Well did you talk with some DD's? Maybe there would be an interest in a
least keeping in experimental for those you are brave enough. If you
really plan on making a private repo I could help you making the
packages as Debian compliant as possible so a potential future packager
might have no problems in reintegrating it (multiarch-compliant,
hardening, etc).

> 
> - Chris

Kind regards
Harald

> 
> 
> On Mon, Mar 05, 2012 at 09:11:58AM +0100, Harald Jenny wrote:
> > Dear opensync folks,
> > 
> > I guess this may be of interest for you - if you are interested in
> > keeping opensync in Debian I would ask you to get in contact with the
> > maintainers (http://packages.qa.debian.org/o/opensync.html).
> > 
> > Kind regards
> > Harald Jenny
> > 
> > ----- Forwarded message from Neil Williams <cod...@de...> -----
> > 
> > Date: Sat, 3 Mar 2012 23:15:16 +0000
> > From: Neil Williams <cod...@de...>
> > To: deb...@li...
> > Cc: Robert Collins <ro...@ro...>, Michael Banck <mb...@de...>, Matthias Jahn <jah...@fr...>, Jonny Lamb <jo...@de...>
> > Subject: Status of opensync in Debian - mass removal very likely
> > X-Local-Spam-Level: 
> > X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
> > 
> > opensync/multisync is a complete mess, collecting 25 RC bugs between 20
> > source packages and a collective 17,626 days waiting to enter testing.
> > dd-list attached.
> > 
> > Summary:
> > libopensync-plugin-gnokii	1462 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-gpe		1462 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-irmc		976 days old (needed 10 days)	libopensync0	RC
> > libopensync-plugin-kdepim	1025 days old (needed 10 days)	libopensync0	RC
> > libopensync-plugin-moto		1207 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-opie		1190 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-palm		1461 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-python	1347 days old (needed 10 days)	libopensync0	RC x 2
> > libopensync-plugin-sunbird	1456 days old (needed 10 days)	libopensync0	RC x 2
> > osynctool			765 days old (needed 10 days)	RC
> > opensync			663 days old (needed 10 days)	RC x 3
> > libopensync-plugin-xmlformat	754 days old (needed 10 days)	opensync
> > libopensync-plugin-vformat	768 days old (needed 10 days)	opensync
> > libopensync-plugin-syncml	755 days old (needed 10 days)	opensync
> > libopensync-plugin-file		755 days old (needed 10 days)	opensync
> > libopensync-plugin-evolution2	755 days old (needed 10 days)	libcamel-1.2-23 et al
> > multisync0.90			825 days old (needed 10 days)	libopensync0	RC x 2
> > synce-sync-engine		depends opensync, libopensync-plugin-python
> > libopensync-plugin-google-calendar	libopensync0 (experimental) RC x 3
> > synce-kpm				depends on synce-sync-engine
> > 
> > Most depend on libopensync0 which does not exist anymore, those which
> > have been updated are split between libopensync1exp3 and
> > libopensync1exp7. libopensync1exp3 does not exist, libopensync1exp7 has
> > 3 RC bugs.
> > 
> > If there's no response (I'm NOT expecting fixes, just *some* idea of
> > whether these RC bugs *can* be fixed and all the packages migrated to
> > whatever counts as the latest available libopensync version), ALL of
> > these packages will have to be removed. I'm afraid it's SO unlikely
> > that anything is going to be truly fixed by Wheezy, the only real
> > option for a deadline is 7 days to get *SOME* kind of expression of
> > interest, some idea of a plan. Naturally, if the maintainers wish to
> > file the removal bugs themselves, that would be appreciated.
> > 
> > I know all of these have already been removed from testing, but the
> > packages in unstable are completely unusable / not installable. Just
> > leaving RC bugs in unstable for years should not be acceptable.
> > 
> > There are packages in experimental too but those appear to be gathering RC
> > bugs as well, so I'll also file removal bugs for those.
> > 
> > -- 
> > 
> > 
> > Neil Williams
> > =============
> > http://www.linux.codehelp.co.uk/
> > 
> > 
> > 
> > 
> > 
> > 
> > ----- End forwarded message -----
> > 
> > ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] [codehelp@debian.org: Status of opensync in Debian - mass removal very likely]

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

Thanks Harald.

I've responded, which can be read here:

http://lists.debian.org/debian-devel/2012/03/msg00104.html

Opensync might not make it into Debian.  But I am planning a separate
apt-get repo for opensync and some of the plugins.  So Opensync users
won't be completely left out in the cold.

- Chris


On Mon, Mar 05, 2012 at 09:11:58AM +0100, Harald Jenny wrote:
> Dear opensync folks,
> 
> I guess this may be of interest for you - if you are interested in
> keeping opensync in Debian I would ask you to get in contact with the
> maintainers (http://packages.qa.debian.org/o/opensync.html).
> 
> Kind regards
> Harald Jenny
> 
> ----- Forwarded message from Neil Williams <cod...@de...> -----
> 
> Date: Sat, 3 Mar 2012 23:15:16 +0000
> From: Neil Williams <cod...@de...>
> To: deb...@li...
> Cc: Robert Collins <ro...@ro...>, Michael Banck <mb...@de...>, Matthias Jahn <jah...@fr...>, Jonny Lamb <jo...@de...>
> Subject: Status of opensync in Debian - mass removal very likely
> X-Local-Spam-Level: 
> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
> 
> opensync/multisync is a complete mess, collecting 25 RC bugs between 20
> source packages and a collective 17,626 days waiting to enter testing.
> dd-list attached.
> 
> Summary:
> libopensync-plugin-gnokii	1462 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-gpe		1462 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-irmc		976 days old (needed 10 days)	libopensync0	RC
> libopensync-plugin-kdepim	1025 days old (needed 10 days)	libopensync0	RC
> libopensync-plugin-moto		1207 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-opie		1190 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-palm		1461 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-python	1347 days old (needed 10 days)	libopensync0	RC x 2
> libopensync-plugin-sunbird	1456 days old (needed 10 days)	libopensync0	RC x 2
> osynctool			765 days old (needed 10 days)	RC
> opensync			663 days old (needed 10 days)	RC x 3
> libopensync-plugin-xmlformat	754 days old (needed 10 days)	opensync
> libopensync-plugin-vformat	768 days old (needed 10 days)	opensync
> libopensync-plugin-syncml	755 days old (needed 10 days)	opensync
> libopensync-plugin-file		755 days old (needed 10 days)	opensync
> libopensync-plugin-evolution2	755 days old (needed 10 days)	libcamel-1.2-23 et al
> multisync0.90			825 days old (needed 10 days)	libopensync0	RC x 2
> synce-sync-engine		depends opensync, libopensync-plugin-python
> libopensync-plugin-google-calendar	libopensync0 (experimental) RC x 3
> synce-kpm				depends on synce-sync-engine
> 
> Most depend on libopensync0 which does not exist anymore, those which
> have been updated are split between libopensync1exp3 and
> libopensync1exp7. libopensync1exp3 does not exist, libopensync1exp7 has
> 3 RC bugs.
> 
> If there's no response (I'm NOT expecting fixes, just *some* idea of
> whether these RC bugs *can* be fixed and all the packages migrated to
> whatever counts as the latest available libopensync version), ALL of
> these packages will have to be removed. I'm afraid it's SO unlikely
> that anything is going to be truly fixed by Wheezy, the only real
> option for a deadline is 7 days to get *SOME* kind of expression of
> interest, some idea of a plan. Naturally, if the maintainers wish to
> file the removal bugs themselves, that would be appreciated.
> 
> I know all of these have already been removed from testing, but the
> packages in unstable are completely unusable / not installable. Just
> leaving RC bugs in unstable for years should not be acceptable.
> 
> There are packages in experimental too but those appear to be gathering RC
> bugs as well, so I'll also file removal bugs for those.
> 
> -- 
> 
> 
> Neil Williams
> =============
> http://www.linux.codehelp.co.uk/
> 
> 
> 
> 
> 
> 
> ----- End forwarded message -----
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Opensync-devel] [codehelp@debian.org: Status of opensync in Debian - mass removal very likely]

[Harald J. <ha...@a-...>]

Dear opensync folks,

I guess this may be of interest for you - if you are interested in
keeping opensync in Debian I would ask you to get in contact with the
maintainers (http://packages.qa.debian.org/o/opensync.html).

Kind regards
Harald Jenny

----- Forwarded message from Neil Williams <cod...@de...> -----

Date: Sat, 3 Mar 2012 23:15:16 +0000
From: Neil Williams <cod...@de...>
To: deb...@li...
Cc: Robert Collins <ro...@ro...>, Michael Banck <mb...@de...>, Matthias Jahn <jah...@fr...>, Jonny Lamb <jo...@de...>
Subject: Status of opensync in Debian - mass removal very likely
X-Local-Spam-Level: 
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu)

opensync/multisync is a complete mess, collecting 25 RC bugs between 20
source packages and a collective 17,626 days waiting to enter testing.
dd-list attached.

Summary:
libopensync-plugin-gnokii	1462 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-gpe		1462 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-irmc		976 days old (needed 10 days)	libopensync0	RC
libopensync-plugin-kdepim	1025 days old (needed 10 days)	libopensync0	RC
libopensync-plugin-moto		1207 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-opie		1190 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-palm		1461 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-python	1347 days old (needed 10 days)	libopensync0	RC x 2
libopensync-plugin-sunbird	1456 days old (needed 10 days)	libopensync0	RC x 2
osynctool			765 days old (needed 10 days)	RC
opensync			663 days old (needed 10 days)	RC x 3
libopensync-plugin-xmlformat	754 days old (needed 10 days)	opensync
libopensync-plugin-vformat	768 days old (needed 10 days)	opensync
libopensync-plugin-syncml	755 days old (needed 10 days)	opensync
libopensync-plugin-file		755 days old (needed 10 days)	opensync
libopensync-plugin-evolution2	755 days old (needed 10 days)	libcamel-1.2-23 et al
multisync0.90			825 days old (needed 10 days)	libopensync0	RC x 2
synce-sync-engine		depends opensync, libopensync-plugin-python
libopensync-plugin-google-calendar	libopensync0 (experimental) RC x 3
synce-kpm				depends on synce-sync-engine

Most depend on libopensync0 which does not exist anymore, those which
have been updated are split between libopensync1exp3 and
libopensync1exp7. libopensync1exp3 does not exist, libopensync1exp7 has
3 RC bugs.

If there's no response (I'm NOT expecting fixes, just *some* idea of
whether these RC bugs *can* be fixed and all the packages migrated to
whatever counts as the latest available libopensync version), ALL of
these packages will have to be removed. I'm afraid it's SO unlikely
that anything is going to be truly fixed by Wheezy, the only real
option for a deadline is 7 days to get *SOME* kind of expression of
interest, some idea of a plan. Naturally, if the maintainers wish to
file the removal bugs themselves, that would be appreciated.

I know all of these have already been removed from testing, but the
packages in unstable are completely unusable / not installable. Just
leaving RC bugs in unstable for years should not be acceptable.

There are packages in experimental too but those appear to be gathering RC
bugs as well, so I'll also file removal bugs for those.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/






----- End forwarded message -----

Re: [Opensync-devel] syncML devel equipment

[Emanoil K. <del...@ya...>]

Hi all,

Nokia 55xx (and a lot of other Nokia pones) and the Galaxy 2 of Samsung also use SyncML protocol. I also think Samsung is using SyncML in other phones.
It seems to be somehow company policy perhaps because of royalties

regards


--- On Sat, 2/25/12, Sateesh Babu <sat...@gm...> wrote:

From: Sateesh Babu <sat...@gm...>
Subject: Re: [Opensync-devel] syncML devel equipment
To: Juh...@ik...
Cc: ope...@li...
Date: Saturday, February 25, 2012, 7:12 AM



I have N9 meego phone now, haven't really checked what protocols it supports,

but at least it was able to suck - or even sync later on stuff from s60 device

so it might still have syncml implementation.

Nokia N9 has SyncML implementation (1.1, 1.2) 





Tuju

--Sateesh 

-----Inline Attachment Follows-----

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
-----Inline Attachment Follows-----

_______________________________________________
Opensync-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] syncML devel equipment

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

On Sat, 2012-02-25 at 11:42 +0530, Sateesh Babu wrote:
>         
>         I have N9 meego phone now, haven't really checked what
>         protocols it supports,
>         but at least it was able to suck - or even sync later on stuff
>         from s60 device
>         so it might still have syncml implementation.
> 
> 
> Nokia N9 has SyncML implementation (1.1, 1.2)

The N9 might not be a good starting point for the purpose of testing
your own SyncML implementation, because I have seen bugs in the phone's
implementation not found in other Nokia phones.

For example, see
http://lists.syncevolution.org/pipermail/syncevolution/2011-November/003145.html

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

Re: [Opensync-devel] syncML devel equipment

[Sateesh B. <sat...@gm...>]

>
>
> I have N9 meego phone now, haven't really checked what protocols it
> supports,
> but at least it was able to suck - or even sync later on stuff from s60
> device
> so it might still have syncml implementation.
>

Nokia N9 has SyncML implementation (1.1, 1.2)


>
>
> Tuju
>
> --
Sateesh

Re: [Opensync-devel] syncML devel equipment

[Juha T. <Juh...@ik...>]

On Friday 24 February 2012 00:41:53 Chris Frey wrote:
> What phone or device is recommended to do syncML development?
> All I have are blackberries, and I don't think they support it.

Project actually has two devices for that purpose, both are Nokia phones, one 
s60 and one s40 based. bellmich has them as he has been maintaining the 
libsyncml where those are quite essential to have.

Generally nokia phones used to have quite good syncml implementation in my 
understanding compared to others. These are mobile devices so one should not 
compare that to desktop quality imo.

I have N9 meego phone now, haven't really checked what protocols it supports, 
but at least it was able to suck - or even sync later on stuff from s60 device 
so it might still have syncml implementation.


Tuju

-- 
tu...@ik... | http://tuju.fi | sip:tu...@ik...
Better to have one, and not need it, than to need one and not have it.

[Opensync-devel] syncML devel equipment

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

Hi,

What phone or device is recommended to do syncML development?
All I have are blackberries, and I don't think they support it.

- Chris

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

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

On Wed, Feb 22, 2012 at 10:03:41AM -0800, Emanoil Kotsev wrote:
> My plan (and part of it is already coded) is to provide access to the engine via UI Api to make configuration and adjustments over the plugin possible and from the DB API for the data sync.
> How do you feel about it?

You're blazing a trail in new territory, so I would say that the code is
the important part.  The more you code, the more details you'll uncover,
and eventually get to the point where it works. :-)


> Something I also do not understand from programming point of view
> I had a look into SyncEvo and there they use boosts shared pointers. So my question is under which circumstanses are you forced to do it - the name is somehow self explaining - but shared between what and why is something I don't understand


Boost shared pointers (or the shared pointers in the tr1 namespace, which
are the same), are for sharing pointers within the same application.

Smart pointers are designed so that you don't have to worry about when
to free an object.  As soon as the pointer object goes out of scope, then
the object it points to is freed.

If you use std::auto_ptr<>, then only one auto_ptr object has a copy of
the pointer at a time.

	auto_ptr<MyObject> ptr1 (new MyObject);
	auto_ptr<MyObject> ptr2;

	ptr2 = ptr1;	// ptr1 is now null, and cannot be used
			// only ptr2 is valid

You use auto_ptr when you only need one copy of a pointer at any given time.
Often when you're returning a pointer from a function.

	auto_ptr<MyObject> FactoryFunction()
	{
		auto_ptr<MyObject> ptr;
		// ... some hard work

		return ptr;
	}

With a shared_ptr, it keeps track of how many copies exist, and only frees
the real object when the last pointer disappears.

	shared_ptr<MyObject> ptr1 (new MyObject);
	shared_ptr<MyObject> ptr2;

	ptr2 = ptr1;	// both ptr1 and ptr2 are valid

So, in a real application, ptr1 might exist in one class, perhaps a list,
and ptr2 might exist in some other class.  It doesn't matter which pointer
goes out of scope first.  The last one to go out of scope will free the
object.



> also looking into my schedule for the future months it will take me some longer time for doing this.

That's ok.  At least someone is working on it! :-)

- Chris

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

[Emanoil K. <del...@ya...>]

Hi,

thanks for encouragement. There are still few things that I don't understand and the other problem is that there is not enough time to read or work on it.

Let me share what I'm trying to do and you or some one on the list can advise.

I decided to go for following create syncml-http-server and syncml-http-client (in my design it's called synthml for synthesis). My idea is that I can use them communicate with each other before actually implementing an obex client for accessing the phone. Besides the modern phones provide http access, so in theory it should be possible to hook them to the server or client in opensync. And here comes the question: what does a syncml phone provide - is it a server or is it a client.
The other question is what and how does the engine exactly do for the syncing: is it a piece able to speak syncml with a particular device in form of server and/or client or did I understand it wrong.

My plan (and part of it is already coded) is to provide access to the engine via UI Api to make configuration and adjustments over the plugin possible and from the DB API for the data sync.
How do you feel about it?

Something I also do not understand from programming point of view
I had a look into SyncEvo and there they use boosts shared pointers. So my question is under which circumstanses are you forced to do it - the name is somehow self explaining - but shared between what and why is something I don't understand

also looking into my schedule for the future months it will take me some longer time for doing this.

kind regards

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

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

On Sun, Feb 12, 2012 at 05:52:19PM +0100, deloptes wrote:
> Hi, again,
> FYI:
> I am pretty occupied lately, but I am still working on this, so I was
> dealing with #1 and could initialize and open session on the engine.
> Now I am working on the discover part of the opensync plugin. I'm planning
> to do http-client/server first, so this is related to the client part.
> 
>  Here is some output from my code

Looks like you're making progress... thanks for the update!

- Chris

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

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

deloptes wrote:

> 
> So modified version of the previous plan:
> 
> 1. initialize the plugin in the osync engine
> 2. start the synthesis engine (UI)
> 3. connect the phone or act as whatever SyncML client/server (DB? or UI?)
> 4. sync (get changes etc) - provide a syncml plugin (DB)
> 5. disconnect (DB? or UI?)
> 6. stop the engine (UI)
> 7. finalize the plugin in the osync engine
> 

Hi, again,
FYI:
I am pretty occupied lately, but I am still working on this, so I was
dealing with #1 and could initialize and open session on the engine.
Now I am working on the discover part of the opensync plugin. I'm planning
to do http-client/server first, so this is related to the client part.

 Here is some output from my code

EKO: --------------------------------
EKO: bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*,
OSyncPluginInfo*, OSyncError**)
EKO: >> m_canConnect:1
EKO: >> m_canDisconnect:1
EKO: >> m_canCommit:0
EKO: >> m_canGetChanges:0
EKO: >> m_canWrite:0
EKO: >> m_canCommitAll:0
EKO: >> m_canRead:0
EKO: >> m_canSyncDone:0
EKO: >> m_canBatchCommit:0
EKO: virtual void OSynthML::SynthmlHttpClient::connect()connect to Synthesis
name='synthml-sync' err=0
modu='synthml-sync' err=404
modu='synthml-sync.so' err=0
func err=0 'SySync_ConnectEngine' 00007F813C68F6C0
call err=0
EKO: (SyncMLCfgPath) bool
OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**)...../syncml-new/src/synthesis-client-conf.xml
EKO: (InitEngineFile) bool
OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OK
EKO: (OpenKeyByPath:profiles) bool
OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OK
EKO: (OpenSession) bool
OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OK
EKO: (CloseSession) bool
OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OK
EKO: bool OSynthML::SynthmlHttpClient::initialize(OSyncPlugin*,
OSyncPluginInfo*, OSyncError**) DONE
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OK
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) OSyncObjTypeSink#contact
EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncObjTypeSink*, OSyncError**) initializing: contact
EKO: virtual sysync::CVersion OSynthML_Adapter_Module::Version()
 EKO mVersion: 17301505
EKO: virtual sysync::TSyError OSynthML_Adapter_Module::Capabilities(char*&)
 EKO cCaps: PLATFORM:Linux
DLL:true
MANUFACTURER:OpenSync.org
DESCRIPTION:OSynthML_AdapterOpenSync Plugin
MINVERSION:V1.5.1.0
ADMIN_Info:yes
ITEM_AS_KEY:yes
 EKO mPlugParams: test
EKO: virtual sysync::sInt32 OSynthML_Adapter_Session::PasswordMode()
 EKO pw mode: 2
EKO: >> m_canConnect:0
EKO: >> m_canDisconnect:0
EKO: >> m_canCommit:1
EKO: >> m_canGetChanges:1
EKO: >> m_canWrite:0
EKO: >> m_canCommitAll:0
EKO: >> m_canRead:0
EKO: >> m_canSyncDone:1
EKO: >> m_canBatchCommit:0
EKO: bool OSynthML::DataSink::initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncObjTypeSink*, OSyncError**) DONE
EKO: void* synthml_http_client_initialize(OSyncPlugin*, OSyncPluginInfo*,
OSyncError**) DONE
EKO: osync_bool synthml_discover(OSynthML::SYNTHML_PLUGIN_TYPE,
OSyncPluginInfo*, void*, OSyncError**)Plugtype OBEX, CLIENT, SERVER: 1
EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*,
OSyncPluginConfig*, std::string, OSyncError**)
EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*,
OSyncPluginConfig*, std::string, OSyncError**) DevInf or similar asking the
engine to provide information
EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*,
OSyncPluginConfig*, std::string, OSyncError**) foreach collection
EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*,
OSyncPluginConfig*, std::string, OSyncError**)> configure ressource
EKO: osync_bool OSynthML::SynthmlHttpClient::testSupport(OSyncObjTypeSink*,
OSyncPluginConfig*, std::string, OSyncError**)1 DONE
EKO: void synthml_http_client_finalize(void*) START
EKO: virtual void OSynthML::SynthmlHttpClient::disconnect() disconnect from
Synthesis
EKO: virtual void OSynthML::SynthmlHttpClient::disconnect() OK
EKO: virtual void OSynthML::SynthmlHttpClient::disconnect()0
EKO: void synthml_http_client_finalize(void*) DONE
Discovered Objtypes:
        contact
                Format: vcard21
                Format: vcard30


 Here is some log from the initialization.

more /home/yoki/kde-testdir/osynctrace/sysynclib_uni_linux*
*** Start of log
==== Client Session started with SyncML (Server+Client) Engine Version
3.4.0.27
---- Hardcoded Product name: SySync SyncML Library OpenSource Linux
---- Configured Model/Manufacturer: SySync SyncML Library OpenSource Linux /
Synthesis AG
---- Running on Linux, URI/deviceID='linux:lisa.s-und-s.home'
---- Platform Hardware Name/Version = 'Linux PC', Firmware/OS Version
= 'unknown'
---- Configured Hardware Version = 'Linux PC', Firmware Version = 'unknown'
---- System local time  : 2012-02-12 17:39:19.358  (time zone 'CET/CEST',
offset 1:00 hours east of UTC)
---- System time in UTC : 2012-02-12 16:39:19.358
==== Config
file='/home/yoki/opensync/svn-source/libopensync-plugin-akonadi/syncml-new/src/synthesis-client-conf.xml',
Last Change=2012-02-12 16:13:01.000
==== Config ID string='OpenSync.org SyncML Client Engine >=3.4 config'
##### DBApi (LNK): Session_CreateContext: desc='Text database module. Writes
data directly to TDB_*.txt file', vers=V1.8.0.0
##### TextDB (LNK): Session_CreateContext: 18291952 '212195867959357'
[2012-02-12 17:39:19.358] SessionAbort - Aborting Session, Status=20017,
ProblemSource=LOCAL
  WARNING: Aborting Session with Reason Status 20017 (LOCAL problem) ***
  --------------- Ignoring all commands in this message (after 0 sec.
request processing, 0 sec. total) with Status 20017 (0=none) from here on
[2012-02-12 17:39:19.358] End of 'SessionAbort'
##### TextDB (LNK): Session_Logout: 18291952
##### TextDB (LNK): Session_DeleteContext: 18291952
*** End of log

Re: [Opensync-devel] EBook / ECal new API

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

On Tue, Feb 07, 2012 at 10:42:19PM +0100, Nicolas wrote:
> If you address your binary meta packages to debian mainteners, Evolution
> is provided into the 3.2.2 release from debian testing.
> 
> So the evolution2 plugin can't be built on debian testing & unstable.
> And I think it's true for the most linux distributions.

That's a good point... maybe I need some better way to select build options.
Still, the distros that are actually released, and in use by end users,
are of more value to me than the development versions, since I'm trying
to make it easy for such users to grab the source, compile, and test.

Maybe I'm expecting too much of end users, though. :-)  The binary
releases via apt-get and yum and zypper should fix that.

Will have to ponder the build options.


> Nevertheless, evolution3 could be used for opensync 0.22 and opensync
> 0.4x on these debian release. Even if I think that it hasn't a lot of
> sense to use 0.22 on unstable release :)

evolution3 would need to be ported to 0.22, no?  That seems like moving
in the wrong direction to me. :-)

- Chris

Re: [Opensync-devel] EBook / ECal new API

[Nicolas <pr...@fr...>]

Le lundi 06 février 2012 à 22:12 -0500, Chris Frey a écrit :
> 
> [...]
>
> > In attachment, you can find a patch for your binary module to add new
> > target and build evolution3 plugin package for debian.
> 
> Thanks!  I had to make some changes to your patch (see the git commit
> comments), but otherwise, I've applied it.

If you address your binary meta packages to debian mainteners, Evolution
is provided into the 3.2.2 release from debian testing.

So the evolution2 plugin can't be built on debian testing & unstable.
And I think it's true for the most linux distributions.

Nevertheless, evolution3 could be used for opensync 0.22 and opensync
0.4x on these debian release. Even if I think that it hasn't a lot of
sense to use 0.22 on unstable release :)

Regards,

Nicolas

Re: [Opensync-devel] EBook / ECal new API

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

On Sun, Feb 05, 2012 at 07:30:12PM +0100, Nicolas wrote:
> Hi Chris,
> 
> I have updated the opensync-evolution3 plugin :
> http://repo.or.cz/w/opensync/evolution3.git

Nice!  Thanks.  I've updated the submodule in binary-meta.


> I'm not very satisfied by the hash array building (I'd like use the
> get_lastdate_modified field, but from icomponent object, I don't know
> how to catch the ecomponent object)
> 
> The plugin works well in the classic usage. But I think that there is an
> issue with recurrent event entries.
> 
> TODO label is insert into the code (evolution3_ecal.c)

I haven't had a chance to look too closely at this yet.  I hope
others have some spare time. :-)


> In attachment, you can find a patch for your binary module to add new
> target and build evolution3 plugin package for debian.

Thanks!  I had to make some changes to your patch (see the git commit
comments), but otherwise, I've applied it.

- Chris

Re: [Opensync-devel] EBook / ECal new API

[Nicolas <pr...@fr...>]

Le lundi 12 décembre 2011 à 18:39 -0500, Chris Frey a écrit :
> On Mon, Dec 12, 2011 at 11:47:10PM +0100, Nicolas wrote:
> > Hi, Chris
> > 
> > I have progressed about the evolution deprecated code.
> > 
> > I think that I can finish it for christmas :)
> 
> Excellent news!  Thanks!

Hi Chris,

I have updated the opensync-evolution3 plugin :
http://repo.or.cz/w/opensync/evolution3.git

I'm not very satisfied by the hash array building (I'd like use the
get_lastdate_modified field, but from icomponent object, I don't know
how to catch the ecomponent object)

The plugin works well in the classic usage. But I think that there is an
issue with recurrent event entries.

TODO label is insert into the code (evolution3_ecal.c)

Nevertheless for a first drop, it's quiet good and usable.

In attachment, you can find a patch for your binary module to add new
target and build evolution3 plugin package for debian.

Regards,

Nicolas

Re: [Opensync-devel] Q: osync strings glib vs libstd

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

On Sat, Dec 10, 2011 at 03:01:35AM +0100, deloptes wrote:
> Chris Frey wrote:
> 
> >>     int newDataSize = item.payloadData().size();
> >>     char newData[newDataSize];
> >>     memcpy(newData, item.payloadData().data(), newDataSize);
> >>     OSyncData *odata = osync_data_new ( newData, newDataSize, format,
> >> &oerror );
> > 
> > This is actually a memory bug.  osync_data_new() takes the pointer you
> > give
> > it, and does no copying.  You are passing a stack based pointer which
> > will disappear at the end of scope.
> > 
> > It would be better to malloc newData.
> > 
> 
> yes, ok - I understand ... but now comes the question what are we doing with
> the repositories. If I update it ... where?

Sorry for the delay!  Been sick lately.

Feel free to send me patches and I can push them to the git repo, or
you can do a git fork the akonadi-sync plugin here:

	http://repo.or.cz/w/opensync/evolution3.git

which will give you a repo of your own.  You can then work on your own branch,
and then just tell me when to pull when you're ready.

- Chris

Re: [Opensync-devel] EBook / ECal new API

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

On Mon, Dec 12, 2011 at 11:47:10PM +0100, Nicolas wrote:
> Hi, Chris
> 
> I have progressed about the evolution deprecated code.
> 
> I think that I can finish it for christmas :)

Excellent news!  Thanks!

- Chris