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

Re: [Opensync-devel] [Fwd: patches 3]

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

On Thu, Aug 15, 2013 at 10:33:39AM +0100, Mark Ellis wrote:
> Good call, tested against synce, not the sample. As it turns out, only
> relevant call is a commented out example, here you go.

Thanks, committed.

I've updated the binary-meta repo to point to all the newly changed
repos as well: opensync, evolution 2 and 3, python-module.

- Chris

Re: [Opensync-devel] patches 4

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

On Wed, Aug 07, 2013 at 02:04:01PM +0100, Mark Ellis wrote:
> pyplug_optional_finalize.diff
> Stops the python plugin dying if there is no optional finalize function
> 
> evoplug-glib-deprecated.diff
> g_type_init() was deprecated in glib 2.36, so made it conditional.
> 
> evoplug-mem-management.diff
> Started off as a memory management cleanup, hence the name, turned into
> a general clean up and bug hunt, corrected some error reporting and
> trace logs, even fixed some code formatting. Would've been nice to break
> up the patch, but it was all a bit interwoven.
> 
> evoplug-read-func.diff
> Add _read_ functions to the sinks, no particular reason, they just
> weren't there.

Thanks again!  That was some delicate memory management work in there. :-)

All committed.

- Chris

Re: [Opensync-devel] [Fwd: patches 3]

[Mark E. <ma...@mp...>]

On Wed, 2013-08-14 at 03:43 +0200, Chris Frey wrote:
> On Wed, Aug 07, 2013 at 01:51:40PM +0100, Mark Ellis wrote:
> > > 4-python.diff
> > > loads of plugin related extensions to the python bindings
> 
> Committed, thanks!
> 
> I notice there were a few API changes that would be visible to
> python plugins.  Did you test against the sample in python-plugin?
> 
> - Chris
> 

Good call, tested against synce, not the sample. As it turns out, only
relevant call is a commented out example, here you go.

Mark

Re: [Opensync-devel] [Fwd: patches 3]

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

On Wed, Aug 07, 2013 at 01:51:40PM +0100, Mark Ellis wrote:
> > 4-python.diff
> > loads of plugin related extensions to the python bindings

Committed, thanks!

I notice there were a few API changes that would be visible to
python plugins.  Did you test against the sample in python-plugin?

- Chris

Re: [Opensync-devel] Moving to Git

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

On Tue, Aug 13, 2013 at 01:42:22PM -0400, Chris Frey wrote:
> I don't think there were many branches in opensync, as I recall.
> And any branches that might have been there were of limited use to me,
> since I wouldn't have known the reasoning behind them.

For opensync in particular, I created two main git branches: one for
the 0.2x development, and one for 0.3x/master.

- Chris

Re: [Opensync-devel] Moving to Git

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

On Tue, Aug 13, 2013 at 04:32:42PM +0200, Michael Bell wrote:
> 1. Branches do not work for me with svn2git. So the migration failed on 
> branches/libwbxml-0.10.x.

I don't think there were many branches in opensync, as I recall.
And any branches that might have been there were of limited use to me,
since I wouldn't have known the reasoning behind them.


> 2. The external links are missing (cmake modules and test). I don't know if 
> git supports such a concept.

I split the cmake modules into their own git repo, and when building
opensync and plugins, pointed to that repo with:

	-DCMAKE_MODULE_PATH=".../sources/cmake-modules"

Git does have the concept of submodules, but I didn't think it was worth
it for something like cmake modules.  Plus, it reinforces the idea that
the cmake-modules repo is something shared.

I used git submodules for my binary-meta git repo, which pulls in all
the other git repos, and provides a makefile mechanism to build them all,
either at a source level, or a DEB/RPM level.

- Chris

Re: [Opensync-devel] Moving to Git

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

Am Dienstag, 13. August 2013, 16:32:42 schrieb Michael Bell:
> 
> I failed with svn2git for the migration of libwbxml.
> 
> 1. Branches do not work for me with svn2git. So the migration failed on
> branches/libwbxml-0.10.x.

The error message is:

Running command: git branch --track "libwbxml-0.10.x" 
"remotes/svn/libwbxml-0.10.x"

fatal: Cannot setup tracking information; starting point 
'remotes/svn/libwbxml-0.10.x' is not a branch.

