2017.02.x: update hash file for libnl 3.2.27 patch
PATCH 1/1 2017.02.x: update hash file for libnl 3.2.27 patch
From: Julien BOIBESSOT <[email protected]>
Corresponding patch is generated on the fly by github. It seems like generation method has changed, resulting to slightly different patch, so update BR hash file accordingly.
--- package/libnl/libnl.hash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
package/libnl/libnl.hash +2 -1
@@ -1,3 +1,4 @@ # From https://github.com/thom311/libnl/releases/download/libnl3_2_27/libnl-3.2.27.tar.gz.sha256sum sha256 4bbbf92b3c78a90f423cf96260bf419a28b75db8cced47051217a56795f58ec6 libnl-3.2.27.tar.gz -sha256 b7bb929194eefc56c786a7e1ae5176b54713f9013ccec63760f232742ae80361 3e18948f17148e6a3c4255bdeaaf01ef6081ceeb.patch +# Locally computed +sha256 a308873157080f1e2e6693b2a151e15d8dfe77884b073ba3dc9bd42772dd1aef 3e18948f17148e6a3c4255bdeaaf01ef6081ceeb.patch
Signature · 1 line
2.1.4
PATCH 1/1 2017.02.x: update hash file for libnl 3.2.27 patch
Quoted 5 lines · julien.boibessot at free.fr
From: Julien BOIBESSOT <[email protected]>
Corresponding patch is generated on the fly by github. It seems like generation method has changed, resulting to slightly different patch, so update BR hash file accordingly.
So this is problematic. While the tarballs generated by git(hub) are
reproducible, the patch files are not. Makes sense, since it has abbreviated sha1s for the tree objects embedded in them and these will need to become longer over time.
I see no better solution than to disable hashes for bit-downloaded patches
entirely...
Regards,
Arnout
Quoted 17 lines
Signed-off-by Julien BOIBESSOT <[email protected]>--- package/libnl/libnl.hash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)package/libnl/libnl.hash +2
-1@@ -1,3 +1,4 @@ # From https://github.com/thom311/libnl/releases/download/libnl3_2_27/libnl-3.2.27.tar.gz.sha256sum sha256 4bbbf92b3c78a90f423cf96260bf419a28b75db8cced47051217a56795f58ec6 libnl-3.2.27.tar.gz -sha256 b7bb929194eefc56c786a7e1ae5176b54713f9013ccec63760f232742ae80361 3e18948f17148e6a3c4255bdeaaf01ef6081ceeb.patch +# Locally computed +sha256 a308873157080f1e2e6693b2a151e15d8dfe77884b073ba3dc9bd42772dd1aef 3e18948f17148e6a3c4255bdeaaf01ef6081ceeb.patch
Signature · 6 lines
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
PATCH 1/1 2017.02.x: update hash file for libnl 3.2.27 patch
In reply to julien.boibessot at free.frHello,
Quoted 10 lines · julien.boibessot at free.fr
From: Julien BOIBESSOT <[email protected]>
Corresponding patch is generated on the fly by github. It seems like generation method has changed, resulting to slightly different patch, so update BR hash file accordingly.
Signed-off-by Julien BOIBESSOT <[email protected]>--- package/libnl/libnl.hash | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
We had some lengthy discussion about it. The problem with your patch is that it will break things for users of non-updated Buildroot versions.
Currently (without your patch), what happens is that Buildroot tries to download the patch from Github, fails because the hash is wrong, and then falls back to sources.buildroot.net which has the patch matching the hash.
Once we apply your patch, users of the updated version of Buildroot (with your patch) will be able to get the correct patch from Github. However, sources.buildroot.net will also automatically fetch the new patch.
Therefore, users of non-updated Buildroot will try to:
1. Fetch from Github, which fails because the hash doesn't match
2. Fetch from sources.buildroot.net, which fails because the hash doesn't match either
I.e, with your patch, we break the build for existing Buildroot users.
So, like we are about to do in the master branch for all packages, what we are going to do here is that we will bring the libnl patch inside package/libnl/ instead of downloading it from Github.
Peter Korsgaard will work on this soon. In the mean time, I'll mark your patch as Rejected in patchwork.
Thanks for having reported the issue in the first place!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 2017.02.x: update hash file for libnl 3.2.27 patch
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas Petazzoni <[email protected]> writes:
Hi,
Quoted 6 lines
So, like we are about to do in the master branch for all packages, what we are going to do here is that we will bring the libnl patch inside package/libnl/ instead of downloading it from Github.
Peter Korsgaard will work on this soon. In the mean time, I'll mark your patch as Rejected in patchwork.
FYI, I've pushed a patch doing this:
https://git.buildroot.net/buildroot/commit/?h=2017.02.x&id=6826e2ee8a2bc09104185c777a4ff57bc6a78872
Signature · 1 line
Bye, Peter Korsgaard