<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.misc.opensync.devel">
    <title>gmane.comp.misc.opensync.devel</title>
    <link>http://blog.gmane.org/gmane.comp.misc.opensync.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885">
    <title>[codehelp&lt; at &gt;debian.org: Status of opensync in Debian - mass removal very likely]</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885</link>
    <description>&lt;pre&gt;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 &amp;lt;codehelp&amp;lt; at &amp;gt;debian.org&amp;gt; -----

Date: Sat, 3 Mar 2012 23:15:16 +0000
From: Neil Williams &amp;lt;codehelp&amp;lt; at &amp;gt;debian.org&amp;gt;
To: debian-devel&amp;lt; at &amp;gt;lists.debian.org
Cc: Robert Collins &amp;lt;robertc&amp;lt; at &amp;gt;robertcollins.net&amp;gt;, Michael Banck &amp;lt;mbanck&amp;lt; at &amp;gt;debian.org&amp;gt;, Matthias Jahn &amp;lt;jahn.matthias&amp;lt; at &amp;gt;freenet.de&amp;gt;, Jonny Lamb &amp;lt;jonny&amp;lt; at &amp;gt;debian.org&amp;gt;
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-gnokii1462 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-gpe1462 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-irmc976 days old (needed 10 days)libopensync0RC
libopensync-plugin-kdepim1025 days old (needed 10 days)libopensync0RC
libopensync-plugin-moto1207 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-opie1190 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-palm1461 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-python1347 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-sunbird1456 days old (needed 10 days)libopensync0RC x 2
osynctool765 days old (needed 10 days)RC
opensync663 days old (needed 10 days)RC x 3
libopensync-plugin-xmlformat754 days old (needed 10 days)opensync
libopensync-plugin-vformat768 days old (needed 10 days)opensync
libopensync-plugin-syncml755 days old (needed 10 days)opensync
libopensync-plugin-file755 days old (needed 10 days)opensync
libopensync-plugin-evolution2755 days old (needed 10 days)libcamel-1.2-23 et al
multisync0.90825 days old (needed 10 days)libopensync0RC x 2
synce-sync-enginedepends opensync, libopensync-plugin-python
libopensync-plugin-google-calendarlibopensync0 (experimental) RC x 3
synce-kpmdepends 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.

&lt;/pre&gt;</description>
    <dc:creator>Harald Jenny</dc:creator>
    <dc:date>2012-03-05T08:11:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880">
    <title>syncML devel equipment</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880</link>
    <description>&lt;pre&gt;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


------------------------------------------------------------------------------
Virtualization &amp;amp; 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/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2012-02-23T22:41:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853">
    <title>Q: osync strings glib vs libstd</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853</link>
    <description>&lt;pre&gt;Hi,
I have a theoretical question rather general as I have been doing a lot of
programming for text processing purposes and always had troubles with
encodings, so I was wondering what should one use when coding for opensync.
There are several advantages when using glib, but also several disadvantages
compared to libstd.

Can you please advise? Or where can I post this question if this is not the
right place for that discussion?

regards


------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-12-08T11:28:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831">
    <title>EBook / ECal new API</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831</link>
    <description>&lt;pre&gt;Hi,

In helping friends with the last Fedora release, I have noticed that the
ebook / ecal API was modified.

http://www.opensubscriber.com/message/evolution-hackers&amp;lt; at &amp;gt;gnome.org/15214566.html

http://developer.gnome.org/libebook/stable/EBook.html#e-book-free-change-list

We have to worked to adapt opensync evolution2 plugin for the new
Evolution API... Maybe opensync evolution3 plugin :)

Regards,

Nicolas



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, 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-novd2d
&lt;/pre&gt;</description>
    <dc:creator>Nicolas</dc:creator>
    <dc:date>2011-11-20T14:54:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829">
    <title>May I modify libwbxml-0.11.0 source code to make it compile, and use it in commercial software</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829</link>
    <description>&lt;pre&gt;Hi,

My question is related to LGPL licensing of libwbxml-0.11.0.