command failed:
2>&1 git branch --track "libwbxml-0.10.x" "remotes/svn/libwbxml-0.10.x"

Best regards 

Michael

Re: [Opensync-devel] Moving to Git

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

Hi,

I failed with svn2git for the migration of libwbxml.

1. Branches do not work for me with svn2git. So the migration failed on 
branches/libwbxml-0.10.x.

2. The external links are missing (cmake modules and test). I don't know if 
git supports such a concept.

Perhaps I should try the automatic tool from github ...

Best regards

Michael

Re: [Opensync-devel] patches 2

[Mark E. <ma...@mp...>]

On Mon, 2013-08-12 at 04:41 +0200, Chris Frey wrote:

> > 2-glibdep-get-time.diff
> > g_source_get_current_time() was deprecated in glib 2.28, which seems old
> > enough to me to not worry about, so I've bumped the required version to
> > 2.28 and rewritten with g_source_get_time()
> 
> I didn't apply this patch, but wrote a slightly different one, wrapping
> the API change in a static function.  The reason I did this was because
> glib 2.24 is still used in Ubuntu's oldest LTS release, which is still
> out there.  Plus my old Debian system uses 2.24 :-)  I also bumped
> the min in CMakeLists.txt to 2.24 instead of your 2.28.
> 

That looks fine. I was a bit torn about which way to go myself. I tend
to consider if something is too old to be in debian stable it's quite
old ! Nearly wrote it for backwards compatibility for that ubuntu LTS,
then thought who'd install it on an old LTS server release :) But that's
cool, I like keeping backwards compat.

Mark

Re: [Opensync-devel] patches 2

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

On Wed, Aug 07, 2013 at 12:44:23PM +0100, Mark Ellis wrote:
> 1-glibdep-threads.diff
> Glib changed some threading functions in 2.32 and deprecated the old
> versions, I've written this to build with both styles depending on the
> version, since 2.32 didn't feel that old.

Committed.  Thanks!


> 3-glibdep-basename.diff
> g_basename() was deprecated ages ago.

Committed, thanks!


> 2-glibdep-get-time.diff
> g_source_get_current_time() was deprecated in glib 2.28, which seems old
> enough to me to not worry about, so I've bumped the required version to
> 2.28 and rewritten with g_source_get_time()

I didn't apply this patch, but wrote a slightly different one, wrapping
the API change in a static function.  The reason I did this was because
glib 2.24 is still used in Ubuntu's oldest LTS release, which is still
out there.  Plus my old Debian system uses 2.24 :-)  I also bumped
the min in CMakeLists.txt to 2.24 instead of your 2.28.

A few more patches to go, yet.

Thanks again!
- Chris

Re: [Opensync-devel] [Fwd: patches 1]

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

On Fri, Aug 09, 2013 at 09:30:27AM +0100, Mark Ellis wrote:
> The main one from my point of view though, just substituting in the new
> style was quite easy and quick to do, and also to test. Wrapping
> everything would take longer, with more chance of screwing something up
> in the short term. My main aim was to get rid of the warnings in the
> limited time I have for this these days.

I think it would be fairly straightforward to do the wrapper, and cleaner,
but I can understand about the ease of implementation, especially with
the following patches depending on it. :-)

It's chafing me badly, but I suppose if I want it done, I may have to
do it myself. :-)

Busy weekend here, so patches are getting committed slowly.  Sorry.

- Chris

Re: [Opensync-devel] Moving to Git

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

On Sat, Aug 10, 2013 at 10:52:03AM +0300, Juha Tuomala wrote:
> >I would push the git repos that I've already converted from SVN.
> 
> Has that been converted with history or just a snapshot from one 
> point of time? If it has been converted, did it keep the users etc 
> too?

All the repos that I have converted were done with history.  I did them
as carefully as possible, from the official SVN repos, and I've been
using them as the main repos for a while now, so they have changes that
SVN does not.  I've used these as the official repos for a while now.

But I haven't converted them all.  I went for the ones that I needed,
and the ones I could compile on my system.
I'm sure I could use the same method to convert the rest.

My repos can be found as forks under the opensync repo found
on repo.or.cz:

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

