[Buildroot] [PATCH 1/3] package/c-ares: add hash

[Buildroot] [PATCH 1/3] package/c-ares: add hash

[Fabio Porcedda]

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 package/c-ares/c-ares.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/c-ares/c-ares.hash

diff --git a/package/c-ares/c-ares.hash b/package/c-ares/c-ares.hash
new file mode 100644
index 0000000..ce614d8
--- /dev/null
+++ b/package/c-ares/c-ares.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db c-ares-1.10.0.tar.gz
-- 
2.3.5

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Fabio Porcedda]

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 package/cache-calibrator/cache-calibrator.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/cache-calibrator/cache-calibrator.hash

diff --git a/package/cache-calibrator/cache-calibrator.hash b/package/cache-calibrator/cache-calibrator.hash
new file mode 100644
index 0000000..df61d17
--- /dev/null
+++ b/package/cache-calibrator/cache-calibrator.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 2018ed8fa733155d44ceb1c0066c5cf8df7771cdf7cfca0a07b8dd9bebd9c221 calibrator.c
-- 
2.3.5

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Peter Korsgaard]

>>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:

 > Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
 > ---
 >  package/cache-calibrator/cache-calibrator.hash | 2 ++
 >  1 file changed, 2 insertions(+)
 >  create mode 100644 package/cache-calibrator/cache-calibrator.hash

 > diff --git a/package/cache-calibrator/cache-calibrator.hash b/package/cache-calibrator/cache-calibrator.hash
 > new file mode 100644
 > index 0000000..df61d17
 > --- /dev/null
 > +++ b/package/cache-calibrator/cache-calibrator.hash
 > @@ -0,0 +1,2 @@
 > +# Locally calculated
 > +sha256 2018ed8fa733155d44ceb1c0066c5cf8df7771cdf7cfca0a07b8dd9bebd9c221 calibrator.c

This will cause issues when/if that file ever gets updated - But then
atleast we know and can update the hash.

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Yann E. MORIN]

Peter, All,

On 2015-04-21 09:07 +0200, Peter Korsgaard spake thusly:
> >>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:
> 
>  > Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>  > ---
>  >  package/cache-calibrator/cache-calibrator.hash | 2 ++
>  >  1 file changed, 2 insertions(+)
>  >  create mode 100644 package/cache-calibrator/cache-calibrator.hash
> 
>  > diff --git a/package/cache-calibrator/cache-calibrator.hash b/package/cache-calibrator/cache-calibrator.hash
>  > new file mode 100644
>  > index 0000000..df61d17
>  > --- /dev/null
>  > +++ b/package/cache-calibrator/cache-calibrator.hash
>  > @@ -0,0 +1,2 @@
>  > +# Locally calculated
>  > +sha256 2018ed8fa733155d44ceb1c0066c5cf8df7771cdf7cfca0a07b8dd9bebd9c221 calibrator.c
> 
> This will cause issues when/if that file ever gets updated - But then
> atleast we know and can update the hash.

It also means that Buildroot 2015.05 will stop working at some point
when this file is updated. The problem is not much about Buildroot
master , which is easily fixable, but about our releases, that get
broken as soon as upstream changes that file.

