Synergy has been lacking a proper release for a while. There hasn't been much development lately either. Synergy-Plus is right now just a maintenance release, with future release planning on introducing new features. Attached is an ebuild, doesn't seem there is much to it right now. I tried running eautoreconf and econf in the src_configure() , but it wasn't running so I moved it to src_compile, but now I get QA Notices, not sure what the proper approach is. I have tested this ebuild on a ~amd64 box, and it is connecting to a synergy2 release running on OS X 10.4
Created attachment 197465 [details] synergy-plus-1.3.4.ebuild
I mistakenly marked this ebuild as 1.3.4, thinking it was the latest release, but it is actually 1.3.3
Thanks Ryan, this really looks interesting, although the fact that it needs an eautoreconf run means upstream has no clue about packaging the stuff (and the way they name the tarball also suggests so)… sigh. If you can reach upstream and convince them that for Linux distributions it's MUCH better if they just run "make dist", then that would be fantastic. I'd sincerely rather not add this to the tree until they decide to do that because it's a huge hassle to deal with such upstream usually...
Thanks I'll reach out to them and see.
the relevant synergy-plus request. http://code.google.com/p/synergy-plus/issues/detail?id=105
Please could you give this some time? As you can tell this is a relatively new fork and we haven't had chance to get started. The current tar.gz has been uploaded for convenience of developers, not end users, hence why it is named after the Mercurial revision and not the version number. Once we get to stable 1.3.4 we will release, synergy-plus-1.3.4.tar.gz - but we may also be using the SCons or CMake build system.
I've added a tar.gz created with `make dist` and added it to the downloads page. http://code.google.com/p/synergy-plus/downloads/list Please bare in mind this is an unstable release :)
fyi, it would still be beneficial to not have the commit hash in the package name, it would require extra work to modify the ebuild every time to change the build package. Granted a small request but it makes version bumps easier. Thanks for the cooperation, imho, it is nice to see developers work with the package maintainers of distro's
Thanks, happy to help. The commit hash is to indicate that it's not a stable version of the code; it's version 1.3.3, with a few fixes. I realise that this is unusual, but it's because version 1.3.3 existed before I joined the project, and doesn't compile on Linux.
I can understand that now. I would say that a version scheme needs to be thought out. Obviously, you have the x.y.z , but maybe you do what the kernel does, and instead of bumping to 1.3.4, when you already have that release planned, and these are just bug fixes, you label it 1.3.3.1. It makes it easier for package maintainers to version the packages and gives a clear lable that 1.3.3.1 is a later release the 1.3.3
Hmm, fair point. To be honest, I don't like the revision number tagged on the end now I think about it. We could just bump up the rev number to 4... To be honest, it's pretty stable how it is, and since we dont have a 1.3.3 tar.gz I think this would be a fair exception, what do you think?
you could do that also, Make you planned releases 1.x and then your patch releases between planned ones being 1.x.y So all the ones between major milestones are 1.3.4 , 1.3.5. Then when you reach the objectives you've set for a milestone, increment the package to 1.4. I've never maintained releases or software projects, so I am just speaking from my schooling, and what I've seen in the open source community.
(In reply to comment #7) > I've added a tar.gz created with `make dist` and added it to the downloads > page. > > http://code.google.com/p/synergy-plus/downloads/list > > Please bare in mind this is an unstable release :) > http://code.google.com/p/synergy-plus/issues/detail?id=124 http://synergy-plus.googlecode.com/files/synergy-plus-1.3.4.tar.gz is expected to contain a directory named synergy-plus-1.3.4 instead of synergy- plus-1.3.3
Issue 124 has been fixed.
Created attachment 199131 [details] synergy-plus-1.3.4.ebuild Here is an updated ebuild, getting rid of the vars needed before, and simpilified the src_compile() Also change the src_install to use emake instead of make, must of been a typo from before? I don't have the ability to test it, but it compiles fine on ~amd64. Will be using it come Monday morning.
MY_PN is now unused, and relies on the undefined variable DIGEST. Using 'make install' works, but 'emake install' is preferred if the package can install in parallel. For a new ebuild, it would be nice, though by no means mandatory, to submit it as EAPI=2. Regardless of whether you use EAPI=2, you can delete src_compile(). The default src_configure and src_compile in EAPI 2, according to <http://devmanual.gentoo.org/ebuild-writing/eapi/index.html#phases>, will do the right thing. The EAPI 0 defaults appear to be equivalent to what you have now, as well. As presently written, synergy-plus cannot be built while synergy is installed. I can understand not being able to install both at the same time, but do you need to prohibit building as well?
Created attachment 199147 [details] synergy-plus-1.3.4.ebuild Removed a few unneeded lines (inherits, MY_PN, src_compile) and changed the postinst elog text
The new ebuild looks fine but dodoc/doins of doc and examples should die too (and imho the example should be installed under docs rather than in /etc (I don't like my /etc polluted!)
how about /etc/synergy.conf.example instead of /etc/synergy.conf
Created attachment 199149 [details] synergy-plus-1.3.4.ebuild EAPI=2 and die on doins and dodoc
Comment on attachment 199149 [details] synergy-plus-1.3.4.ebuild also removed the build dependency on !x11-misc/synergy
(In reply to comment #18) > imho the example should be installed under docs rather than in /etc (I > don't like my /etc polluted!) I find that odd. I am used to seeing example files in /etc, look at samba (/etc/samba/smb.conf.example). Although I advice on adding a .example at the end of it, since this is not a default conf file.
Tested, works great on ~amd64. Upstream is a non-starter with recent GCC and X11 releases. Please add to tree.
*** Bug 289255 has been marked as a duplicate of this bug. ***
Confirmed working well on amd64 as well... Wondering why this is masked by package.keywords and package.mask? I'd enjoy seeing this in the tree as well.
Was added to the tree in October 2009 so closing as FIXED.
