Synchronize Windows CE devices with computers running GNU/Linux, like MS ActiveSync. A little note on this ebuild however. It doest *not* work as is, because this ebuild will try and download 4-5 files (depending on USE) and compile and install these. They are all part of the synce package, and they all need to be installed in order to use the synce package. However, I feel its a complete waste of space and resources creating 5 separate ebulds for one program basically. But as of now, I have a rather huge problem with the ebuild. The ./configure script for the second file checks if the first file (libsynce) is installed. However, the libsynce is still located in the sandbox and not merged with / yet. There is no way to disable the checking for libsynce in the configure script afaik. But is there a way this can be solved still, without creating two or more ebuilds? Ive discussed this issue in the forums (http://forums.gentoo.org/viewtopic.php?t=23223), but havent really found a good solution yet. I have created separate ebuilds if you really request that, but I wanted to ask if it really is neccesary or if there is another way of solving this. Cheers and thank you! -Frank
Created attachment 5927 [details] synce-0.3.1.ebuild Ive chosen the version number on this ebuild according to the version number on the daemon in the program package.
If a developer strongly feels that each file should have its own ebuild, I will not protest - i can see both positive and negative aspects when doing every file in one ebuild. However, I just had to ask someone very fluent in writing ebuilds about their oppinion. Hope this doesnt cause any problems. Cheers! -Frank
Created attachment 5928 [details] digest-synce-0.3.1
I love what you're doing here. I'm interested in the package for myself. I do believe that the ebuild needs to be split up. We will have a app-pda category to prevent clutter elsewhere, so worry not. It's the Right Thing To Do. I will take care of it this weekend, as part of creating the app-pda category. I'm looking forward to being able to sync my ipaq for the first time since this summer. :)
Okay, I've got this emerging successfully as five seperate ebuilds. I had to pull in most of gnome to do it, and I'll have to get gnome working on this previously kde exclusive machine before I can test it. Small game delay for me there. Nevertheless, it looks good and I'm commiting it for testing asap. Look for the ebuilds in your portage mirror soon. :)
These have been committed as ~x86 masked in app-pda. Please test them and report your results here. In particular, I have not added back the informational message or RDEPENDS (like ppp). At this point, the DEPENDS for each ebuild seems minimal. I will test them after sleep, but they will remain masked until we get good feedback here of actually working syncs. :)
Great work! Some comments/questions: - In the description field for each ebuild, perhaps it should reflect what the actual ebuild contains, and not repeat " Synchronize Windows CE devices with computers running GNU/Linux, like MS ActiveSync"? That is, when we now do split them up anyway? - I didnt find the program intuitive at all, after installing every tarball for the first time I sat there going "Hmmm what now?" Of course, if you've used the program before - there's no need for einfo (it just clutters the screen), but perhaps new users would find it very usefull that there is indeed a "How to get connected" page somewhere out there. - One thing I havent tested though, but is this program even useful if you dont install every tar.gz file? (except the gnome-part) I was under the impression you needed them all to do useful things. If so, perhaps make the DEPEND variable drag in every ebuild? - DEPEND for ppp should definately be there imo. It is required for normal operation. Perhaps I misunderstod you as to why ppp shouldnt be a dependancy :-) Also, synce depends on check (I see you've snatched it already ;) but on last rsync it didnt appear. Probably slow mirror, or perhaps check isnt commited to CVS yet. Cheers and thank you for commiting to this "bug"! -Frank
Completely off topic, but is there actually any way I can prevent my posts from appearing on one line? *grrr* I did press enter after each line, but konqueror asked for username and passwd, so I guess a foul-up happened somewhere in between... annoying
Bugzilla has... limitations. :) Press enter. It sucks. We live with it because it does make our life so much easier despite its quirks. However, it allows you to put short verbatim code or patches and not have to worry about newline mangling. Anyway, the split was done because they are seperate packages, and it allows new packages to be added without disrupting existing users. For example, I am interested in helping add a synce-usb package, so adding it in this case is much easier than the monolithic approach. However, I agree with you. The info needs to be put back. I am looking to add a synce ebuild that pulls in all of the packages (and optionally trayicon), prompting the users, perhaps even running a prompted script to set things up. Only synce-trayicon has the gnome dependencies, and I'm talking with the package maintainer directly now to help determine which packages need which runtime dependencies. There's also talk of a new version....
The synce developers release things faster than I change my socks! Well, not really but you get the picture... Who is responsible to bump the ebuild once a new version is available? If its me, it seems kinda backwards I have to go here and post a new comment with new version numbers and md5 checksum. How do I become a gentoo developer, so I can for eksample maintain my own ebuilds? Is it an exclusive club? :-) Anyway, these are the latest versions of the synce package: synce-dccm-0.5.tar.gz c76e2ec3e96e76cd2ad5800de6cfbad8 183076 synce-librapi2-0.5.tar.gz 4f9143012f55dacb4f93ebd10a853e08 269520 synce-libsynce-0.5.tar.gz f51745d3a962dc83338fc543d7f8cab1 226937 synce-serial-0.5.tar.gz 40499748059d6c3039ff77f790fc256e 178010 synce-trayicon-0.3.tar.gz 5c510ef1cce723689379d3f0d24d8027 223350 Hope you'll update the ebuilds as soon as possible. BTW the existing ones works perfectly here. Ive also started looking at porting the synce_kio slave to kde3, but I have to finish my exams first. This will be my primary goal for this xmas programming. I expect the synce_kio to be a plugin for konqueror, and that means we'll also need a trayicon for KDE. Seems like the perfect opportunity to start with KDE app development.
I am responsible for updating the ebuilds, and I will commit the ebuilds for the new release very soon.
Then I assing this to you, Zach.
this bug is fixed; newer versions or synce ebuilds are in portage
