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

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

[Thomas Petazzoni]

The Github repository at https://github.com/symless/synergy no longer
exists, it has apparently been moved to
https://github.com/symless/synergy-core.

On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
v1.8.8, which fails to download from github.com, so we fallback to
sources.buildroot.net, which has the tarball.

However, on next as of 7da2748c9ef4e67a060ea7eb6ff23275da235daa, we
use v2.1.0, which completely fails to download, as we don't have a
backup tarball on sources.buildroot.net.

This commit fixes that by using the new upstream
location. Unfortunately, the hash changes, because the prefix in the
tarball is changed from synergy-1.8.8-stable/ to
synergy-core-1.8.8-stable/. There are no other changes. This means
that people having existing tarballs locally we'll see them being
re-downloaded because the hash has changed.

Fixes (once applied to next):

  http://autobuild.buildroot.net/results/82ae9a378b70a3d27e78e1d80a63495b37329e16/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
---
 package/synergy/Config.in    | 2 +-
 package/synergy/synergy.hash | 2 +-
 package/synergy/synergy.mk   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/synergy/Config.in b/package/synergy/Config.in
index 3bb8b8e98c..2f99cdf6fc 100644
--- a/package/synergy/Config.in
+++ b/package/synergy/Config.in
@@ -14,7 +14,7 @@ config BR2_PACKAGE_SYNERGY
 	  operating systems, each with its own display,
 	  without special hardware.
 
-	  https://github.com/symless/synergy/
+	  https://github.com/symless/synergy-core/
 
 comment "synergy needs a toolchain w/ C++, wchar"
 	depends on BR2_PACKAGE_XORG7
diff --git a/package/synergy/synergy.hash b/package/synergy/synergy.hash
index 52f9d74d6b..34d4b99050 100644
--- a/package/synergy/synergy.hash
+++ b/package/synergy/synergy.hash
@@ -1,2 +1,2 @@
 # Locally computed:
-sha256  85c388f93881d741981ce3c675e840a52a76883cb2cea1da306c0c453c5d7d9b  synergy-v1.8.8-stable.tar.gz
+sha256  9ee45aabf9f77925bfab6248e713ae5d9e6bfe6bc246e4a0a6304dc6a30f5f14  synergy-v1.8.8-stable.tar.gz
diff --git a/package/synergy/synergy.mk b/package/synergy/synergy.mk
index 76a4004f06..932a2ee9dc 100644
--- a/package/synergy/synergy.mk
+++ b/package/synergy/synergy.mk
@@ -5,7 +5,7 @@
 ################################################################################
 
 SYNERGY_VERSION = v1.8.8-stable
-SYNERGY_SITE = $(call github,symless,synergy,$(SYNERGY_VERSION))
+SYNERGY_SITE = $(call github,symless,synergy-core,$(SYNERGY_VERSION))
 SYNERGY_LICENSE = GPL-2.0
 SYNERGY_LICENSE_FILES = LICENSE
 SYNERGY_DEPENDENCIES = libcurl openssl xlib_libX11 xlib_libXtst
-- 
2.14.4

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

[Peter Korsgaard]

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

 > The Github repository at https://github.com/symless/synergy no longer
 > exists, it has apparently been moved to
 > https://github.com/symless/synergy-core.

 > On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
 > v1.8.8, which fails to download from github.com, so we fallback to
 > sources.buildroot.net, which has the tarball.

 > However, on next as of 7da2748c9ef4e67a060ea7eb6ff23275da235daa, we
 > use v2.1.0, which completely fails to download, as we don't have a
 > backup tarball on sources.buildroot.net.

 > This commit fixes that by using the new upstream
 > location. Unfortunately, the hash changes, because the prefix in the
 > tarball is changed from synergy-1.8.8-stable/ to
 > synergy-core-1.8.8-stable/. There are no other changes. This means
 > that people having existing tarballs locally we'll see them being
 > re-downloaded because the hash has changed.

 > Fixes (once applied to next):

 >   http://autobuild.buildroot.net/results/82ae9a378b70a3d27e78e1d80a63495b37329e16/

 >  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.

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

-- 
Bye, Peter Korsgaard

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

[Thomas Petazzoni]

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.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Peter Korsgaard]

>>>>> "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

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

[Arnout Vandecappelle]

