| Summary: | Build issue: tdepim/kitchensync will not build against opensync >= 0.39 | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdepim | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | wishlist | CC: | bugwatch, deloptes, kb9vqf, ktbz.aoneshot.eliddell, michele.calgaro, slavek.banko |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: | Patch to fix configure/cmake to build against opensync 0.22 or 0.3x | ||
I'm changing the summary to "Build issue:" to match all other such bug reports. From what I can see, the OpenSync project has stalled, its packages are no longer included in Debian/Ubuntu, and its developers recommend not using 0.3 as they are (still) attempting to move to 0.4. See http://www.opensync.org/wiki/download for additional information. At this time I see no reason to support opensync > 0.2x. > At this time I see no reason to support opensync > 0.2x.
That's fine. Let's leave this as a wish list item.
Comment on attachment 902 [details]
Patch to fix configure/cmake to build against opensync 0.22 or 0.3x
Removing the proposed partial patch: irrelevant to the current resolution of non-action.
Hi, I suggest you close this as "won't fix" as opensync project is dead. PS: My vision on this would be to rework all of the mobile related packages as some of them are really outdated, but back to the sync part, kitchensync should be reworked to interface syncevolution. I started working on tdepim plugins for that and I was almost done with the addressbook part, when I hit an issue with the syncengine and it could take a while. I think the best way to address this is to add opensync 0.22 to GIT. In Debian/Ubuntu, opensync 0.22 is already maintain separately as a build dependency package.
> I started working on tdepim plugins for that and I was almost done with the
> addressbook part, when I hit an issue with the syncengine and it could take a
> while.
Good to hear there is someone else working on TDE stuff!
You are welocmed and keep it up :-)
I wish I would have more time to do so. It makes fun creating useful software and one learns always something in the process. However in the next few weeks I'm booked out Regarding this issue I suggest to just drop all that stuff in future releases. It makes no point to maintain something that never worked properly and is not supported anymore, but when the time comes I will raise this to the community. regards kitchensync builds, or used to, against libopensync 0.36, but fails against 0.38--see https://bugs.gentoo.org/show_bug.cgi?id=262397 . There seems to have been a patch involved, which can be obtained from the kdepim-3.5-patchset-05.tar.bz2 bundle at http://www.mmnt.net/db/0/4/debian.uchicago.edu/kde-sunset/ . kitchensync does have to be ported to another backend if we're not adopting libopensync into the tree, though, because the Opensync project is deader than a doornail. Sources can still be obtained from https://web.archive.org/web/20140724173847/http://www.opensync.org/download/releases/ , but they won't build against modern glib (I had 0.39 fail against glib 2.44.1), and the package is already unavailable on some distros. The alternative is, as deloptes suggests, dropping kitchensync. Probably quicker to adopt opensync 0.22. This is what we are currently doing on all debian/ubuntu distros, where we are maintaining opensync 0.22 as an external library dependency. Not sure how much work would be involved in changing the backend for kichensync, as well as the benefit against the TDE developer workforce headcount :-) At the same time I would like *not* to drop Kitchensync (unless there is no other way) in case some existing user is using it (I don't BTW) I don't use it either--I discovered the various problems while working on ebuilds for tdepim. Gentoo has dropped libopensync already (one broken 0.39 ebuild in some random developer's overlay doesn't count); a quick skim of some search results suggests that Arch has dropped it too, OpenSUSE still has it, and I can't tell what Red Hat/Fedora have done. Even if we do adopt libopensync, though, how much of it is still good/useful? Especially the last stable release 0.22, which was already three years old when development ended in 2010. How many modern devices (post-2012, say) will still synchronize correctly using this lib? How about Web-based PIM sources? Other desktops' software? Anyone got any idea? I have the code from the opensync svn from arround 2010 if someone is interested I might have also some older versions. Our understanding is that it is not bad, but syncml implementation is very poor and architecture of opensync is not compatible with the syncml logic. So you can use it for anything else but for phones. How good is it working for the other part I don't know. We/You could talk to Graham Cobb - can be found @syncevolution mailing list or somewhere out there. I think syncevolution is much better off in terms of support and syncml functionality. However opensync has some advantages over syncevolution. I finished the syncevolution address book and calendar plugins for TDE and I'm looking forward to get the memo/notes and todos part next. It could take 1-2 months though, depending on how much free time I have. You could have a look into syncevolution and check the options it supports. > Even if we do adopt libopensync, though, how much of it is still good/useful?
> Especially the last stable release 0.22, which was already three years old
> when development ended in 2010. How many modern devices (post-2012, say) will
> still synchronize correctly using this lib? How about Web-based PIM sources?
> Other desktops' software? Anyone got any idea?
All good points E. and sorry for the late reply.
Frankly speaking I have no idea how useful opensync can or can not be.
Probably moving to a different and more modern sync mechanism/protocol is the right way to go, but currently we do not have the resources to do so. If someone wants to take up the challenge, he would be welcomes.
I think there were also some discussions in ML in the past about updating the sync mechanism.
In the short term, importing opensync in the main trunk is probably the most doable option in terms of resource avilability.
> I finished the syncevolution address book and calendar plugins for TDE and I'm > looking forward to get the memo/notes and todos part next. It could take 1-2 > months though, depending on how much free time I have. Very good, keep it up. When is all done let us know and we can push your code to the main repot. > We/You could talk to Graham Cobb - can be found @syncevolution mailing list or > somewhere out there. > I think syncevolution is much better off in terms of support and syncml > functionality. However opensync has some advantages over syncevolution. Perhaps you could take this on as the next step once you complete what you are currently doing :-) Just an idea, we need more developer ;-) Thanks for your contributions so far. Kitchensync has been dropped in R14.2.0-dev, so I am closing this bug as wontfix. |
Created attachment 902 [details] Patch to fix configure/cmake to build against opensync 0.22 or 0.3x tdepim/kitchensync will build against the current stable version of opensync 0.22, but fails to build against opensync 0.39. I don't know which version in the 0.3x development branch that kitchensync begins to fail. Doesn't really matter because only the latest version in a development branch counts. :) Part of the problem is renaming of the pkgconfig files, for which I am attaching a proposed patch. Part of the problem is opensync functions that no longer exist in the 0.3x branch or have been renamed. Some code work is needed and probably preprocessor tests in order to support both 0.22 or 0.3x.