I got the source of libwbxml-0.11.0 but found it won't compile on Windows
using Visual C++ 6 (missing wbxml_config.h). I'd like to modify the source
and make it compile, then use it in the commercial software in a
dynamic-link manner(DLL).  This proprietary is an email client with
ActiveSync capability.

My concern is that as it's bounded by LGPL, may I keep the commercial
software code proprietary, while using a modified libwbxml-0.11.0 ?

My modification is just to make it compile, but not to modify the internal
of libwbxml.

Is this a case prohibited by LGPL, a close source commercial software dynamic
links to a modified version of LGPL software?

Thanks!

*Weiming*
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Zeng,Weiming</dc:creator>
    <dc:date>2011-11-14T07:27:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828">
    <title>Cmake Modules repo</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828</link>
    <description>&lt;pre&gt;http://zi.fi/cmake/Modules/


------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-11-10T11:58:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810">
    <title>Discussion: syncml plugin with synthesis</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810</link>
    <description>&lt;pre&gt;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.
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


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning&amp;lt; at &amp;gt;Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-10-23T10:40:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809">
    <title>file renames to resolve version conflicts</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809</link>
    <description>&lt;pre&gt;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 &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
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 &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
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 &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
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


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning&amp;lt; at &amp;gt;Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-10-20T04:09:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806">
    <title>fixed: evolution syncing problem with get_changeson Debian Squeeze</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806</link>
    <description>&lt;pre&gt;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


------------------------------------------------------------------------------
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-d2dcopy2
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-09-23T05:12:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802">
    <title>make test doubts</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802</link>
    <description>&lt;pre&gt;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.
            luizluca&amp;lt; at &amp;gt;gmail.com
------------------------------------------------------------------------------
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
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-09-02T15:52:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793">
    <title>[BUG] Fix printf for size_t on google-calendar</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793</link>
    <description>&lt;pre&gt;Hello,

This is a simple fix in order to have google-calendar compile on x86_64.

git&amp;lt; at &amp;gt;github.com:luizluca/google-calendar.git fixprintf

Regards,
---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-08-27T02:10:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792">
    <title>Binary meta fails at "make fetch"</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792</link>
    <description>&lt;pre&gt;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. :-)

I saw that binary-meta now has more interesting make options. 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

Again just for sure:

# make fetch
git submodule init
git submodule update
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

So I discovered that something before created sources/opensync/build.
I guess it created it before it should.
I just rmdir it and it worked.

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-08-26T15:02:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762">
    <title>libopensync with AMQP</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762</link>
    <description>&lt;pre&gt;Hello,

I have a question and i don’t know if it makes sense. Please do
correct me, if i am wrong.

Can you use libopensync along with zeromq/rabbitmq (rabbitmq is a AMQP
protocol implementation with zeromq being AFAIK loosely based on AMQP)
to syncornize data with another server that uses liopensync to
synchronize random data ??

Or is it better to use libsyncml to sync arbitary binary data some
media like ethernet.


Thanks,
Harish

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
&lt;/pre&gt;</description>
    <dc:creator>harish badrinath</dc:creator>
    <dc:date>2011-07-28T13:00:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741">
    <title>Breakthrough: all opensync library tests pass</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741</link>
    <description>&lt;pre&gt;Hi folks,

I did a test run on opensync tonight, using my git repo, and for the
first time to my memory, in all my experience with opensync, all
the tests pass for me.

Please let me know if you have different results.

It's been a long week of valgrind work, and repairing and debugging tests,
but I'm pretty happy that I'm at this point already.

This is not to say that all the tests are themselves accurate.  I haven't
gone through them and analyzed the logic.  I just wanted the existing
code to run and pass.

Hopefully from now on, we can keep opensync in this good shape.  And
improve it.  There are more corner cases, I'm sure, that valgrind can
catch.

The repo is here, with 65 commits over the past week and a half:

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


So far, all my tests have been with file-sync and mock-sync.  Next on
the agenda is to slowly work through the binary-meta tree, and test
those plugins with valgrind as well.  Hopefully opensync will become
bulletproof soon. :-)

