[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/dhrystone/dhrystone.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/dhrystone/dhrystone.hash

diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
new file mode 100644
index 0000000..9ea22a3
--- /dev/null
+++ b/package/dhrystone/dhrystone.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
-- 
2.4.10

[Buildroot] [PATCH 2/4] libglu: add a hash file

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/libglu/libglu.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/libglu/libglu.hash

diff --git a/package/libglu/libglu.hash b/package/libglu/libglu.hash
new file mode 100644
index 0000000..6e4e4fd
--- /dev/null
+++ b/package/libglu/libglu.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 3d19cca9b26ec4048dd22e3d294acd43e080a3205a29ff47765bd514571ea8f9  glu-9.0.0.tar.gz
-- 
2.4.10

[Buildroot] [PATCH 3/4] torsmo: add a hash file

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/torsmo/torsmo.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/torsmo/torsmo.hash

diff --git a/package/torsmo/torsmo.hash b/package/torsmo/torsmo.hash
new file mode 100644
index 0000000..8bbf9dc
--- /dev/null
+++ b/package/torsmo/torsmo.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 6a6bc82e71c841ba9359f0ffe370e57ef7b04b49a448252bb0c1c28fc10e964c  torsmo-0.18.tar.gz
-- 
2.4.10

[Buildroot] [PATCH 4/4] whetstone: add a hash file

[Vicente Olivert Riera]

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
 package/whetstone/whetstone.hash | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 package/whetstone/whetstone.hash

diff --git a/package/whetstone/whetstone.hash b/package/whetstone/whetstone.hash
new file mode 100644
index 0000000..db9bbb4
--- /dev/null
+++ b/package/whetstone/whetstone.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 333e4ceca042c146f63eec605573d16ae8b07166cbc44a17bec1ea97c6f1efbf  whetstone.c
-- 
2.4.10

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Peter Korsgaard]

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
 > ---
 >  package/dhrystone/dhrystone.hash | 2 ++
 >  1 file changed, 2 insertions(+)
 >  create mode 100644 package/dhrystone/dhrystone.hash

 > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
 > new file mode 100644
 > index 0000000..9ea22a3
 > --- /dev/null
 > +++ b/package/dhrystone/dhrystone.hash
 > @@ -0,0 +1,2 @@
 > +# Locally calculated
 > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c

Hmm, what are we going to do if this file ever changes?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Arnout Vandecappelle]

On 02-12-15 21:45, Peter Korsgaard wrote:
>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
> 
>  > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>  > ---
>  >  package/dhrystone/dhrystone.hash | 2 ++
>  >  1 file changed, 2 insertions(+)
>  >  create mode 100644 package/dhrystone/dhrystone.hash
> 
>  > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
>  > new file mode 100644
>  > index 0000000..9ea22a3
>  > --- /dev/null
>  > +++ b/package/dhrystone/dhrystone.hash
>  > @@ -0,0 +1,2 @@
>  > +# Locally calculated
>  > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
> 
> Hmm, what are we going to do if this file ever changes?
> 

 Isn't that the whole point of the hash, that we notice when it changes?

 That said, I'm not sure what we can do about it when that happens, except
switch to a more reliable mirror.

 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 1/4] dhrystone: add a hash file

[Yann E. MORIN]

Peter, Vicente, All,

On 2015-12-02 21:45 +0100, Peter Korsgaard spake thusly:
> >>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
> 
>  > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>  > ---
>  >  package/dhrystone/dhrystone.hash | 2 ++
>  >  1 file changed, 2 insertions(+)
>  >  create mode 100644 package/dhrystone/dhrystone.hash
> 
>  > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
>  > new file mode 100644
>  > index 0000000..9ea22a3
>  > --- /dev/null
>  > +++ b/package/dhrystone/dhrystone.hash
>  > @@ -0,0 +1,2 @@
>  > +# Locally calculated
>  > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
> 
> Hmm, what are we going to do if this file ever changes?

That's a good question...

Since ultimately I'd like we get hash files for the packages, and make
it an error when the hash file is missing, we'd have to handle those
cases in a consistent way.

There are two options here:

  - add a real hash, and break older releases when the file is updated
    upstream,

  - add a 'none' hash, but loose the detection tht upstream has changed
    (but the autobuilders would tell us if that change breaks the
    build).

I'm afraid the only possible solution if we want to have a hash is the
second solution (but with a comment explaning why it is so).

But until we make the .hash files mandatory, we can just not add it for
non-versioned upstreams. So I'd say we drop that one.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 1/4] dhrystone: add a hash file

[Vicente Olivert Riera]

Hi Peter,