The forks listed at the bottom are independent git repos from the main
opensync.git repo... I juse used the fork mechanism as a nice way of
grouping them all under opensync.  These repos I've converted with full
history.  These are the repos that I would push, once git was available
on opensync.org.  Alternatively, you're welcome to pull from there to
get opensync.org setup initially.

You'll notice that the commit names in the SVN history are what SVN uses,
instead of the style of git... i.e. you'll see "dgollub" instead of
"Daniel Gollub" with odd "email addresses."  I personally like this
distinction, as it is easy to see what history came from SVN vs git,
but not everyone is a fan.  It was also a bit easier. :-)

As I've already done the work, I'm not keen on re-doing it, but if
someone else wants to improve things, please do.


> Another thing is that we need to make a user database for other 
> committers too. That's a bit tricker already, but I've something in 
> mind for that too.

I suspect that's a special server issue.  I'm imagining that we would
use specific accounts per repo, with ssh keys used for push access,
so we can grant push access on a per-repo basis?

What do you have in mind?

- Chris

Re: [Opensync-devel] Moving to Git

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

On Fri, 9 Aug 2013, Chris Frey wrote:
> I would just need a way to create new repos, and then a way to 
> push to them.

That's easy.

> I would push the git repos that I've already converted from SVN.

Has that been converted with history or just a snapshot from one 
point of time? If it has been converted, did it keep the users etc 
too?

Lot of projects have gone through this and I think we could try to 
keep the history as intact as possible if it's doable.

Another thing is that we need to make a user database for other 
committers too. That's a bit tricker already, but I've something in 
mind for that too.


Tuju

-- 
Säästämisen ja ahkeroinnin tilalle syntyi varsinkin 1960-luvulta lähtien oman
onnellisuuden ympärillä pyörivä, vastuuton ajattelutapa, joka korostaa oikeuksia
velvollisuuksien sijaan. - Paul Lillrank

Re: [Opensync-devel] How evo capabilities work (was Re: capabilities problem)

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

On Fri, Aug 09, 2013 at 11:17:35AM +0100, Mark Ellis wrote:
> So, back to the caps conversion in the format plugin. It registers
> caps_conv_evo3_to_xmlformat() as the converter, which essentially just
> calls caps_conv_generic() with the contact objtype name. This objtype
> seems somewhat artificial and forced, because we have no objtype
> information at this time, the converter seems it should be objtype
> neutral, it's only there because we have no caps info for other
> objtypes. And that's where it goes wrong if the contacts objtype has
> been disabled in the evo plugin.
> 
> I'm thinking that this function should instead, check to see if oldcaps
> has the objtypes we know about, in this case only contacts. If it
> exists, create a new caps objtype and populate it. If it/they don't
> exists, we haven't registered those objtypes, so just return TRUE, since
> we haven't actually had an error, we just don't have caps info for the
> other objtypes that have been registered by the plugin.

That sounds reasonable to me.  I think caps_conv_evo3_to_xmlformat()
should loop through all the objformats in *oldcaps, and convert what it
can, instead of hardcoding the "contacts" objtype.

If you have the opportunity, it would be interesting to test whether
an empty "events" objtype in **newcaps would result in null events
being used in the sync.

- Chris

Re: [Opensync-devel] Moving to Git

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

On Fri, Aug 09, 2013 at 11:54:46AM +0300, Juha Tuomala wrote:
> So, we could do it now. What do you require at server end it to 
> happen?
> 
> I hope it could help a bit in patching and development if tools were 
> more familar for today's hackers.

I would just need a way to create new repos, and then a way to push
to them.

I would push the git repos that I've already converted from SVN.

- Chris

Re: [Opensync-devel] How evo capabilities work (was Re: capabilities problem)

[Mark E. <ma...@mp...>]