Enjoy,
- Chris



git shortlog:

Chris Frey (62):
      Minor code cleanup: use local variable instead of pointer again
      Added clarifying comments
      Merge remote branch 'luizluca/fix-memoryleak-serializer'
      Added explanatory comments for bit count totals in OSyncObjEngine
      Replaced bit twiddling code with simpler equivalents
      Fixed access of freed memory in osync_obj_engine_command()
      Fixed caps_converters and mergers memory leaks when freeing FormatEnv lists
      Fixed memory leak in osync_demarshal_objformatsink()'s error handling logic
      Fixed hairy OSyncList-based memory leak in osync_engine_initialize()
      Added note on debugging memory issues with valgrind
      doc: Added bird's eye view of the capabilities structure hierarchy
      Minor pointer initialization fix, and comment formatting
      Removed unused osync_capability_free() prototype
      Minor reorg of opensync_capability_private.h, and typo fix
      Comment typo
      No need to call a function to access internal struct value
      Fixed some of osync_capabilities_objtype_unref()'s cleanup logic
      Commented out unused prototype
      Added internal OSyncCapabilityParameter new/ref/unref API
      Changed capability list add behaviour
      API: changed osync_capability_new() API
      API: documented osync_capability_new_child() and _add_child()
      Added clarification comment to osync_capability_new_child()
      Added implementation for osync_capability_unref()
      API: changed osync_capabilities_objtype_new() to behave like _new()
      Updated osync_capabilities_objtype_parse doxygen comments
      Cleaned up osync_capabilities_unref()
      API: changed capability-related _parse() and _parse_and_add() functions
      API: reorganized capabilities API to be more consistent and clear
      leak: fixed two leaks in osync_member_support_targetformat()
      memory: fixed potential invalid memory access in error case of osync_demarshal_pluginconfig()
      leak: fixed invalid use of osync_free(), should have used osync_plugin_config_unref()
      leak: fixed leak in osync_message_new() in the error case
      leak: fixed ref logic error in _osync_queue_generate_error()
      Added proper child support to OSyncError
      Fixed trace logging in new capabilities functions
      Fixed typo in osync_engine_get_cmdstr()
      Fixed logic of unidirectional write optimization in osync_obj_engine_command()
      leak: fixed osync_list_free() bug in _inject_changelog_entries
      leak: fixed missing calls to osync_db_free_list()
      doc: added What is the difference between _private.h and _internal.h headers?
      Changed engine's busy flag to volatile
      leak: fixed leaks in the xmlformat and xmlfield API
      doc: clarified freeing responsibility for osync_format_env_find_path_with_detectors()
      leak: fixed extremely tricky set of leaks in osync_format_env_find_path_fn()
      leak: fixed potential leaks in the error path of osync_demarshal_change()
      leak: fixed leaked change object in _osync_client_handle_read_change()
      leak: fixed leaked change and data objects in _inject_changelog_entries()
      leak: fixed leak in osync_archive_get_mixed_objengines()
      leak: fixed leak and logic error in _osync_client_proxy_fin_handler()
      leak: fixed leak in osync_queue_disconnect(), and tightened up locking
      API: osync_xmlformat_assemble() now returns osync_strdup() buffer
      doc: clarify how osync_xmlformat_assemble() buffer should be freed
      Fixed path name bug in test data
      test: added workaround for the empty directory problem with git
      Fixed comment typo
      test: beefed up error checking for system() calls
      Fixed unref on pointer before checking if valid (oops)
      Added basic error logging in osync_member_support_targetformat()
      leak: fixed ref leak in mock_initialize
      Added OSYNC_ERROR_MAX error type, for error type range checking
      Added error type range check in osync_demarshal_error(), and log if out of range

Luiz Angelo Daros de Luca (3):
      - formatting stuff
      - Fix memoryleak. objformat is duplicated and must be freed.
      - Fix memory leak when some error occurs in osync_demarshal_objtype_sink     - Fix memory leak in osync_demarshal_objtype_sinks as it never unrefs sinks


