After years of work SynCE 0.10.0 version released. It offers Windows Mobile 5 synchronization with contacts, task and files. Supports connections thru USB or Bluetooth subsystem. Full set of ebuilds for this version could be gathered from SVN: http://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo/ Or with 'layman' xml: http://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo/synce-wm5-layman.xml Packages included in ebuilds: # app-pda/synce-0.10.0 # app-pda/synce-gnome-0.10.0 # app-pda/synce-gnomevfs-0.10.0 # app-pda/synce-librapi2-0.10.0 # app-pda/synce-librtfcomp-1.1 # app-pda/synce-libsynce-0.10.0 # app-pda/synce-odccm-0.10.0-r1 # app-pda/synce-pywbxml-0.1 # app-pda/synce-rra-0.10.0 # app-pda/synce-serial-0.10.0 # app-pda/synce-sync-engine-0.10.0 # app-pda/synce-vdccm-0.10.0 # dev-libs/libwbxml-0.9.2_p48 - patched version of libwbxml (does not break compatibility with original) # sys-fs/usb-rndis-lite-0.10.0 # sys-fs/usb-rndis-ng-0.10.0
*** Bug 159958 has been marked as a duplicate of this bug. ***
Is there a reason to not include them in the official portage tree? ..
After the request for help at http://bugs.gentoo.org/show_bug.cgi?id=135043#c28 and discussions via email, following soon are the 0.10.0 ebuilds from layman: app-pda/synce/synce-0.10.0.ebuild app-pda/synce-gnomevfs/synce-gnomevfs-0.10.0.ebuild app-pda/synce-librapi2/synce-librapi2-0.10.0.ebuild app-pda/synce-rra/synce-rra-0.10.0.ebuild app-pda/synce-gnome/synce-gnome-0.10.0.ebuild app-pda/synce-odccm/synce-odccm-0.10.0-r1.ebuild app-pda/synce-libsynce/synce-libsynce-0.10.0.ebuild app-pda/synce-vdccm/synce-vdccm-0.10.0.ebuild app-pda/synce-serial/synce-serial-0.10.0.ebuild app-pda/synce-sync-engine/synce-sync-engine-0.10.0.ebuild sys-fs/usb-rndis-lite/usb-rndis-lite-0.10.0.ebuild sys-fs/usb-rndis-ng/usb-rndis-ng-0.10.0.ebuild app-pda/synce-librtfcomp/synce-librtfcomp-1.1.ebuild app-pda/synce-pywbxml/synce-pywbxml-0.1.ebuild dev-libs/libwbxml/libwbxml-0.9.2_p48.ebuild
Created attachment 138669 [details] synce ebuild
Created attachment 138670 [details] synce-gnomevfs ebuild
Created attachment 138672 [details] synce-librapi2 ebuild
Created attachment 138674 [details] synce-rra ebuild
Created attachment 138675 [details] synce-gnome ebuild
Created attachment 138676 [details] odccm ebuild
Created attachment 138677 [details] libsynce ebuild
Created attachment 138679 [details] vdccm ebuild
Created attachment 138680 [details] synce-serial ebuild
Created attachment 138682 [details] sync-engine ebuild
Created attachment 138684 [details] usb-rndis-lite ebuild
Created attachment 138685 [details] usb-rndis-ng ebuild
Created attachment 138687 [details] librtfcomp ebuild
Created attachment 138689 [details] pywbxml ebuild
Created attachment 138691 [details] libwbxml ebuild This one is a patched version of the original. It is suggested the patches get merged with the portage version, under a synce use flag or something?
note that synce 0.11 was just released (Bug #204990).
*** Bug 204990 has been marked as a duplicate of this bug. ***
sorry didn't realise I should have used the same bug :) Also, the version naming has changed from 0.x.y to just 0.x but I can't change summaries. Could someone change summary to 0.11 instead of 0.11.0? And the due message could probably go too. thanks.
dropping the due date, it will get done, just need some more time and some help from Iain.
The ebuilds I am intending to do are listed here: http://www.synce.org/moin/IainBuchanan Also, could someone please change the URL to http://sourceforge.net/mailarchive/message.php?msg_id=1199905467.8252.0.camel%40localhost or similar for the 0.11 announcement? thanks.
On your page, you wrote, that you perhaps won't need to bump the usb-rndis-lite ebuild. Why?
(In reply to comment #24) > On your page, you wrote, that you perhaps won't need to bump the usb-rndis-lite > ebuild. Why? because it needs to install into /lib/modules over the top of your -sources built copy, so I don't think this style of ebuild would make it into portage. Also, there is a kernel patch that lets you do the same thing for newer kernels, by patching the kernel source before you make it. Perhaps the solution would be to get this patch into the *-sources ebuilds with a use flag or something. But I don't know enough about *-sources yet... Eventually this patch will be supplied upstream to kernel.org so you won't have to do anything, but that's not for a while yet!
Thanks for the ebuilds. Great work. Note: Additional to recreating partnerships in sync-engine as mentioned in that ebuild, I had to recreate groups in opensync as well. If that is a general requirement, please add it to the ebuild messages and ask the sync-engine developer to write it into the README. (In reply to comment #25) > Also, there is a kernel patch that lets you do the same thing for newer > kernels, by patching the kernel source before you make it. Perhaps the > solution would be to get this patch into the *-sources ebuilds with a use flag > or something. But I don't know enough about *-sources yet... > > Eventually this patch will be supplied upstream to kernel.org so you won't have > to do anything, but that's not for a while yet! > For the time being you could perhaps add the patchfile to the synce ebuild and provide some einfo messages for instructions how to apply it.
(In reply to comment #26) > Thanks for the ebuilds. Great work. np, thanks! Did you use 0.10 attached here or 0.11 from synce.org? > Note: Additional to recreating partnerships in sync-engine as mentioned in that > ebuild, I had to recreate groups in opensync as well. If that is a general > requirement, please add it to the ebuild messages and ask the sync-engine > developer to write it into the README. hm.. I can see this list of messages growing - perhaps a link to the doco on the wiki would be better... > (In reply to comment #25) > > Eventually this patch will be supplied upstream to kernel.org so you won't have > > to do anything, but that's not for a while yet! > > > For the time being you could perhaps add the patchfile to the synce ebuild and > provide some einfo messages for instructions how to apply it. good idea - the patch can be installed, and the user can patch at her convenience.
(In reply to comment #27) > np, thanks! Did you use 0.10 attached here or 0.11 from synce.org? 0.11 from synce.org layman overlay > hm.. I can see this list of messages growing - perhaps a link to the doco on > the wiki would be better... So the new wiki needs a gentoo page and/or instructions for updating from previous versions.
(In reply to comment #28) > (In reply to comment #27) > > np, thanks! Did you use 0.10 attached here or 0.11 from synce.org? > 0.11 from synce.org layman overlay good! > > hm.. I can see this list of messages growing - perhaps a link to the doco on > > the wiki would be better... > So the new wiki needs a gentoo page and/or instructions for updating from > previous versions. how's this for a start: http://www.synce.org/moin/UpgradeGuide --- For others watching: some updates on the libwbxml issue. We should shortly have wbxml conversion built into sync-engine, removing the need for libwbxml completely.
Can someone sum up the status of the ebuild development here? jsin, are the ebuilds at a stage that can be merged into the tree? This bug is blocking a security bug.
work continues in the overlay, but it could do with some review from a gentoo dev or two :) I've been away for a bit, but now I'm back I will continue to tweak and maintain (with others) the overlay. 0.11 is in there, 0.11.1 was released just before my holidays. Comments welcome. (It turns out I'm not a "sufficiently empowered user" to change the summary - could someone change it to 0.11.1, thanks)
I read something about a kernel patch. Is that necessary to actually use synce? What fails if I do not add it. Is that an actual patch, or an additional module? As far as inclusion in our kernels goes, that could be done, but I would rather avoid it and have it included upstream. I don't know what the patch looks like though.
(In reply to comment #32) > I read something about a kernel patch. Is that necessary to actually use synce? usb-rndis-lite contains the same source for building a module, so that it is not necessary to patch your kernel. > What fails if I do not add it. Is that an actual patch, or an additional > module? you must have the module (or the patch), or you can't connect. > As far as inclusion in our kernels goes, that could be done, but I would rather > avoid it and have it included upstream. I don't know what the patch looks like > though. patch is here: http://synce.svn.sourceforge.net/svnroot/synce/trunk/patches/linux-2.6.22-rndis_host-wm5.patch kernel.org doesn't like it for it's incompatibility with other rndis devices: http://bugzilla.kernel.org/show_bug.cgi?id=8094#c36 there may be another option in the future: http://sourceforge.net/tracker/index.php?func=detail&aid=1888183&group_id=30550&atid=399603 But for now, the usb-rndis-lite module seems to satisfy most.
according to the changelog, a patch has made it into 2.6.25: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.25 "rndis_host: fix transfer size negotiation" so the patch / module will not be necessary for much longer...
Found some things need to be fixed: - make the ebuilds not depend on "=app-pda/some_synce_stuff-0.11" but on "~app-pda/some_synce_stuff-0.11" -- For example there is at the moment "app-pda/synce-sync-engine-0.11-r1" which you can't install because portage wants to downgrade to the =-0.11 version there after - /etc/init.d/odccm should depend on hald being started
(In reply to comment #35) > Found some things need to be fixed: Sorry for the delay - flew interstate to visit real life :) > - make the ebuilds not depend on "=app-pda/some_synce_stuff-0.11" but on > "~app-pda/some_synce_stuff-0.11" -- For example there is at the moment > "app-pda/synce-sync-engine-0.11-r1" which you can't install because portage > wants to downgrade to the =-0.11 version there after Checked this in a little while ago - I've got rid of all "=blah". They're now "~blah" or ">=blah". > - /etc/init.d/odccm should depend on hald being started how come? more criticism from devs please :)
(In reply to comment #36) > > - /etc/init.d/odccm should depend on hald being started > > how come? if you don't have hald started: Devoty necoro # /etc/init.d/odccm start * Starting Synce ... * Starting odccm ... ** (odccm:5947): WARNING **: libhal_ctx_init failed with D-Bus error (null): (null) ** (odccm:5947): WARNING **: init_hal: failed [ ok ]
strange... couldn't reproduce it. I put "after hald". thanks.
0.11.1 ebuilds are now in the overlay. Haven't played with them much yet. more comments?
!!! Digest verification failed: !!! /usr/local/layman/synce/app-pda/synce-odccm/synce-odccm-9999.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 913 !!! Expected: 903 Could you fix this? And btw ... I saw, that nothing depends on hal. So (as it requires it though), this is either an error in the ebuild (missing dep) - or an automagic dep in the package ^^ But: If I remember correctly, odccm _uses_ hal to get things done, so I guess, there is a dependency missing
sorry for delay. Manifest was fixed before your post :) hal dep added.
Is there anything holding back the insertion into the portage tree? I use it on a nearly everyday basis and it works :)
(In reply to comment #42) > Is there anything holding back the insertion into the portage tree? A maintainer? No offence jsin :) > I use it on a nearly everyday basis and it works :) cool.
According to the synce mailinglist, 0.12 is out. http://sourceforge.net/mailarchive/message.php?msg_name=20080716003243.GA3964%40salieri.jonnylamb.com The roadmap on the wiki (http://www.synce.org/moin/SynceRoadmap) says Gentoo ebuild is 'done'. Where or when?
(In reply to comment #44) > According to the synce mailinglist, 0.12 is out. > http://sourceforge.net/mailarchive/message.php?msg_name=20080716003243.GA3964%40salieri.jonnylamb.com Indeed it is :) > The roadmap on the wiki (http://www.synce.org/moin/SynceRoadmap) says Gentoo > ebuild is 'done'. er... I think Jonny Lamb was assuming I'd do them since I've been mostly maintaining the last few... I've just had a baby (excuses, excuses) so I haven't got around to it yet. > Where It will be in the usual svn overlay > or when? when I get a Round Tuit :) Soon I hope.
Created attachment 166113 [details] synce-kio-rapip ebuld
Thanks, added to the overlay, with a few tweaks. Can someone please change the summary to 0.12? 0.12 ebuilds are all in the overlay. Can a dev comment on a plan to get these into the tree? I would like to close this bug, eventually :)
some some notes for last changes in SynCE 0.12 ebuilds 1. synce-sync-engine-0.12.ebuild src_install function. 1) Change dir for synce-opensync-plugin.py for <app-pda/libopensync-0.30 to /usr/lib/opensync/python-plugins. 2) Add "Gentoo way" to install org.synce.service. It is not nessary to include addition file 'org.synce.service' to synce-hal-0.1 ebuild, because it alredy exists in synce-sync-engine tar src_install() { DOCS="CHANGELOG COPYING" insinto /usr/share/${PN}/ doins config/syncengine.conf.xml insinto /usr/share/dbus-1/services/ doins config/org.synce.SyncEngine.service distutils_src_install if has_version '>=app-pda/libopensync-0.30'; then insinto /usr/lib/opensync-1.0/python-plugins newins plugins/synce-opensync-plugin-3x.py synce-opensync-plugin.py else insinto /usr/lib/opensync/python-plugins newins plugins/synce-opensync-plugin-2x.py synce-opensync-plugin.py fi } 2. where is not meta ebuild for SynCE 0.12 so, i have some wishes to USE and DEPEND variables: 1) add KDE use flag 2) add new synce-gvfs for gnome users IUSE="gnome kde syncengine" DEPEND="app-pda/synce-hal syncengine? ( ~app-pda/synce-sync-engine-0.12 ) kde? ( app-pda/synce-kio-rapip ~app-pda/synce-kpm-0.12 ) gnome? ( ~app-pda/synce-gvfs-0.1 ~app-pda/synce-gnomevfs-0.12 ~app-pda/synce-trayicon-0.12 )"
runoverheads: please resync and let me know how it looks for you now.
(In reply to comment #49) I have make some small changes in my local ebuilds. Maybe it will be interesting and for others 1) --- synce-sync-engine-0.12.ebuild 2008-09-30 11:19:19.000000000 +0400 +++ synce-sync-engine-0.12_my.ebuild 2008-09-30 13:37:10.000000000 +0400 @@ -39,6 +39,9 @@ insinto /usr/share/${PN}/ doins config/syncengine.conf.xml + insinto /usr/share/dbus-1/services/ + doins config/org.synce.SyncEngine.serv + distutils_src_install # TODO - move this to separate ebuilds 2) Iain, what's wrong in synce-hal-0.2 for you? I successefully use this version, and it's work fine for me (i don't test with serial, because use kernel mainstream rndis drviver). Additionaly i'm using dhclient util (net-misc/dhcp) for assign dinamic ip for my WM device. --- synce-hal-0.2.ebuild 2008-09-30 11:19:12.000000000 +0400 +++ synce-hal-0.2_my.ebuild 2008-09-30 11:36:23.000000000 +0400 @@ -12,6 +12,7 @@ KEYWORDS="~x86 ~amd64" IUSE="" DEPEND="sys-apps/hal + net-misc/dhcp >=net-libs/gnet-2.0.0 !app-pda/synce-dccm !app-pda/synce-vdccm @@ -32,8 +33,5 @@ src_install() { make DESTDIR="${D}" install || die - insinto /usr/share/dbus-1/services/ - doins "${FILESDIR}/org.synce.service" - dodoc AUTHORS COPYING README ChangeLog } 3) I have unmask app-pda/synce-kio-rapip, but i don't want app-pda/synce-kio-rapip-9999 by dependency --- synce-0.12.ebuild 2008-09-30 11:19:08.000000000 +0400 +++ synce-0.12_my.ebuild 2008-09-30 20:07:21.000000000 +0400 @@ -13,7 +13,7 @@ DEPEND="" RDEPEND="~app-pda/synce-sync-engine-0.12 hal? ( - >=app-pda/synce-hal-0.1 + >=app-pda/synce-hal-0.2 ) !hal? ( ~app-pda/synce-odccm-0.12 @@ -22,7 +22,7 @@ ~app-pda/synce-serial-0.11 ) kde? ( - app-pda/synce-kio-rapip + ~app-pda/synce-kio-rapip-0.10 ~app-pda/synce-kpm-0.12 ) gnome? ( 4) I thing, pywbxml library alredy included in app-pda/sync-engine. --- synce-kpm-0.12.ebuild 2008-09-30 11:19:24.000000000 +0400 +++ synce-kpm-0.12_my.ebuild 2008-09-30 13:31:17.000000000 +0400 @@ -22,7 +22,6 @@ ~app-pda/synce-hal-0.1 ~app-pda/synce-librra-0.12 ~app-pda/synce-librtfcomp-1.1 - ~app-pda/synce-pywbxml-0.1 dev-python/PyQt4" SRC_URI="mirror://sourceforge/synce/synce-kpm-${PV}.tar.gz"
(In reply to comment #50) > (In reply to comment #49) > > I have make some small changes in my local ebuilds. Maybe it will be > interesting and for others thanks! > 1) [snip] Yes, moved this out of synce-hal and into sync-engine. > 2) Iain, what's wrong in synce-hal-0.2 for you? someone reported it was broken so I have left 0.1 and 0.2 available. The user should be able to mask 0.2 if they don't want it. > I successefully use this > version, and it's work fine for me great to know! > DEPEND="sys-apps/hal > + net-misc/dhcp This should probably go in RDEPEND, and I don't know how it conflicts with dhcpcd, so investigation needed! > 3) I have unmask app-pda/synce-kio-rapip, but i don't want > app-pda/synce-kio-rapip-9999 by dependency [snip] > - >=app-pda/synce-hal-0.1 > + >=app-pda/synce-hal-0.2 I left this as >=0.1 as this should still install 0.2 for you, but leave 0.1 if others want to p.mask 0.2. > - app-pda/synce-kio-rapip > + ~app-pda/synce-kio-rapip-0.10 normally I wouldn't as -9999 should be masked and won't make it into the official tree, but I think kio-rapip is tied to kpm. > 4) I thing, pywbxml library alredy included in app-pda/sync-engine. you're right! OK, thanks! The overlay has had lots of commits lately. Keep em coming!
Reassigning to herd since jsin has left Gentoo, bug #186663.
mescalinum: can this be closed? All but usb-rndis-lite are in?
yes. also usb-rndis-{lite,ng} is in portage. thank you Iain :)
I'm not sure if this will fall under this bug or if I should create a brand new one. But synce-kio-rapip-0.10 will not compile. Neither will the previous version (non-layman). I'm wondering why I am seeing such a horrific failure on something that is supposed to be patched so it at least will compile. See my attached build.log
Created attachment 174271 [details] Build Log from failed compile of synce-kio-rapip-0.10