On Fri, 2013-08-09 at 05:18 +0200, Chris Frey wrote:
> On Fri, Aug 02, 2013 at 02:43:46PM +0100, Mark Ellis wrote:
> > After some thinking, should evo sync even have a format ? We get vformat
> > from evo, the vformat plugin even has some extensions for evolution, and
> > I don't think the evolution format plugin will actually get used, it
> > probably just gets loaded because it exists ?
> 
> Oy, it took me a while to find this, so I'll try to document my
> understanding. :-)
> 
> I'll use evo2_sync, as that's what I have open right now.
> 
> The evo2 sync plugin starts up, and registers its evo2_discover() function.
> This discover function is then called by the library, which creates
> a capability set called "evo2-caps".  It then discovers capabilities
> for ebook and ecal.  These capabilities tell opensync what fields
> that the evo2 sync supports.
> 
> Discovering ebook capabilities is done in evo2_ebook_discover(),
> which contacts evolution and asks for the fields it supports.
> It then calls evo2_capabilities_translate_ebook(), which basically
> adds an objtype "contact" to the "evo2-caps", and adds all the
> fieldnames returned by evolution to that objtype capability list.
> 
> We now have "evo2-caps" which supports "contact" objtypes, and a
> list of names specific to evolution that represent
> what contact fields it supports.  We know this because evo2_discover()
> calls osync_plugin_info_set_capabilities(), setting this new
> "evo2-caps" as this plugin's capability set.
> 

Ok, I can see that. But we only set caps for contact, not any other
objtypes, which I'll come to later.

> But all this is useless, because while the engine knows that
> the evo2_sync plugin can handle contact objtypes, it also knows
> that it must serve the data to the plugin in vcard30 format,
> without using any fields that the plugin doesn't support.
> Unfortunately, the library engine has no idea what the
> capability names in "evo2-caps" mean, as they are evolution
> names and not related to any format that opensync understands.
> 
> But it does know what the names are for XMLFormat, and what those
> fields mean.
> 
> This is where the evo2 format plugin steps in, which provides only
> the conversion aspect of a format plugin, not the format part.
> 
> The evo2 format plugin registers a caps_converter which points
> to "evo2-caps" and "xmlformat".  This caps converter takes the
> capabilities of the plugin ("evo2-caps"), and creates a new capabilities
> set ("xmlformat", see evolution2_format.c:caps_conv_evo2_to_xmlformat()),
> with its "contact" objtype filled in with xmlformat names,
> matching the xmlformat schema.
> 
> Now the engine has all the information it needs.  It knows the sync
> plugin's objtype (contact), its format (vcard30), its capabilities
> (evo2-caps, for objtype contact), and how to put meaning to those
> capabilities (the caps converter to xmlformat).  It can now take data from
> some other plugin, convert that to xmlformat, strip out any fields
> that evolution can't handle, then convert it to vcard30, and vice versa,
> all while being completely automatic.  There are no config files for
> evolution... this data comes straight from evolution itself, and so
> if evolution changes, the plugin adapts as well.
> 
> So short answer: yes, as I see it, we do need the evo2 format plugin. :-)
> 

Ok, I'm with you on the why, in which case the how in evo sync needs
fixing.

We only set capabilities for contacts, I guess that's fair enough, since
it's registered by objtype, so I would assume (hope ?) that the engine
accepts we have no caps information for other objtypes and just passes
through everything. In an ideal world we'd provide caps for other
objtypes, but evo doesn't seem to provide it, possibly because it does
all the "normal" stuff and doesn't feel it needs to.

So, back to the caps conversion in the format plugin. It registers
caps_conv_evo3_to_xmlformat() as the converter, which essentially just
calls caps_conv_generic() with the contact objtype name. This objtype
seems somewhat artificial and forced, because we have no objtype
information at this time, the converter seems it should be objtype
neutral, it's only there because we have no caps info for other
objtypes. And that's where it goes wrong if the contacts objtype has
been disabled in the evo plugin.

I'm thinking that this function should instead, check to see if oldcaps
has the objtypes we know about, in this case only contacts. If it
exists, create a new caps objtype and populate it. If it/they don't
exists, we haven't registered those objtypes, so just return TRUE, since
we haven't actually had an error, we just don't have caps info for the
other objtypes that have been registered by the plugin.

Thoughts ?

Mark

[Opensync-devel] Moving to Git

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

Hi

So, we could do it now. What do you require at server end it to 
happen?

I hope it could help a bit in patching and development if tools were 
more familar for today's hackers.


Tuju

-- 
Säästämisen ja ahkeroinnin tilalle syntyi varsinkin 1960-luvulta lähtien oman
onnellisuuden ympärillä pyörivä, vastuuton ajattelutapa, joka korostaa oikeuksia
velvollisuuksien sijaan. - Paul Lillrank

Re: [Opensync-devel] [Fwd: patches 1]

[Mark E. <ma...@mp...>]