On 02/12/15 20:45, Peter Korsgaard wrote:
>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
> 
>  > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
>  > ---
>  >  package/dhrystone/dhrystone.hash | 2 ++
>  >  1 file changed, 2 insertions(+)
>  >  create mode 100644 package/dhrystone/dhrystone.hash
> 
>  > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
>  > new file mode 100644
>  > index 0000000..9ea22a3
>  > --- /dev/null
>  > +++ b/package/dhrystone/dhrystone.hash
>  > @@ -0,0 +1,2 @@
>  > +# Locally calculated
>  > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
> 
> Hmm, what are we going to do if this file ever changes?

isn't the purpose of the hash files to ensure that we download exactly
what we want to download, so we can make the builds reproducible?

If that file changes, we will notice it thanks to its hash file. You
could ask the same for tarballs. What are we going to do if this
tarballs ever changes?

Regards,

Vincent.

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Thomas Petazzoni]

Vicente,

On Thu, 3 Dec 2015 10:35:01 +0000, Vicente Olivert Riera wrote:

> >  > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> >  > new file mode 100644
> >  > index 0000000..9ea22a3
> >  > --- /dev/null
> >  > +++ b/package/dhrystone/dhrystone.hash
> >  > @@ -0,0 +1,2 @@
> >  > +# Locally calculated
> >  > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e  dhry-c
> > 
> > Hmm, what are we going to do if this file ever changes?
> 
> isn't the purpose of the hash files to ensure that we download exactly
> what we want to download, so we can make the builds reproducible?
> 
> If that file changes, we will notice it thanks to its hash file. You
> could ask the same for tarballs. What are we going to do if this
> tarballs ever changes?

It also took me a bit to understand Peter's comment. I believe what
Peter means is that this file has no version in its name. So if
upstream changes the file, the hash will change, and we will notice.
But it will break every previous Buildroot version that has been
released, since the old file can no longer be fetched from anywhere.

But unless I'm missing something, I believe that this is exactly what
we want: if upstream changes the file, it *does* affect old Buildroot
versions, and we want users of such old Buildroot versions to be loudly
notified that the dhry-c file they are building from is no longer the
same than the one that existed at the time the Buildroot they are using
was released.

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

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

>> > Hmm, what are we going to do if this file ever changes?
 >> 
 >> isn't the purpose of the hash files to ensure that we download exactly
 >> what we want to download, so we can make the builds reproducible?
 >> 
 >> If that file changes, we will notice it thanks to its hash file. You
 >> could ask the same for tarballs. What are we going to do if this
 >> tarballs ever changes?

 > It also took me a bit to understand Peter's comment. I believe what
 > Peter means is that this file has no version in its name. So if
 > upstream changes the file, the hash will change, and we will notice.

Yes, my reply was perhaps a bit too terse.

 > But it will break every previous Buildroot version that has been
 > released, since the old file can no longer be fetched from anywhere.

No, it will not break as long as we keep a backup of the old file on
sources.buildroot.net, as buildroot will fall back to using that.


 > But unless I'm missing something, I believe that this is exactly what
 > we want: if upstream changes the file, it *does* affect old Buildroot
 > versions, and we want users of such old Buildroot versions to be loudly
 > notified that the dhry-c file they are building from is no longer the
 > same than the one that existed at the time the Buildroot they are using
 > was released.

Agreed, but the problem is if upstream ever changes the file content (for
bugfixes or new features) then we cannot use the new version without
updating our sources.buildroot.net mirror (and hence break old
releases).

But ok, for something as old as dhrystone this probably isn't very
likely to happen (and we could carry the improvements/fixes as a local
patch if it does).

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Peter Seiderer]

Hello Peter,

On Thu, 03 Dec 2015 12:42:50 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> 
> Hi,
> 
> >> > Hmm, what are we going to do if this file ever changes?
>  >> 
>  >> isn't the purpose of the hash files to ensure that we download exactly
>  >> what we want to download, so we can make the builds reproducible?
>  >> 
>  >> If that file changes, we will notice it thanks to its hash file. You
>  >> could ask the same for tarballs. What are we going to do if this
>  >> tarballs ever changes?
> 
>  > It also took me a bit to understand Peter's comment. I believe what
>  > Peter means is that this file has no version in its name. So if
>  > upstream changes the file, the hash will change, and we will notice.
> 
> Yes, my reply was perhaps a bit too terse.
> 
>  > But it will break every previous Buildroot version that has been
>  > released, since the old file can no longer be fetched from anywhere.
> 
> No, it will not break as long as we keep a backup of the old file on
> sources.buildroot.net, as buildroot will fall back to using that.
> 
> 
>  > But unless I'm missing something, I believe that this is exactly what
>  > we want: if upstream changes the file, it *does* affect old Buildroot
>  > versions, and we want users of such old Buildroot versions to be loudly
>  > notified that the dhry-c file they are building from is no longer the
>  > same than the one that existed at the time the Buildroot they are using
>  > was released.
> 
> Agreed, but the problem is if upstream ever changes the file content (for
> bugfixes or new features) then we cannot use the new version without
> updating our sources.buildroot.net mirror (and hence break old
> releases).
> 