------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-23T06:15:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740">
    <title>trying to understand the duplicate callback</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740</link>
    <description>&lt;pre&gt;Hi Daniel,

While fixing leaks, I ran across the following function in the xmlformat
plugin:

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

I've removed all the dead code (which contained a leak), but while it looks
correct, and the sync continues to work without that dead code, it looks
kinda odd.

I just wanted to confirm:  is is true that the duplicate callback is only
for duplicating the UID?  Why is there an output/outsize mechanism involved
in that case?

How else can the duplicate callback be used?

Thanks!
- Chris


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks &amp;amp; Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-22T22:46:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739">
    <title>API behaviour change: osync_xmlformat_assemble(and heads-up to ldap plugin author)</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739</link>
    <description>&lt;pre&gt;Hi,

I've made a memory allocation change to the function
osync_xmlformat_assemble() which can be viewed here:

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

Much of the code that I've seen, both inside the library and in the
plugins, assumes that the resulting buffer from a call to
osync_xmlformat_assemble() can be freed with osync_free() or g_free().

But the call passes back memory that expects to be freed with libxml2's
xmlFree().

If you're on a system that uses malloc everywhere, this might not matter,
but glib/gtk uses its own g_slice memory management, and this might
cause problems.

With the above commit, osync_xmlformat_assemble() gives back an osync_strdup()
buffer, so freeing works as expected.


scriptor:
I've noticed in your ldap plugin code, you free this memory with
calls to xmlFree(), which is very correct, but plugins shouldn't
have to know this.  This change will affect you.

Also, I notice that you make much use of valgrind in your testing.
I've been fixing a lot of memory leaks in opensync in the above
git repo.  If you'd like to give it a try and report back if you
see any improvement, that would be great.

- Chris


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks &amp;amp; Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-22T22:40:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737">
    <title>API change: capabilities API reworked</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737</link>
    <description>&lt;pre&gt;Hi,

I've made a number of changes and fixed some memory leaks in the capabilities
API.  You can see the last change here:

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

I've updated the evolution2, vformat, and xmlformat plugins as well, with
the small API change required, since I'm tracking them.

For plugin authors, the change is pretty simple:

Change: osync_capability_new()

To: osync_capabilities_add_new_capability()

and

Change: osync_capabilities_objtype_new()

To: osync_capabilieis_add_new_objtype()

The reason for this change was because the capabilities API behaved
differently than the rest of opensync.  The _new() calls would add
the new object to an internal list, and return an unref'd pointer.
This is inconsistent with what the user will expect from every other
_new() call in the library.

Also, due to this oddity, some of the internal implementations were
very difficult to get right.  While building the capabiities hierarchy,
there could be errors after an object was created, but before it could
be returned successfully.

I have changed the internal API so that all calls to _new(), _ref(), and
_unref(), in the capabilities API behave as expected.  I have also
hidden a number of calls, in favour of promoting just the top level
OSyncCapabilities objects.  This is all that the user should need to
worry about, when it comes to memory management, and the normal
_new(), _ref(), and _unref() calls are available for it only.


API Changes:
============

Removed (moved to internal)

osync_capabilities_objtype_new
osync_capabilities_objtype_ref
osync_capabilities_objtype_unref
osync_capability_new
osync_capability_ref
osync_capability_unref

Added

osync_capabilities_add_new_objtype
osync_capabilities_add_new_capability


Background:
===========

For those who don't know what the "capabilities hierarchy" is, here's the
docs that I added to opensync_capabilities_private.h.

