Bug 1542286
Summary: | synergy-2.0.0 should not have been pushed anywhere except rawhide | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Wakely <jwakely> |
Component: | synergy | Assignee: | Ding-Yi Chen <dchen> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | antoine, chkr, dchen, gholms, sheepdestroyer |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | synergy-1.8.8-3.fc27 synergy-1.8.8-3.fc26 synergy-1.8.8-3.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-03-06 17:23:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jonathan Wakely
2018-02-06 00:34:39 UTC
The only justification for the updates is a minor packaging bug originally reported against rawhide, Bug 1476515 That's no reason to push an incompatible major version to stable releases of Fedora and EPEL. I am the one that push the update 2.0.0. As I purely rely on the command line, I failed to recognize that GUI and desktop failed, sorry. The reason I push this update is to accommodate the RHEL 7 boxes that enabled the repository rhel-7-workstation-htb-rpms, with which avahi-compat-libdns_sd-devel-0.6.31-17 conflicts with avahi-0.6.31-19. synergy2 does not require avahi-compat-libdns_sd I've also come up with a fix that bring back synergy1's GUI with a tiny change (remove --no-tray argument). I will file this fix as pull request. (In reply to Jonathan Wakely from comment #0) > > It is no longer possible to use a mouse & keyboard attached to a machine > running synergy in client mode, because synergy grabs all input. Only the > mouse & keyboard attached to the server can be used, which makes it > difficult to keep specific focus on specific windows on both the server and > client desktops. This is a **major** loss of functionality. > > A client running 2.0.0 doesn't seem to be able to connect to a server > running 1.8.8, the logs show: > > [2018-02-06T00:29:21] ERROR: ssl error occurred (system call failure) > [2018-02-06T00:29:21] ERROR: eof violates ssl protocol > [2018-02-06T00:29:21] INFO: client connection may not be secure > [2018-02-06T00:29:21] ERROR: failed to accept secure socket > [2018-02-06T00:29:22] INFO: OpenSSL 1.0.1e-fips 11 Feb 2013 > > This means that if the EPEL 7 update is rejected, it won't be possible to > use synergy between machines running Fedora and RHEL/CentOS. So the update > must also be pushed to EPEL 7 and EPEL 6. > > This update should never have happened anywhere except rawhide! I DO have the working environment that has 1.8.8 server, 2.0.0 and 1.7.6 clients. They are: RHEL 6 (left): 1.7.6-2.el6 as client RHEL 7 (middle): 1.8.8-2.el7 as server Fedora 27 (right): 2.0.0-1.fc27 as client However, I use ssh instead of ssl. Would you mind showing me what's your configuration, especially with SSL? The 1.8.8 server process was running with these args: /usr/bin/synergys -f --no-tray --debug INFO --name knitphad.home --enable-crypto -c /tmp/qt_temp.i10216 --address :24800 --serial-key [...] The 2.0.0 client was simply running "synergy-core --client knitphad" and didn't connect. This is the /tmp/qt_temp.i10216 config file on the server: section: screens knitphad.home: halfDuplexCapsLock = false halfDuplexNumLock = false halfDuplexScrollLock = false xtestIsXineramaUnaware = false switchCorners = none switchCornerSize = 0 wraith.home: halfDuplexCapsLock = false halfDuplexNumLock = false halfDuplexScrollLock = false xtestIsXineramaUnaware = false switchCorners = none +top-left +bottom-left switchCornerSize = 0 end section: aliases end section: links knitphad.home: right = wraith.home wraith.home: left = knitphad.home end section: options relativeMouseMoves = false screenSaverSync = true win32KeepForeground = false clipboardSharing = true switchCorners = none switchCornerSize = 0 end (In reply to Jonathan Wakely from comment #5) > The 1.8.8 server process was running with these args: > > /usr/bin/synergys -f --no-tray --debug INFO --name knitphad.home > --enable-crypto -c /tmp/qt_temp.i10216 --address :24800 --serial-key [...] > > The 2.0.0 client was simply running "synergy-core --client knitphad" and > didn't connect. I can reproduce your error. However, that is because you enable-crypto in server, but not in client. After I configure my client according to https://github.com/symless/synergy-core/wiki/Security, and enable-crypto like so: synergy-core --client --name wraith.home --enable-crypto --debug DEBUG <HostnameOfKnitphad>:24800 It worked. If you are using the GUI in client, if it is unregistered, you don't have SSL support. I don't have synergy account, so I am unable to tell SSL support for registered users. (In reply to Ding-Yi Chen from comment #6) > (In reply to Jonathan Wakely from comment #5) > > The 1.8.8 server process was running with these args: > > > > /usr/bin/synergys -f --no-tray --debug INFO --name knitphad.home > > --enable-crypto -c /tmp/qt_temp.i10216 --address :24800 --serial-key [...] > > > > The 2.0.0 client was simply running "synergy-core --client knitphad" and > > didn't connect. > > I can reproduce your error. However, that is because you enable-crypto in > server, but not in client. I didn't explicitly use that option, it's just how the process starts (possibly because I paid for Synergy 1 support, I'm not sure). > After I configure my client according to > https://github.com/symless/synergy-core/wiki/Security, and enable-crypto > like so: > > synergy-core --client --name wraith.home --enable-crypto --debug DEBUG > <HostnameOfKnitphad>:24800 > > It worked. But the .desktop file installed by synergy-2.0.0-1 doesn't add that option (it doesn't add any options, which is completely borked, Bug 1541640) and synergy-core doesn't support a config file for the client, it has to be on the command-line. So this is another loss of functionality with the new version. > If you are using the GUI in client, if it is unregistered, you don't have I can't use the GUI in the client, because you upgraded synergy to a version with no GUI. I also haven't paid for Synergy 2 support. So again, your upgrade to an incompatible version has caused this. I should not have to make these kind of changes to stable F26 systems. And the biggest problem still remains: It is no longer possible to use a mouse & keyboard attached to a machine running synergy in client mode, because synergy grabs all input. Only the mouse & keyboard attached to the server can be used, which makes it difficult to keep specific focus on specific windows on both the server and client desktops. This is a **major** loss of functionality. synergy-2.0.0-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-0029a198c7 synergy-2.0.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2438eccd2e synergy-2.0.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae0adc3891 (In reply to Jonathan Wakely from comment #7) > (In reply to Ding-Yi Chen from comment #6) > > I didn't explicitly use that option, it's just how the process starts > (possibly because I paid for Synergy 1 support, I'm not sure). > > > After I configure my client according to > > https://github.com/symless/synergy-core/wiki/Security, and enable-crypto > > like so: > > > > synergy-core --client --name wraith.home --enable-crypto --debug DEBUG > > <HostnameOfKnitphad>:24800 > > > > It worked. > > But the .desktop file installed by synergy-2.0.0-1 doesn't add that option > (it doesn't add any options, which is completely borked, Bug 1541640) and > synergy-core doesn't support a config file for the client, it has to be on > the command-line. So this is another loss of functionality with the new > version. I have pushed an new update, 2.0.0-2, which bring back 1.X synergy GUI client. > > If you are using the GUI in client, if it is unregistered, you don't have > > I can't use the GUI in the client, because you upgraded synergy to a version > with no GUI. I also haven't paid for Synergy 2 support. So again, your > upgrade to an incompatible version has caused this. I should not have to > make these kind of changes to stable F26 systems. I did some basic tests, GUI does work without activation and SSL. But I cannot test as registered user, so please help me test 2.0.0-2. synergy-2.0.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ae0adc3891 synergy-2.0.0-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2438eccd2e synergy-2.0.0-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-0029a198c7 I agree with the comment that 2.0 shouldn't have been pushed out. I had no choice in the matter, it just updated the 1.8.8 package. It broke user setups. First hint that something was wrong was when the desktop launcher didn't work, something very basic. Then I found that the 1.8.8 version was gone from the EPEL repo. To get it to work I had to install the sourceforge package and blacklist 2.0. Please undo the damage by restoring the stable version and test the 2.0 package better before releasing. Sorry, I cannot volunteer my users as testers for your changes. They have work to do. > The reason I push this update is to accommodate the RHEL 7 boxes that enabled
> the repository rhel-7-workstation-htb-rpms, with which
> avahi-compat-libdns_sd-devel-0.6.31-17 conflicts with avahi-0.6.31-19.
> synergy2 does not require avahi-compat-libdns_sd
The funny thing is that this dependency is now back because the GUI requires it. (It was the removal of the GUI that dropped the dependency.)
Wouldn't the best solution be to bump Epoch and revert to 1.8.8 altogether?
(In reply to Ding-Yi Chen from comment #6) > After I configure my client according to > https://github.com/symless/synergy-core/wiki/Security, and enable-crypto > like so: > > synergy-core --client --name wraith.home --enable-crypto --debug DEBUG > <HostnameOfKnitphad>:24800 > > It worked. I can confirm that using --enable-crypto on the client works (but I have to start it manually because the .desktop file doesn't work). But I still can't use a mouse + keyboard on the client that way. Testing synergy-core-2.0.0-2 I see this when running on a terminal: [2018-02-09T17:10:10] WARNING: failed to set process uid to: -1 Starting the client with an unqualified hostname fails: $ synergy-core --client knitphad synergy-core: unrecognized option `knitphad' I need to use a qualified hostname like knitphad.home (which is another regression). I've now got the non-open source version of synergy 2 installed, and it does allow me to use both mice and keyboards, by using a feature that can only be enabled by the new closed-source setup GUI, but *not* the same way as synergy-1 because now *both* mice and keyboards can be used across both desktops (with a delay as it seems to dynamically reconfigure to switch from client to server or vice versa). N.B. symless.com explicitly says that Synergy 2 is not backwards compatible so if you use it you need to install it on all machines. Synergy 2 is only partly open source (only synergy-core is open, the set up GUI and advanced features are only available for the paying customers of closed source parts). So you are forcing all users to upgrade to a version that removes features (i.e. just synergy-core not synergy), or to pay for the closed source version. This is unacceptable for Fedora IMHO. (In reply to Kevin Kofler from comment #16) > > The reason I push this update is to accommodate the RHEL 7 boxes that enabled > > the repository rhel-7-workstation-htb-rpms, with which > > avahi-compat-libdns_sd-devel-0.6.31-17 conflicts with avahi-0.6.31-19. > > synergy2 does not require avahi-compat-libdns_sd > > The funny thing is that this dependency is now back because the GUI requires > it. (It was the removal of the GUI that dropped the dependency.) > > Wouldn't the best solution be to bump Epoch and revert to 1.8.8 altogether? Usually, I won't say this is the best solution, because 2.0.0 usually bring some new features. However, looking at the ChangeLog and git log, most of them are clean up and change paths. The most interesting commit is: https://github.com/symless/synergy-core/pull/6045 Quote: If this code ever fetched a string longer than 1K, it would leak memory and then perform a null dereference. So, I can revert it to 1.8.8 if none of you think that you need the commit. (In reply to Jonathan Wakely from comment #19) > I've now got the non-open source version of synergy 2 installed, and it does > allow me to use both mice and keyboards, by using a feature that can only be > enabled by the new closed-source setup GUI, but *not* the same way as > synergy-1 because now *both* mice and keyboards can be used across both > desktops (with a delay as it seems to dynamically reconfigure to switch from > client to server or vice versa). > > N.B. symless.com explicitly says that Synergy 2 is not backwards compatible > so if you use it you need to install it on all machines. > > Synergy 2 is only partly open source (only synergy-core is open, the set up > GUI and advanced features are only available for the paying customers of > closed source parts). So you are forcing all users to upgrade to a version > that removes features (i.e. just synergy-core not synergy), or to pay for > the closed source version. This is unacceptable for Fedora IMHO. Thanks for the through tests and exploration. The only interesting commit between v1.8.8-stable and v2.0.0-stable is https://github.com/symless/synergy-core/pull/6045 If you think that is not important, I can create an epoch to revert the version in current Fedora, as well as rawhide. If you revert Fedora 27 and Rawhide, you should also do it for at least Fedora 26 too as users are complaining about this too : https://github.com/symless/synergy-core/issues/6254 (In reply to Ding-Yi Chen from comment #21) > If you think that is not important, I can create an epoch to revert the > version in current Fedora, as well as rawhide. I'm just using the upstream v1.8.8 RPM and adding exclude=synergy to my Yum repo configs, so I no longer care about the Fedora packages. I'm not using them. (In reply to sheepdestroyer from comment #22) > If you revert Fedora 27 and Rawhide, you should also do it for at least > Fedora 26 too as users are complaining about this too : > https://github.com/symless/synergy-core/issues/6254 Yes, the original point of this bug report is that updating from v1 to v2 in F26 and F27 is against Fedora's policies. It's also a downgrade in functionality (even in rawhide, where the policy does allow updating it) due to only the core being open source in v2. I would like to point out that this upgrade has also affected people who use the EPEL repo on RHEL/CentOS, not just Fedora users. (In reply to Ken Yap from comment #25) > I would like to point out that this upgrade has also affected people who use > the EPEL repo on RHEL/CentOS, not just Fedora users. Yes that was already pointed out in comment 0 and comment 1. Come to think of it, my 2.0.0-2 update does not fit the bill here. So I unlink the update with this bug. The 1:1.8.8 is building at the moment. I will link this bug to that update. synergy-1.8.8-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7dd4cdd6e3 synergy-1.8.8-3.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-137991da60 synergy-1.8.8-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-137991da60 synergy-1.8.8-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7dd4cdd6e3 synergy-1.8.8-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dad604399b synergy-1.8.8-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-dad604399b synergy-1.8.8-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. synergy-1.8.8-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. synergy-1.8.8-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. |