Why not append a (short) hash to the saved file for unversioned downloads?

e.g. dhry-c-038a7e9

Regards,
Peter

> But ok, for something as old as dhrystone this probably isn't very
> likely to happen (and we could carry the improvements/fixes as a local
> patch if it does).
> 

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Peter Korsgaard]

>>>>> "Peter" == Peter Seiderer <ps.report@gmx.net> writes:

Hi,

 > Hello Peter,

 > Why not append a (short) hash to the saved file for unversioned downloads?

 > e.g. dhry-c-038a7e9

This could be done, but it complicates the primary/backup site handling
(E.G. should they use the upstream name or "our" name) - The way
sources.buildroot.net is kept up to date would mean that they would need
to use "our" name.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [PATCH 1/4] dhrystone: add a hash file

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 2 Dec 2015 12:29:40 +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/dhrystone/dhrystone.hash | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 package/dhrystone/dhrystone.hash

Applied, thanks.

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

[Buildroot] [PATCH 2/4] libglu: add a hash file

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 2 Dec 2015 12:29:41 +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/libglu/libglu.hash | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 package/libglu/libglu.hash

I don't think a hash for this package will work fine: it is a snapshot
tarball generate by cgit. As an example, the tarball I had locally here
did not had the same hash as the one you entered. Once re-downloaded, I
got a tarball that had a hash matching yours. But again, I don't think
we can assume it's a stable hash.

thomas at skate:~/projets/buildroot (master)$ make libglu-extract
ERROR: glu-9.0.0.tar.gz has wrong sha256 hash:
ERROR: expected: 3d19cca9b26ec4048dd22e3d294acd43e080a3205a29ff47765bd514571ea8f9
ERROR: got     : 0d10e3b297663e701499fc0324f62bf697a61b984c873cb5b43d636668c41659
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
dl-wrapper: Re-downloading 'glu-9.0.0.tar.gz'...
--2015-12-17 16:32:05--  http://cgit.freedesktop.org/mesa/glu/snapshot/glu-9.0.0.tar.gz
Resolving cgit.freedesktop.org (cgit.freedesktop.org)... 131.252.210.161
Connecting to cgit.freedesktop.org (cgit.freedesktop.org)|131.252.210.161|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: ?/home/thomas/projets/buildroot/output/build/.glu-9.0.0.tar.gz.x6B3tE/output?

/home/thomas/projets/buildroot/output     [         <=>                                                             ] 296,94K   155KB/s   in 1,9s   

2015-12-17 16:32:08 (155 KB/s) - ?/home/thomas/projets/buildroot/output/build/.glu-9.0.0.tar.gz.x6B3tE/output? saved [304063]

glu-9.0.0.tar.gz: OK (sha256: 3d19cca9b26ec4048dd22e3d294acd43e080a3205a29ff47765bd514571ea8f9)

I've marked this patch as Rejected.

Best regards,

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

[Buildroot] [PATCH 3/4] torsmo: add a hash file

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 2 Dec 2015 12:29:42 +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/torsmo/torsmo.hash | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 package/torsmo/torsmo.hash

Applied, thanks. However, I think you could send a patch to deprecate
this package. It is really not something that is maintained or
evolving, it doesn't have a website or anything. It's really a leftover
from the time where we had some avr32 support contributed by Atmel and
other folks.

Best regards,

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

[Buildroot] [PATCH 4/4] whetstone: add a hash file

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Wed, 2 Dec 2015 12:29:43 +0000, Vicente Olivert Riera wrote:
> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> ---
>  package/whetstone/whetstone.hash | 2 ++
>  1 file changed, 2 insertions(+)
>  create mode 100644 package/whetstone/whetstone.hash

Applied, thanks.

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

[Buildroot] [PATCH 3/4] torsmo: add a hash file

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Vicente Olivert Riera,
 > On Wed, 2 Dec 2015 12:29:42 +0000, Vicente Olivert Riera wrote:
 >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
 >> ---
 >> package/torsmo/torsmo.hash | 2 ++
 >> 1 file changed, 2 insertions(+)
 >> create mode 100644 package/torsmo/torsmo.hash

 > Applied, thanks. However, I think you could send a patch to deprecate
 > this package. It is really not something that is maintained or
 > evolving, it doesn't have a website or anything. It's really a leftover
 > from the time where we had some avr32 support contributed by Atmel and
 > other folks.

I agree, it is very old and hasn't been updated since it was added.

-- 
Venlig hilsen,
Peter Korsgaard