On Fri, 2013-08-09 at 03:24 +0200, Chris Frey wrote:
> On Wed, Aug 07, 2013, Mark Ellis wrote:
> > 1-glibdep-threads.diff
> > Glib changed some threading functions in 2.32 and deprecated the old
> > versions, I've written this to build with both styles depending on the
> > version, since 2.32 didn't feel that old.
> 
> Thanks Mark for these patches!  I'll putter through them as I have
> time.  Hopefully it won't take too long to get them into the main tree.
> 
> As I was reading through this patch, and looking at the API change,
> I started wondering, wouldn't it be better if we wrapped glib's API
> in our own?  Somehow, I like the idea of pointers which are filled,
> and freed, rather than keeping the entire sturcture around.
> Pointers are opaque, and we don't need the structure
> definition to work with them.
> 
> So with that in mind, I'm not sure why glib decided to change the
> way they did, but regardless, we don't have to follow in their footsteps,
> and we can write our own pointer-oriented API.  It might even be
> cleaner in the long run.
> 
> Compare to this patch:
> http://lists.freedesktop.org/archives/gstreamer-commits/2012-March/061105.html
> 
> What do you think?  Are there any drawbacks to writing our own?
> 

I wouldn't disagree with you on those points, most particularly why they
changed the API. I have 2 vague points to add against wrapping them in
our own API.

I don't presume to know how glib's internal threading code works, so I
can only presume there is a good reason for it, and the developers know
what they're doing :) That's an assumption of course.

The main one from my point of view though, just substituting in the new
style was quite easy and quick to do, and also to test. Wrapping
everything would take longer, with more chance of screwing something up
in the short term. My main aim was to get rid of the warnings in the
limited time I have for this these days.

Thoughts ?

Mark

[Opensync-devel] How evo capabilities work (was Re: capabilities problem)

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

On Fri, Aug 02, 2013 at 02:43:46PM +0100, Mark Ellis wrote:
> After some thinking, should evo sync even have a format ? We get vformat
> from evo, the vformat plugin even has some extensions for evolution, and
> I don't think the evolution format plugin will actually get used, it
> probably just gets loaded because it exists ?

Oy, it took me a while to find this, so I'll try to document my
understanding. :-)

I'll use evo2_sync, as that's what I have open right now.

The evo2 sync plugin starts up, and registers its evo2_discover() function.
This discover function is then called by the library, which creates
a capability set called "evo2-caps".  It then discovers capabilities
for ebook and ecal.  These capabilities tell opensync what fields
that the evo2 sync supports.

Discovering ebook capabilities is done in evo2_ebook_discover(),
which contacts evolution and asks for the fields it supports.
It then calls evo2_capabilities_translate_ebook(), which basically
adds an objtype "contact" to the "evo2-caps", and adds all the
fieldnames returned by evolution to that objtype capability list.

We now have "evo2-caps" which supports "contact" objtypes, and a
list of names specific to evolution that represent
what contact fields it supports.  We know this because evo2_discover()
calls osync_plugin_info_set_capabilities(), setting this new
"evo2-caps" as this plugin's capability set.

But all this is useless, because while the engine knows that
the evo2_sync plugin can handle contact objtypes, it also knows
that it must serve the data to the plugin in vcard30 format,
without using any fields that the plugin doesn't support.
Unfortunately, the library engine has no idea what the
capability names in "evo2-caps" mean, as they are evolution
names and not related to any format that opensync understands.

But it does know what the names are for XMLFormat, and what those
fields mean.

This is where the evo2 format plugin steps in, which provides only
the conversion aspect of a format plugin, not the format part.

The evo2 format plugin registers a caps_converter which points
to "evo2-caps" and "xmlformat".  This caps converter takes the
capabilities of the plugin ("evo2-caps"), and creates a new capabilities
set ("xmlformat", see evolution2_format.c:caps_conv_evo2_to_xmlformat()),
with its "contact" objtype filled in with xmlformat names,
matching the xmlformat schema.

Now the engine has all the information it needs.  It knows the sync
plugin's objtype (contact), its format (vcard30), its capabilities
(evo2-caps, for objtype contact), and how to put meaning to those
capabilities (the caps converter to xmlformat).  It can now take data from
some other plugin, convert that to xmlformat, strip out any fields
that evolution can't handle, then convert it to vcard30, and vice versa,
all while being completely automatic.  There are no config files for
evolution... this data comes straight from evolution itself, and so
if evolution changes, the plugin adapts as well.

