[Buildroot] [PATCH] synergy: change upstream location to fix download issues

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > Hello,
 > On Mon, 03 Sep 2018 09:20:10 +0200, Peter Korsgaard wrote:

 >> >  SYNERGY_VERSION = v1.8.8-stable
 >> > -SYNERGY_SITE = $(call github,symless,synergy,$(SYNERGY_VERSION))
 >> > +SYNERGY_SITE = $(call github,symless,synergy-core,$(SYNERGY_VERSION))  
 >> 
 >> So is the idea to apply this to next or to master? If we change the hash
 >> for the 1.8.8 version, then this will break download for the 2018.02.x /
 >> 2018.05.x releases.

 > My idea was to have it on master and next, but indeed I did not think
 > about 2018.02.x/2018.05.x being broken :-/

 >> Looking at the synergy git history, a hack could be to bump the version
 >> to the commit just after v1.8.8 together with changing the URL so we end
 >> up with a new tarball name:
 >> 
 >> commit ec56ac4485ef8e3cf986107b8456949b5aec3527
 >> Author: Andrew Nelless <andrew@symless.com>
 >> Date:   Fri Mar 3 14:51:23 2017 +0000
 >> 
 >> Fix version number in Changelog

 > Or perhaps we simply don't fix it in master, and only in next ? The big
 > downside I see with not fixing in master is that people who look at
 > their build log will see the upstream download fail due to the hash
 > mismatch, and the fallback to sources.buildroot.net. A
 > security-conscious user could rightfully think that Buildroot is trying
 > to sneak in a backdoor in the synergy code by providing a different
 > version on sources.buildroot.net than what upstream provides.

s/not fixing in master/not fixing in master and 2018.0{2,5}.x/.

I guess the best solution is to bump to the git hash just after the
1.8.8 at the new upstream location (perhaps with a comment that this is
1.8.8) and apply that to all 3 branches.

I will do a last release of 2018.05.x in a week or 2 and mark it as EOL.

-- 
Bye, Peter Korsgaard