/**
 * &amp;lt; at &amp;gt;brief Represent a Capabilities object
 *
 * This is the top level Capabilities object, which contains a list of
 * lists of capability objects for each objtype.
 *
 * For example, if your device has a set of capabilities, you could call the
 * set "foodevice-caps".  This would be the Capabilities format name.
 * This format name could contain different capability lists for each
 * objtype supported, for example "contact" or "event" or both.
 *
 * The names of the capabilities do not have to match anything else, but
 * if they do not match something opensync knows about, it will need a
 * caps-converter (capabilities converter) to translate your list of
 * capability objects for, say, "contact" into something it knows, say,
 * "xmlformat-contact".
 *
 *   foodevice-caps
 *      contact
 *         name
 *         address1
 *         phonenumber
 *      event
 *         date
 *         location
 *
 * I don't know if multiple objtypes are ever useful, but they are possible,
 * given the 3 structures: OSyncCapabilities, OSyncCapabilitiesObjType,
 * and finally OSyncCapability.
 *
 * Note that OSyncCapability is a hierarchical list, having its own children.
 * It also has a list of OSyncCapabilityParameter objects.
 *
 */


The Capabilities API could use some feedback and thought.  Currently there
is no way to properly manage the OSyncCapabilityParameters programmatically.

Enjoy,
- Chris


------------------------------------------------------------------------------
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-18T21:34:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735">
    <title>OMA DM</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735</link>
    <description>&lt;pre&gt;There was mention on the roadmap of the wiki that there was some effort and
interest for device management - has there been any work, and are there any
working reference code for showing the capability.
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>James Hanley</dc:creator>
    <dc:date>2011-07-18T17:06:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722">
    <title>[BUG]s file-sync misses dir references and adouble random number</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722</link>
    <description>&lt;pre&gt;Hello,

I don't know it the bug tracker at the site is still valid so I'm writing
about the bug I found to the list.
Correct me if I'm wrong.

File-sync/src/file-sync.c at osync_filesync_initialize:

"OSyncFileEnv *env" is initialized with no problem. It contains only a list
of "GList *directories". However, this list is never filled.
At the end of each sink loop, it should add dir to env-&amp;gt;directories. The
result is that free_env never frees dirs as
it has no reference for them.


File-sync/src/file.c at conv_plain_to_file:

file-&amp;gt;path = osync_rand_str(g_random_int_range(1, 100), error);

the g_random_int_range(1, 100) returns a random number between 1 and 100.
However, the osync_rand_str already does this. Its first argument is "int
maxlength", which is used in:

length = g_random_int_range(1, maxlength + 1);

Seems to be a double random :-). It should be enough to call:

file-&amp;gt;path = osync_rand_str(100, error);


Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-07-18T00:06:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720">
    <title>FormatEnv setup and teardown logic</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720</link>
    <description>&lt;pre&gt;Hi Daniel,

I've been working on opensync memory leaks, and found an interesting one
in the FormatEnv unref code:

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

For caps_converters, it looks like it is possible to have init/final logic
in the format plugins, since these functions exist:

osync_caps_converter_set_initialize_func()
osync_caps_converter_set_finalize_func()
osync_caps_converter_initialize()
osync_caps_converter_finalize()

The FormatEnv code does not seem to make use of any of these calls,
so my memory leak patch above does not call finalize().

The merger code on the other hand, only has the following functions
in opensync_merger.c:

osync_merger_set_initialize_func()
osync_merger_set_finalize_func()

There are no functions available to call these callbacks.

Could you give me a bird's eye overview of how the caps_converters and
mergers are supposed to work from an API point of view?  Should I be
implementing init/final sequences in FormatEnv for both?  Or is there
a reason FormatEnv doesn't bother with these?

Thanks!
- Chris


------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-16T01:41:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4717">
    <title>[PATCH] Small memoryleak fixed in serializer.c</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4717</link>
    <description>&lt;pre&gt;Hello,

While playing with valgrind, I found some small memory leaks.
I fixed what it found in serializer.c and another one that it did not
found. My code is in:

git://github.com/luizluca/opensync-luizluca.git   fix-memoryleak-serializer

The first do some formatting cleanup (kdeveloper help) and the other
ones are the real fixes.

BTW, there is more memory leaks in code. I just didn't stopped to fix them.

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-07-15T05:15:21</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.misc.opensync.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.misc.opensync.devel</link>
  </textinput>
</rdf:RDF>

