Currently osmo-0.2.4 is broken in rawhide because syncml in rawhide has been bumped to 0.5.0, and osmo version 0.2.4 doesn't support the new API. I disabled syncml support temporarily in rawhide until such time the osmo bindings are syncml are ported to the new API to fix the broken deps: osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
I took the liberty of rebuilding osmo in rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=78453 This fixes the broken deps, but this bug should probably be kept open until such time as an osmo with updated API for syncml is released.
Is it possible to re-add syncml 0.5.0 support? Looking at osmo upstream SVN: http://osmo-pim.svn.sourceforge.net/viewvc/osmo-pim/trunk/ it doesn't look like there is a version with support for the new 0.5.0 API in the works.
I'm actually a little annoyed at the libsyncml maintainer who bumped the soname / API without checking what packages depended on it and whether they had been ported to the new API. He then tried pushing updates to F-10 and F-9 which would have caused major dep breakage in released version: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0540 Thankfully he unpushed them.
Hi there. I'm very sorry to have annoyed you. I was not aware of the consequences my update had as it worked for me. Since I'm a very new contributor I have learned my lesson from this. I will revert rawhide to the old version as soon as I find time to do so. The reason for bumping to 0.5.0 was that I wanted to import blueZync (http://bluezync.kaarposoft.dk/) which requires to have a newer lib. Sorry again.
(In reply to comment #4) > Hi there. I'm very sorry to have annoyed you. I was not aware of the > consequences my update had as it worked for me. Since I'm a very new > contributor I have learned my lesson from this. It's OK, we all make mistakes. Actually I think your sponsor should probably have taken more time to explain the need to run repoquery to check dependent packages and so on. > I will revert rawhide to the old version as soon as I find time to do so. Actually, please don't do that for the moment, since you would have to introduce an Epoch tag, which is a pain, otherwise libsync-0.5.0 will never be updated to libsync-0.4.x see: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Version for more details. One possible solution (especially if libopensync-plugin-syncml and osmo aren't likely to update to the new API soon) is to introduce a compat-libsyncml-0.4.x version for the old apps to build against and keep libsyncml at 0.5.0, see: http://fedoraproject.org/wiki/JeremyKatz/DraftCompatPackages > The reason for bumping to 0.5.0 was that I wanted to import blueZync > (http://bluezync.kaarposoft.dk/) which requires to have a newer lib. OK, thanks for the clarification.
(In reply to comment #4) > I will revert rawhide to the old version as soon as I find time to do so. No need to do that right now. Can you try and port Osmo to the new version? That would be much more constructive and interesting thing to do. Otherwise I will give it a try when I get some time.
2 months passed, osmo has still no syncml support and libopensync-plugin-syncml also doesn't build against the new version. I think libsyncml should be reverted with an Epoch bump, I see no other solution. There isn't a single package which can use the version 0.5.0 so it is completely useless.
(In reply to comment #7) > 2 months passed, osmo has still no syncml support and libopensync-plugin-syncml > also doesn't build against the new version. I think libsyncml should be > reverted with an Epoch bump, I see no other solution. There isn't a single > package which can use the version 0.5.0 so it is completely useless. libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0.
(In reply to comment #8) > libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0. I am aware of this and contacted the maintainer on 8.3.2009 regarding this issue and haven't received an answer yet.
> libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0. 1. Are you sure? It says "SET ( LIBSYNCML_MIN_VERSION "0.4.7" )" and appears to have no code to handle 0.5.0 at all. 2. libopensync-plugin-syncml-0.38 does not build against libopensync 0.36 which is what Rawhide has now, it needs at least 0.37 (major API changes between 0.36 and 0.37).
(In reply to comment #10) > > libopensync-plugin-syncml-0.38 would build against libsyncml 0.5.0. > > 1. Are you sure? It says "SET ( LIBSYNCML_MIN_VERSION "0.4.7" )" and appears to > have no code to handle 0.5.0 at all. Yes, it is also mentioned in the release notes. The packages I built used 0.5.0. > 2. libopensync-plugin-syncml-0.38 does not build against libopensync 0.36 which > is what Rawhide has now, it needs at least 0.37 (major API changes between 0.36 > and 0.37). The libopensync-* packages are afaics synchronized and should all build when they area all updated. The API changes are expected to happen, because it is a development release and this is clearly stated by upstream.
libsyncml.so.0 was last time used in 0.4.7. Then it was bumped to so.2 which is current API. It's a stable release, so why not include it into Fedora if at the same time taking care that apps depending on old API will find their dependencies elsewhere? What you guys *could* do, is to communicate with the upstream. They *are* in IRC and mailing lists and available, every day, they speak english. The draft 0.3x libopensync version should not be kept in upcoming fedora releases. They should have never been included into fedora. IMO whole opensync should be dropped until there will be something that works, gets released and is *supported* by the upstream. 0.22 is not that, it may work for someone but mostly it doesn't. It's definitely not supported by the upstream. That's just a can of worms waiting to get opened in f10/f11 release lifespan. Tuju
(In reply to comment #12) > libsyncml.so.0 was last time used in 0.4.7. > > Then it was bumped to so.2 which is current API. It's a stable release, so why > not include it into Fedora if at the same time taking care that apps depending > on old API will find their dependencies elsewhere? Reverting to the old API is what is probably going to happen see the thread here: http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01272.html and also this post: http://www.redhat.com/archives/fedora-devel-list/2009-March/msg01359.html
I'm subscribing the list. You're going to do that compatibility package at some point anyway, the way you're doing it just going to introduce the epoch for good. If someone is planning to use 0.5.0 for her project or to create testing packages for Fedora from opensync for example, installing those pkgs will be harder for testers. Regarding those mails, I'm wondering were you get these opinions "opensync 0.22 works pretty well"? One of the loudest commentor in this topic for example doesn't even have anything to try with (phone/pda). Note that *copying* your vcards from phone to dekstop pim once doesn't qualify as syncing. You can do that also with kdepim dir resource and libsyncml cli tools without msynctool/osynctool. Problems start when you fall into slowsync and comparison fails, creates duplicates etc. It's not working for the most users. If it would, there wouldn't be a major breakage in trunk, just small enhancements. Speaking of supported 0.22 branch, cstender did the last change in svn at 21.08.2008, the one bigger set before that was 4.11.2007. This is year 2009. I don't call it supported. Find a developer in upstream who commits to spend time with that (other than holding your hand in irc) and I agree that it's supported. It's not, it's dead.
Since libsyncml support has now been re-enabled in Osmo, can we close this as RAWHIDE now.
(In reply to comment #15) > Since libsyncml support has now been re-enabled in Osmo, can we close this as > RAWHIDE now. Done. Koji build for reference: http://koji.fedoraproject.org/koji/buildinfo?buildID=96279