I am not really happy with either solutions: either add a hash and break
releases in the future, or not add a hash file, and miss updates,
especially in the autobuilders (even though they do remove downloads
from time to time.

One case for the adding the hash, too, is that it will tell people that
their local copy in their local cache (e.g. my ~/src/ ) is out-of-date.

Still, I'm not convinced we want that hash...

Do we have other such packages (I think I read there was another
version-less package for now)?

Regards,
Yann E. MORIN.

> Committed, thanks.
> 
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Tue, 21 Apr 2015 19:22:46 +0200, Yann E. MORIN wrote:

> Do we have other such packages (I think I read there was another
> version-less package for now)?

For makedevs, we simply bundle the source code in Buildroot. But it's
more a core tool, that we have improved for our own purposes.

calibrator.c is only 38KB, so we could integrate it in
package/cache-calibrator/ directly, but it's not very nice either.

Thoas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

>> This will cause issues when/if that file ever gets updated - But then
 >> atleast we know and can update the hash.

 > It also means that Buildroot 2015.05 will stop working at some point
 > when this file is updated. The problem is not much about Buildroot
 > master , which is easily fixable, but about our releases, that get
 > broken as soon as upstream changes that file.

 > I am not really happy with either solutions: either add a hash and break
 > releases in the future, or not add a hash file, and miss updates,
 > especially in the autobuilders (even though they do remove downloads
 > from time to time.

True - I don't really think there's any good solution to this (besides
maybe convincing upstream to version their releases).

 > One case for the adding the hash, too, is that it will tell people that
 > their local copy in their local cache (e.g. my ~/src/ ) is out-of-date.

 > Still, I'm not convinced we want that hash...

Maybe not. Perhaps the breakage from wrong hash is worse than the
potential breakage from newer versions. Also notice that the download
support falls back to our local copy on sources.buildroot.net if the
hash doesn't match.

 > Do we have other such packages (I think I read there was another
 > version-less package for now)?

Yes, we do:

git grep 'SOURCE =.*\.c$'
package/cache-calibrator/cache-calibrator.mk:CACHE_CALIBRATOR_SOURCE = calibrator.c
package/devmem2/devmem2.mk:DEVMEM2_SOURCE = devmem2.c
package/whetstone/whetstone.mk:WHETSTONE_SOURCE = whetstone.c

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 2/3] package/cache-calibrator: add hash

[Fabio Porcedda]

On Tue, Apr 21, 2015 at 10:43 PM, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
>
> Hi,
>
>>> This will cause issues when/if that file ever gets updated - But then
>  >> atleast we know and can update the hash.
>
>  > It also means that Buildroot 2015.05 will stop working at some point
>  > when this file is updated. The problem is not much about Buildroot
>  > master , which is easily fixable, but about our releases, that get
>  > broken as soon as upstream changes that file.
>
>  > I am not really happy with either solutions: either add a hash and break
>  > releases in the future, or not add a hash file, and miss updates,
>  > especially in the autobuilders (even though they do remove downloads
>  > from time to time.
>
> True - I don't really think there's any good solution to this (besides
> maybe convincing upstream to version their releases).
>
>  > One case for the adding the hash, too, is that it will tell people that
>  > their local copy in their local cache (e.g. my ~/src/ ) is out-of-date.
>
>  > Still, I'm not convinced we want that hash...
>
> Maybe not. Perhaps the breakage from wrong hash is worse than the
> potential breakage from newer versions. Also notice that the download
> support falls back to our local copy on sources.buildroot.net if the
> hash doesn't match.
>
>  > Do we have other such packages (I think I read there was another
>  > version-less package for now)?
>
> Yes, we do:
>
> git grep 'SOURCE =.*\.c$'
> package/cache-calibrator/cache-calibrator.mk:CACHE_CALIBRATOR_SOURCE = calibrator.c
> package/devmem2/devmem2.mk:DEVMEM2_SOURCE = devmem2.c
> package/whetstone/whetstone.mk:WHETSTONE_SOURCE = whetstone.c
>

If the upstream is not willing to version those files what about
creating a github repositories for them? Also to be able to check the
hash on github files we just need to attach the binary for each
release.

BR
-- 
Fabio Porcedda

[Buildroot] [PATCH 3/3] package/clapack: add hash

[Fabio Porcedda]

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 package/clapack/clapack.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/clapack/clapack.hash

diff --git a/package/clapack/clapack.hash b/package/clapack/clapack.hash
new file mode 100644
index 0000000..08657fc
--- /dev/null
+++ b/package/clapack/clapack.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 0b3f782bc24845d85f36bafbff0f2f1384dc72df730fda4e7924ec1a70baca5a clapack-3.2.1-CMAKE.tgz
-- 
2.3.5

[Buildroot] [PATCH 3/3] package/clapack: add hash

[Peter Korsgaard]

>>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:

 > Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/3] package/c-ares: add hash

[Peter Korsgaard]

>>>>> "Fabio" == Fabio Porcedda <fabio.porcedda@gmail.com> writes:

 > Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
 > ---
 >  package/c-ares/c-ares.hash | 2 ++
 >  1 file changed, 2 insertions(+)
 >  create mode 100644 package/c-ares/c-ares.hash

 > diff --git a/package/c-ares/c-ares.hash b/package/c-ares/c-ares.hash
 > new file mode 100644
 > index 0000000..ce614d8
 > --- /dev/null
 > +++ b/package/c-ares/c-ares.hash
 > @@ -0,0 +1,2 @@
 > +# Locally calculated
 > +sha256 3d701674615d1158e56a59aaede7891f2dde3da0f46a6d3c684e0ae70f52d3db c-ares-1.10.0.tar.gz

Upstream provides a gpg signature, so I've verified against that and
updated the comment, thanks.

-- 
Bye, Peter Korsgaard