So short answer: yes, as I see it, we do need the evo2 format plugin. :-)

- Chris

Re: [Opensync-devel] capabilities problem

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

On Fri, Aug 02, 2013 at 01:35:43PM +0100, Mark Ellis wrote:
> Equally annoyingly in this situation, opensync doesn't seem to register
> capabilities by objtype, but by format, if I'm reading it right, even
> though it references capabilities by objtype here.

Capabilities are fairly standalone, as far as I can tell.  It is the
caps_converter which pertains to a format.

Capabilities can be associated with a plugin member, as you can see
from osync_member_load_capabilities() and osync_member_get_capabilities().
In the member's case, the capabilities are loaded from an XML file in
the config.


> I don't really understand the capabilities stuff, and was hoping to
> avoid it, oh well :)

:-)

- Chris

Re: [Opensync-devel] [Fwd: patches 1]

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

On Wed, Aug 07, 2013, Mark Ellis wrote:
> 1-glibdep-threads.diff
> Glib changed some threading functions in 2.32 and deprecated the old
> versions, I've written this to build with both styles depending on the
> version, since 2.32 didn't feel that old.

Thanks Mark for these patches!  I'll putter through them as I have
time.  Hopefully it won't take too long to get them into the main tree.

As I was reading through this patch, and looking at the API change,
I started wondering, wouldn't it be better if we wrapped glib's API
in our own?  Somehow, I like the idea of pointers which are filled,
and freed, rather than keeping the entire sturcture around.
Pointers are opaque, and we don't need the structure
definition to work with them.

So with that in mind, I'm not sure why glib decided to change the
way they did, but regardless, we don't have to follow in their footsteps,
and we can write our own pointer-oriented API.  It might even be
cleaner in the long run.

Compare to this patch:
http://lists.freedesktop.org/archives/gstreamer-commits/2012-March/061105.html

What do you think?  Are there any drawbacks to writing our own?

Thanks,
- Chris

[Opensync-devel] patches 4

[Mark E. <ma...@mp...>]

pyplug_optional_finalize.diff
Stops the python plugin dying if there is no optional finalize function

evoplug-glib-deprecated.diff
g_type_init() was deprecated in glib 2.36, so made it conditional.

evoplug-mem-management.diff
Started off as a memory management cleanup, hence the name, turned into
a general clean up and bug hunt, corrected some error reporting and
trace logs, even fixed some code formatting. Would've been nice to break
up the patch, but it was all a bit interwoven.

evoplug-read-func.diff
Add _read_ functions to the sinks, no particular reason, they just
weren't there.

Mark

[Opensync-devel] [Fwd: patches 3]

[Mark E. <ma...@mp...>]

-------- Forwarded Message --------
> From: Mark Ellis <ma...@mp...>
> To: ope...@li...
> <ope...@li...>
> Subject: patches 3
> Date: Wed, 07 Aug 2013 12:45:13 +0100
> 
> 4-python.diff
> loads of plugin related extensions to the python bindings
> 

[Opensync-devel] [Fwd: patches 1]

[Mark E. <ma...@mp...>]

Try again, zipped this time.

-------- Forwarded Message --------
> From: Mark Ellis <ma...@mp...>
> To: ope...@li...
> <ope...@li...>
> Subject: patches 1
> Date: Wed, 07 Aug 2013 12:41:57 +0100
> 
> Hi Chris
> 
> First of my patches attached, tried sending all at once but it's too big
> for the list, so i'll send through bit by bit.
> 
> The order is in some cases relevant so they apply
> cleanly.
> 
> 1-glibdep-threads.diff
> Glib changed some threading functions in 2.32 and deprecated the old
> versions, I've written this to build with both styles depending on the
> version, since 2.32 didn't feel that old.
> 

[Opensync-devel] patches 2

[Mark E. <ma...@mp...>]

2-glibdep-get-time.diff
g_source_get_current_time() was deprecated in glib 2.28, which seems old
enough to me to not worry about, so I've bumped the required version to
2.28 and rewritten with g_source_get_time()

3-glibdep-basename.diff
g_basename() was deprecated ages ago.