On 03/09/2018 10:26, Thomas Petazzoni wrote:
> 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 :-/

 Wait, how are these broken? Quoting the commit message:

   On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
   v1.8.8, which fails to download from github.com, so we fallback to
   sources.buildroot.net, which has the tarball.

>> 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.

 It's not a hash mismatch, it's a 404. So in my book, that's fine.

> 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.

 Well, if upstream breaks their URLs, you can't expect things to keep working...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Thomas Petazzoni]

Hello,

On Tue, 4 Sep 2018 00:25:27 +0200, Arnout Vandecappelle wrote:

> > 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 :-/  
> 
>  Wait, how are these broken? Quoting the commit message:
> 
>    On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
>    v1.8.8, which fails to download from github.com, so we fallback to
>    sources.buildroot.net, which has the tarball.

synergy is using version 1.8.8 since commit
caa16c13e0fef18ae1142f502ee39d2af8f5172e, which was merged in 2017.05.

> >> 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.  
> 
>  It's not a hash mismatch, it's a 404. So in my book, that's fine.

True. But if people fix to use the new upstream, then the hash becomes
different. But perhaps that's OK.

So all in all, you're saying that we should keep it as-is in
master/2018.02.x/2018.05.x, and simply change in next ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Arnout Vandecappelle]

On 04/09/2018 10:03, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 4 Sep 2018 00:25:27 +0200, Arnout Vandecappelle wrote:
> 
>>> 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 :-/  
>>
>>  Wait, how are these broken? Quoting the commit message:
>>
>>    On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
>>    v1.8.8, which fails to download from github.com, so we fallback to
>>    sources.buildroot.net, which has the tarball.
> 
> synergy is using version 1.8.8 since commit
> caa16c13e0fef18ae1142f502ee39d2af8f5172e, which was merged in 2017.05.
> 
>>>> 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.  
>>
>>  It's not a hash mismatch, it's a 404. So in my book, that's fine.
> 
> True. But if people fix to use the new upstream, then the hash becomes
> different. But perhaps that's OK.
> 
> So all in all, you're saying that we should keep it as-is in
> master/2018.02.x/2018.05.x, and simply change in next ?

 Yes, that's what I'm saying. Don't fix what's not broken. We have plenty of
other patches to apply :-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

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

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

>> True. But if people fix to use the new upstream, then the hash becomes
 >> different. But perhaps that's OK.
 >> 
 >> So all in all, you're saying that we should keep it as-is in
 >> master/2018.02.x/2018.05.x, and simply change in next ?

 >  Yes, that's what I'm saying. Don't fix what's not broken. We have plenty of
 > other patches to apply :-)

I agreed, lets just fix this up when bumping and leave 2018.02.x /
2018.05.x / 2018.08.x as is.

-- 
Bye, Peter Korsgaard

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

[Thomas Petazzoni]

Hello,

On Sun,  2 Sep 2018 22:45:05 +0200, Thomas Petazzoni wrote:
> The Github repository at https://github.com/symless/synergy no longer
> exists, it has apparently been moved to
> https://github.com/symless/synergy-core.
> 
> On master as of 811734ef9044bbdfc067da76358153061fae2031, we use
> v1.8.8, which fails to download from github.com, so we fallback to
> sources.buildroot.net, which has the tarball.
> 
> However, on next as of 7da2748c9ef4e67a060ea7eb6ff23275da235daa, we
> use v2.1.0, which completely fails to download, as we don't have a
> backup tarball on sources.buildroot.net.
> 
> This commit fixes that by using the new upstream
> location. Unfortunately, the hash changes, because the prefix in the
> tarball is changed from synergy-1.8.8-stable/ to
> synergy-core-1.8.8-stable/. There are no other changes. This means
> that people having existing tarballs locally we'll see them being
> re-downloaded because the hash has changed.
> 
> Fixes (once applied to next):
> 
>   http://autobuild.buildroot.net/results/82ae9a378b70a3d27e78e1d80a63495b37329e16/
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> ---
>  package/synergy/Config.in    | 2 +-
>  package/synergy/synergy.hash | 2 +-
>  package/synergy/synergy.mk   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

Following the discussion with Arnout and Peter, I marked this patch as
"Changes Requested" (it was not merged in master prior to the 2018.08
release). And instead, I committed a fix in master now, only for the
v2.0.12-beta version of synergy. For this one, the hash of the tarball
was already correct.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com